JDK 版本选择这件事，几乎每隔一两年就会被重新翻出来讨论一遍。我印象特别深的是前阵子帮一个刚入行的朋友搭环境，他打开官网的下载页，盯着 8、17、21、25、27 这一串数字看了半天，最后问我一句："这些不都是 Java 吗，随便下个最新的不行吗？"这个问题看似简单，实际上背后牵扯到语法特性、垃圾回收器演进、生态兼容性、长期支持策略、构建工具链适配等一大堆东西。选错了版本，轻则编译报错、依赖冲突，重则项目上线后性能不达标、安全补丁跟不上。所以这篇内容我打算把 JDK 8 到 27 这条版本线彻底捋一遍，讲清楚每个版本到底带来了什么、适合什么场景、新手该怎么落地。不管你是刚学 Java 的学生、准备重构老系统的工程师，还是想给团队定技术栈的负责人，看完应该都能对号入座找到自己的答案。
1. 先把版本号这串数字的规律搞明白
很多人一上来就纠结"选哪个"，其实连版本号的命名逻辑都没弄清楚。JDK 的版本号在 2017 年之后发生了根本性变化，这个背景不搞懂，后面所有的对比都是空中楼阁。
1.1 从"大版本几年一发"到"半年一发"的节奏切换
JDK 8 之前，Sun 和后来的 Oracle 采用的是"功能驱动"的发布模式，一个大版本往往要憋两三年，攒够一堆特性才发。JDK 8 是 2014 年发布的，JDK 9 一直拖到 2017 年才出来，中间隔了三年多。这种节奏的问题是，新特性迟迟落不了地，开发者等得花儿都谢了。
从 JDK 9 开始，官方改成了每六个月发一个功能版本的节奏，每年 3 月和 9 月各一个。同时引入了**长期支持（LTS）**的概念——不是每个版本都会被长期维护，只有被标记为 LTS 的版本才会获得多年的安全更新和 bug 修复。这个机制是理解整个版本选择逻辑的钥匙。
具体到数字上，JDK 8 是 LTS，JDK 9、10 是非 LTS，JDK 11 是 LTS，12、13、14、15、16 非 LTS，17 是 LTS，18、19、20 非 LTS，21 是 LTS，之后 22、23、24 非 LTS，25 是 LTS，26 非 LTS，27 又是 LTS。你会发现一个规律：大约每两年左右会出一个 LTS 版本。这个节奏不是随便定的，它要兼顾两件事——给新特性足够的沉淀时间，同时让企业有相对稳定的升级窗口。
提示：非 LTS 版本的生命周期通常只有六个月，下一个版本发布它就停止更新了。生产环境基本不用考虑非 LTS 版本，除非你有非常特殊的诉求，比如想提前验证某个新特性。
1.2 LTS 到底意味着什么，别被"长期"两个字忽悠
"长期支持"这个词听起来很美好，但具体支持多久，不同版本、不同厂商差别很大。Oracle 官方的策略是 LTS 版本提供至少八年的商业支持，但免费公开更新通常只覆盖前几年，之后要么买商业订阅，要么转用其他厂商的构建版本。
这里就涉及一个很现实的问题：市面上流通的 JDK 构建不止一家。除了 Oracle 自己的，还有 Eclipse 基金会维护的 Temurin、亚马逊的 Corretto、微软的 OpenJDK 构建、阿里的 Dragonwell 等等。这些构建大多基于 OpenJDK 源码，但在支持周期、补丁策略、性能调优上各有侧重。对新手来说，选一个社区活跃、更新及时的免费构建就够了，比如 Temurin 或者 Corretto，不用一上来就纠结商业订阅。
我个人的经验是，判断一个 LTS 版本值不值得用，看三个指标：一是官方承诺的支持年限，二是主流框架（Spring、MyBatis 这些）对它的适配程度，三是你所在团队或公司的运维能力。前两个是硬条件，第三个决定了你升级时的摩擦成本。
1.3 版本号和内部类文件格式的隐性绑定
还有一个容易被忽略的点：每个 JDK 大版本对应一个 class 文件的 major version。JDK 8 编译出来是 52，JDK 11 是 55，JDK 17 是 61，JDK 21 是 65，往后每加一个大版本这个数字加 1。这个数字决定了"高版本编译的 class 能不能在低版本 JVM 上跑"——答案是不能，会直接抛UnsupportedClassVersionError。
这个机制的实际影响在于：如果你的项目依赖了某个第三方库，而那个库是用更高版本 JDK 编译的，你在低版本 JDK 上根本加载不了。反过来，低版本编译的 class 在高版本 JVM 上通常能跑（向后兼容），但也有例外，比如某些被移除的内部 API。所以选版本时不能只看自己，还得看依赖链上所有组件的最低要求。
2. JDK 8：绕不开的"钉子户"，但它真的老了
聊 JDK 版本，8 是绝对绕不过去的。哪怕到了 2026 年，你去看各种招聘要求、老项目代码库，JDK 8 的出现频率依然高得惊人。这不是因为它多先进，而是因为历史包袱太重。
2.1 为什么这么多系统还钉在 8 上
JDK 8 是 2014 年发布的，那个时间点正好赶上国内互联网大规模扩张，大量系统在那几年定型。之后虽然新版本不断出，但"能跑就别动"的运维哲学让升级这件事一拖再拖。加上 JDK 8 引入了 Lambda 表达式和 Stream API，语法上已经比 7 舒服太多，很多团队觉得"够用了"，缺乏升级动力。
另一个关键原因是生态锁定。一些老牌中间件、内部框架、甚至某些商业软件，明确只支持到 JDK 8。你升到 11 或 17，可能某个核心依赖直接罢工。这种锁定效应是链式的——A 依赖 B，B 只支持 8，那 A 也只能待在 8 上。我见过一个内部系统，光是为了升级 JDK 就得先改三个自研组件，评估下来工作量比新做一个模块还大，最后不了了之。
2.2 JDK 8 的语法甜头和它的技术债
客观说，JDK 8 在当年是里程碑式的。Lambda 让 Java 终于能写出像样的函数式代码，Stream 把集合操作从一堆 for 循环里解放出来，新的日期时间 API（java.time）解决了老Date类的线程安全问题，接口默认方法让库的演进不再那么痛苦。这些特性放到今天依然是日常开发的主力。
但技术债也是实打实的。永久代（PermGen）在 8 里被元空间（Metaspace）取代，这算是好事，但 8 的垃圾回收器主力还是 Parallel 和 CMS，CMS 在后续版本里已经被标记废弃甚至移除。更要命的是，8 缺少后来那些让 Java 焕发第二春的特性——没有模块系统、没有var局部变量类型推断、没有 record、没有 switch 模式匹配、没有虚拟线程。写起来代码量大、样板代码多，跟 17 之后的体验完全不是一个量级。
还有一个现实问题：JDK 8 的免费公开更新早就停了。继续用意味着要么自己承担安全风险，要么买商业支持。这在合规要求高的场景里是个硬伤。
2.3 什么情况下你"不得不"继续用 8
不是说 8 就一无是处。以下几种情况，老老实实待着反而是理性选择：一是维护一个已经稳定运行多年、没有新功能需求的老系统，升级收益远小于风险；二是依赖链里有明确只支持 8 的组件，且短期内无法替换；三是团队技术储备有限，贸然升级带来的运维复杂度超出承受能力。
但我要强调一点：新项目绝对不要从 8 起步。哪怕你团队最熟 8，新项目也应该至少从 17 开始。理由很简单，8 的生态支持在肉眼可见地萎缩，你现在用 8 起的新项目，两三年后就会面临"想升升不动"的尴尬，等于主动给自己埋雷。
3. JDK 11 和 17：过渡带与事实上的新基线
从 8 往上走，11 和 17 是两个关键节点。11 是 8 之后的第一个 LTS，17 则是目前被广泛认可的新一代基线。这两个版本的关系，有点像"过渡"和"定型"。
3.1 JDK 11 的定位：承上启下的尴尬
JDK 11 发布于 2018 年，是 8 之后的第一个 LTS。它带来了一些实用改进，比如var局部变量类型推断（虽然这个特性在 10 就预览了）、新的 HTTP Client API（支持 HTTP/2）、String类新增了一堆便捷方法（isBlank、lines、strip等）、还有可以直接用java命令运行单文件源码，不用先javac再java。
但 11 的尴尬在于，它夹在 8 和 17 中间。对还停留在 8 的团队来说，升到 11 的收益不够"解渴"——语法上没有质变，模块系统虽然引入了但很多项目根本没用起来，反而因为javax到jakarta的命名空间迁移带来一堆麻烦。而对追求新特性的团队来说，17 明显更香。所以 11 在实际落地中，更多是作为"从 8 到 17 的中间跳板"存在，很多团队是 8 直接跳到 17，跳过了 11。
不过 11 也不是没有价值。它的 LTS 支持周期长，稳定性经过多年验证，一些对变更极度保守的金融、电信类系统会选择停在 11。如果你接手的是这样一个系统，理解 11 的特性边界就很有必要。
3.2 JDK 17：为什么它成了新项目的默认答案
JDK 17 发布于 2021 年，是 8 之后第二个 LTS，也是目前生态适配最成熟的高版本。它把 9 到 16 这些年攒下的好东西基本都收编了，形成了质变。
最直观的是语法层面的现代化。record让你用一行代码定义不可变数据载体，省掉一堆 getter、equals、hashCode、toString；sealed类让继承关系可控，配合模式匹配能写出非常清晰的类型分支；switch表达式支持箭头语法和yield，告别 fall-through 的坑；文本块（"""）让多行字符串（比如 SQL、JSON 模板）写起来清爽多了。这些特性单独看都不算颠覆，但组合起来，代码量和可读性的改善是肉眼可见的。
垃圾回收器方面，17 默认是 G1，同时 ZGC 和 Shenandoah 都已经可用（ZGC 在 17 里还算实验性，但已经能用于生产评估）。G1 在 17 上的调优比 8 时代成熟太多，停顿时间控制得更好。对于大多数业务系统，默认配置就能跑得不错，不用像 8 时代那样天天调 CMS 参数。
模块系统在 17 上也算是尘埃落定了。虽然很多项目依然不写module-info.java，但 JDK 自身的模块化让运行时镜像可以裁剪（用jlink），这对容器化部署很有意义——你可以打出一个只包含所需模块的小镜像，启动更快、体积更小。
3.3 从 8 升到 17 的真实摩擦点
升级从来不是改个版本号那么简单。我梳理一下从 8 到 17 最常见的几个坑，这些是文档里不会重点写、但实操中一定会遇到的。
第一个是内部 API 的移除。8 时代很多人用sun.misc.Unsafe或者sun.misc.BASE64Encoder这类内部类，17 里这些要么被封装要么被移除，编译直接报错。解决办法是换成标准 API，比如Base64用java.util.Base64，Unsafe的大部分场景可以用VarHandle替代。
第二个是反射的强封装。17 对 JDK 内部结构的反射访问做了更严格的限制，一些老框架（尤其是做序列化、依赖注入的）如果用了深度反射，可能会抛InaccessibleObjectException。通常需要加--add-opens参数临时放开，但更好的做法是升级框架版本。
第三个是依赖版本。Spring Boot 2.x 早期版本对 17 支持不完整，建议至少用 2.7 以上或者直接上 3.x（3.x 要求 JDK 17+）。MyBatis、各类连接池、日志框架也都要相应升级。这块的工作量往往被低估，实际升级时建议先跑一遍完整的依赖树分析。
注意：升级前一定要在独立分支上做，并且准备好回滚方案。我见过直接在主分支改版本号、结果编译失败一堆人卡住的场面，非常耽误事。
4. JDK 21：虚拟线程带来的范式转变
如果说 17 是"现代化"，那 21 就是"范式转变"。2023 年发布的 JDK 21 是 LTS，它最重磅的特性就是**虚拟线程（Virtual Threads）**正式转正。这个东西对 Java 的并发编程模型影响深远，值得单独拎出来讲。
4.1 虚拟线程到底解决了什么痛点
传统 Java 的线程是平台线程，一对一映射到操作系统线程。操作系统线程很贵——创建销毁有开销，每个线程占用的栈空间通常按 MB 算，一台机器能同时跑的线程数是有硬上限的（几千个就算多了）。这就导致在高并发 IO 场景下，我们不得不搞线程池、搞异步回调、搞响应式编程，代码复杂度飙升。
虚拟线程是 JVM 自己管理的轻量级线程，多个虚拟线程可以复用少量平台线程。它的栈是动态分配的，创建成本极低，你可以放心地开几十万甚至上百万个。这意味着什么？意味着你可以用同步阻塞的写法去处理高并发 IO，不用再写那些嵌套回调或者Mono/Flux的链式代码。代码可读性直接回到"一个请求一个线程"的直觉模型，但吞吐量却能上去。
我实测过一个简单的场景：模拟大量并发请求去调外部接口，用平台线程池需要精心调参还得担心池耗尽，换成虚拟线程后，直接Thread.ofVirtual().start(...)或者用Executors.newVirtualThreadPerTaskExecutor()，代码简洁一大截，压测下来吞吐也稳。当然，虚拟线程不是银弹，它适合 IO 密集型，CPU 密集型场景还是得靠平台线程加合理的并行度。
4.2 21 里其他值得关注的落地特性
除了虚拟线程，21 还有几个实用东西。分代 ZGC让 ZGC 在保持低停顿的同时提升了吞吐，对大堆内存场景更友好。模式匹配 for switch正式转正，配合 record 和 sealed，写类型分派逻辑非常优雅。Sequenced Collections给集合框架补上了"有序集合"的统一接口，getFirst()、getLast()、reversed()这些方法终于不用各写各的了。
还有一个容易被忽略但很实用的：记录模式（Record Patterns）。你可以在instanceof和switch里直接解构 record 的字段，代码简洁度又上一个台阶。这些特性单独看都是小改进，但 21 把它们攒在一起，加上虚拟线程这个大杀器，整体体验比 17 又上了一个层次。
4.3 现在上 21 合不合适
我的判断是：新项目可以放心上 21，老项目升级要评估。新项目没有历史包袱，21 的生态适配到 2026 年已经相当成熟，Spring Boot 3.2+ 对虚拟线程有专门支持，主流框架基本都跟上了。用 21 起步，等于直接站在了未来几年的技术基线上。
老项目升级到 21 的主要顾虑在虚拟线程的引入方式。虚拟线程不是自动生效的，你得主动改代码去用（比如把线程池换成虚拟线程执行器）。如果只是升版本号而不用新特性，那 21 相对 17 的收益就没那么明显，升级的性价比要打个折扣。这种情况下，17 升 21 可以缓一缓，等有明确的并发优化需求时再动。
5. JDK 25 和 27：面向未来的两个 LTS
25 和 27 是更靠后的两个 LTS，很多人对它们的认知还比较模糊。这里我基于公开的版本演进路线，把它们的定位和预期特性讲清楚。需要说明的是，越靠后的版本，具体特性落地情况越可能调整，以下内容是基于当前已知路线图的合理推断。
5.1 JDK 25：稳定演进中的又一个锚点
JDK 25 作为 LTS，承接的是 21 之后几年的积累。从版本节奏看，21 到 25 之间隔了 22、23、24 三个非 LTS，这些版本里的成熟特性会陆续沉淀到 25 里。可以预期的方向包括：虚拟线程的进一步优化（比如对synchronized阻塞的更好处理、监控和调试支持的完善）、结构化并发 API 的转正、以及垃圾回收器在低延迟方向的持续打磨。
对普通开发者来说，25 相对 21 的吸引力主要在于稳定性和工具链成熟度，而不是某个颠覆性新特性。如果你的项目在 21 上跑得很稳，没有遇到明确的瓶颈，那 25 更像是"该升级时的一个自然选择"，而不是"必须马上追"的目标。它的价值在于给那些 21 之后想再往上走一步、但又不想冒非 LTS 风险的团队一个稳妥的落脚点。
5.2 JDK 27：更远的未来，现在只需了解方向
JDK 27 是再下一个 LTS，距离现在更远。从 Java 这几年的演进主线看，27 大概率会继续沿着几条路走：性能方面，Project Panama 带来的外部函数和内存 API 会进一步成熟，让 Java 和本地代码的互操作更高效；并发方面，结构化并发、作用域值（Scoped Values）这些会继续完善，配合虚拟线程形成完整的并发编程新范式；语言方面，模式匹配、值类型（Valhalla 项目）这些长期项目可能会有阶段性成果落地。
对现在要做技术选型的人来说，27 的意义更多是"知道方向在哪"。你不需要现在就为 27 做适配，但如果你在设计一个生命周期很长的系统，了解这些方向能帮你避免选到"即将被淘汰"的技术路线。比如你如果现在还在重度依赖某些老旧的并发模型，那未来迁移到虚拟线程体系时就会比较痛苦，提前有个心理准备和架构预留是明智的。
5.3 版本跨度太大时，升级策略怎么定
从 8 直接跳到 27，跨度太大，风险也大。我的建议是分段升级：8 先到 17（这一步摩擦最大，要处理内部 API、反射、依赖升级），17 稳定运行一段时间后再评估到 21 或 25。每段升级之间留出足够的观察期，让问题暴露出来。
分段升级的好处是每次变更的范围可控，出问题容易定位。一次性跨太多版本，一旦出问题，你很难判断是哪个版本的哪个变更导致的。而且中间版本的一些过渡性 API 和配置，分段走能让你逐步适应，而不是被一堆 breaking change 同时砸中。
| 升级路径 | 主要摩擦 | 建议观察期 |
|---|---|---|
| 8 → 17 | 内部 API 移除、反射封装、依赖升级 | 1-2 个迭代 |
| 17 → 21 | 虚拟线程引入方式、框架版本 | 1 个迭代 |
| 21 → 25 | 相对平滑，主要是工具链适配 | 视情况 |
6. 新手和团队到底该怎么选：一份可落地的决策清单
前面把各个版本掰开揉碎讲了一遍，现在回到最实际的问题：到底选哪个。这个问题没有标准答案，但有清晰的决策逻辑。我按不同角色和场景给出一份清单，你对号入座就行。
6.1 纯新手学 Java：从 17 或 21 起步
如果你是刚开始学 Java，我的建议很明确：别碰 8，直接从 17 或 21 开始。理由有三。第一，你学的目的是掌握现代 Java 的写法，8 的那些老套路（匿名内部类代替 Lambda、手写 getter/setter）学了也是负担，以后还得改。第二，新版本的工具链（IDE、构建工具、教程）都在往高版本迁移，你从 17 起步能少踩很多环境配置的坑。第三，17 和 21 的语法更接近其他现代语言，学习曲线反而更平缓。
具体选 17 还是 21，看你学习的方向。如果只是打基础、学语法和核心库，17 足够，生态最成熟，遇到问题搜到的答案最多。如果想顺带了解并发编程的新范式，21 的虚拟线程值得早点接触。我倾向于推荐 21，因为它是当前和未来几年新项目的主流选择，学了直接能用上。
6.2 维护老系统的工程师：先评估再动手
如果你接手的是跑在 8 或 11 上的老系统，第一件事不是急着升级，而是做一次全面的依赖和风险评估。具体怎么做：先把项目的依赖树拉出来，看每个依赖的最低 JDK 要求；再搜一遍代码里有没有用内部 API、有没有深度反射；最后评估升级的工作量和收益比。
评估下来如果收益明显（比如能显著降低运维成本、能用到关键新特性），就制定分段升级计划。如果收益不明显、风险又高，那就先维持现状，但要做好安全补丁的管理，别让老版本成为安全短板。这里没有"必须升级"的政治正确，只有合不合适。
6.3 团队技术选型：把 LTS 和生态适配放在第一位
如果是给团队定技术栈，决策维度要更系统一些。我通常看这么几项：LTS 状态（非 LTS 直接排除）、主流框架支持度（Spring Boot、各类中间件是否官方支持）、团队熟悉度（升级的学习成本）、运维工具链（监控、诊断工具是否适配）、长期维护成本（免费更新周期、商业支持选项）。
综合下来，2026 年这个时间点，新项目选 21 是比较稳的，生态成熟、特性现代、支持周期长。如果团队极度保守或者有特殊依赖限制，17 也是合理选择。25 可以作为未来一两年的升级目标提前规划，但不必现在就用。8 和 11 只应出现在"维护存量"的场景里，新项目不要碰。
6.4 一张表看清各版本的核心差异
为了让你更直观地对比，我把几个关键版本的核心信息整理成表。需要说明的是，越靠后的版本，部分特性还在演进中，表中标注的是当前已知的稳定信息。
| 版本 | LTS | 关键特性 | 适合场景 | 主要顾虑 |
|---|---|---|---|---|
| 8 | 是 | Lambda、Stream、新日期 API | 存量老系统维护 | 免费更新停止、语法老旧 |
| 11 | 是 | var、HTTP Client、String 增强 | 保守型存量系统 | 定位尴尬、收益有限 |
| 17 | 是 | record、sealed、switch 表达式、文本块 | 新项目基线、8 升级目标 | 从 8 升级摩擦较大 |
| 21 | 是 | 虚拟线程、分代 ZGC、模式匹配 | 新项目首选、高并发场景 | 虚拟线程需主动适配 |
| 25 | 是 | 虚拟线程优化、结构化并发成熟 | 21 之后的稳妥升级 | 生态适配需时间 |
| 27 | 是 | 外部函数内存 API、值类型探索 | 长期项目规划参考 | 距离较远、变数多 |
7. 几个实操中反复被问到的细节问题
理论讲完，最后聊几个我在实际带人、做技术咨询时被问得最多的问题。这些问题的答案往往不在官方文档里，但实操中特别容易卡住。
7.1 多个 JDK 版本能共存吗，怎么管理
能，而且强烈建议共存。你完全可以在同一台机器上装 8、17、21 多个版本，通过环境变量或者工具切换。最土的办法是手动改JAVA_HOME和PATH，但容易忘、容易乱。稍微好一点的做法是用版本管理工具，比如 SDKMAN（Linux/macOS）或者手动维护几个切换脚本。
Windows 上我见过比较实用的做法是写几个.bat脚本，分别设置不同版本的JAVA_HOME，需要哪个就双击哪个。IDE 里也可以单独配置每个项目用的 JDK，跟系统环境变量解耦。关键是要养成习惯：项目根目录或者 README 里明确写清楚这个项目用哪个 JDK 版本，别让后来的人猜。
提示：切换 JDK 版本后，记得清理一下构建工具的缓存（Maven 的
~/.m2一般不用清，但 IDE 的索引和编译输出目录要清），否则可能出现"明明换了版本还报老错误"的诡异现象。
7.2 高版本编译的代码能在低版本跑吗
不能，这是硬限制。前面提过 class 文件的 major version，高版本编译的产物在低版本 JVM 上会直接抛UnsupportedClassVersionError。反过来，低版本编译的代码在高版本 JVM 上通常能跑，但要注意几个例外：一是用了被移除的内部 API，二是依赖了被移除的模块（比如 Java EE 相关的javax包在 11 之后被移出 JDK），三是某些行为变更（比如默认字符集、垃圾回收器默认值）可能导致运行时表现不同。
实际开发中，如果你的项目要兼容多个 JDK 版本，编译时用最低目标版本，并且用--release参数（而不是老的-source/-target）来确保 API 兼容性。--release会同时检查语法和 API，比单纯设 source/target 靠谱得多。
7.3 升级后性能反而下降是怎么回事
这种情况我遇到过几次，原因通常不在 JDK 本身，而在配置没跟着调整。最常见的是垃圾回收器。8 时代很多人用 CMS 并调了一堆参数，升到 17 后默认变成 G1，但老的 CMS 参数还留在启动脚本里，G1 不认识这些参数，要么忽略要么报错，性能自然不对。正确做法是升级时把 GC 相关参数全部重新审视一遍，该删的删、该换的换。
另一个常见原因是依赖库版本没跟上。比如某个序列化框架在老版本 JDK 上有针对性的优化，新版本上没适配，性能就掉下来了。还有 JIT 编译的预热行为在不同版本上也有差异，短时间的压测数据可能不准，要看长时间稳定运行后的表现。所以升级后的性能验证，一定要跑足够长的时间、覆盖足够多的场景，别拿一个瞬时数据下结论。
7.4 容器化部署时 JDK 版本要注意什么
容器场景下有两个点特别值得注意。一是基础镜像的选择，尽量用官方或者社区维护的、带明确版本标签的镜像，别用latest，否则哪天基础镜像悄悄升级了，你的构建结果就不可复现了。二是内存和 CPU 的感知，早期 JDK 8 的某些版本对容器资源限制感知不好，会按宿主机资源来算堆大小，导致容器被 OOM Kill。17 之后这方面改善很多，-XX:MaxRAMPercentage这类参数能更准确地按容器限制来分配堆内存。
如果用 21 的虚拟线程，容器场景下还要注意平台线程池的大小配置。虚拟线程虽然轻量，但底层的载体线程池（ForkJoinPool）大小默认跟 CPU 核数相关，在 CPU 限制严格的容器里可能需要显式调整，避免载体线程不够用导致虚拟线程排队。
7.5 怎么判断一个第三方库支持哪个 JDK 版本
最靠谱的办法是看它的官方文档和pom.xml（或build.gradle）里的编译配置。很多库会在 README 里明确写"Requires JDK 17+"之类的说明。如果文档没写，可以看它发布产物的 class 文件版本，或者直接看它的 CI 配置里用的 JDK 版本。
还有一个实用技巧：在 Maven 里用mvn dependency:tree拉出依赖树后，重点关注那些传递依赖的版本，有时候你直接依赖的库支持高版本，但它传递进来的某个底层库还是老版本编译的，这种隐性不兼容最难排查。遇到诡异的UnsupportedClassVersionError，先怀疑传递依赖。
8. 我个人的版本选择心得
聊了这么多，最后说点我自己的体会。这些年下来，我对 JDK 版本选择的态度经历了一个变化：早期总想追最新，觉得新版本就是好；后来被各种兼容性问题教育了，变得极度保守；到现在，我更倾向于在稳定和现代之间找一个平衡点。
具体来说，我现在给新项目的默认建议是 21，给保守团队的过渡建议是 17，给存量系统的建议是"先评估再动"。这个判断不是拍脑袋，而是基于生态成熟度、支持周期和实际踩坑经验综合出来的。8 和 11 我会尊重它们的历史地位，但不会主动推荐用于新场景。
还有一个心得是：版本选择不是一锤子买卖。你今天选了 21，不代表永远停在 21。技术栈是要持续演进的，关键是建立一套可持续的升级机制——定期评估新版本、保持依赖更新、在非核心项目上先试水。这样等到必须升级的时候，你不会手忙脚乱。我见过太多团队平时不升级、等到安全漏洞爆出来才紧急行动，那种被动局面下的升级质量往往很差。
最后分享一个小习惯：我会在自己的开发机上同时保留 8、17、21 三个版本，遇到不同项目随时切换。这个习惯让我对各个版本的差异保持敏感，也让我在给别人建议时更有底气——毕竟很多结论，是自己真跑过、真踩过才敢说的。
