JDK 8 到 24 全版本深度盘点每个版本的功能、优点、坑与升级建议java -version打出来的那个数字决定了你能用什么语法、你的 GC 有多快、你的服务能扛多少并发。但绝大多数 Java 程序员的状态是用着 JDK 8听说 17 不错知道虚拟线程很香具体哪一版带来的、升级会踩什么坑说不清。这篇文章把 JDK 8 到 242026 年 8 月时点25 已是最新 LTS逐版本盘一遍每个版本带来什么、好在哪、坑在哪、值不值得为它升级。信息以 Oracle/OpenJDK 官方发布说明和 Java Version Almanac 为准。先给一张全景图版本发布类型一句话定位82014.03LTS函数式革命至今装机量最大92017.09-模块化争议最大的版本102018.03-var 局部变量推断112018.09LTS首个新节奏LTSHTTP Client12~162019~2021-渐进式语法铺垫records/sealed 预览 ZGC/Shenandoah172021.09LTSsealed 模式匹配生态迁移分水岭18~202022~2023-虚拟线程孵化期212023.09LTS虚拟线程正式版近十年最大更新22~242024~2025-FFM 落地、Stream Gatherers、性能微调期一、JDK 82014LTS一个版本统治了一个时代核心特性Lambda 表达式与函数式接口、Stream API、Optional、接口默认方法、新的日期时间 APIjava.time、Metaspace 取代永久代、Nashorn JS 引擎、Parallel 数组排序。// JDK 8 之前 ListString names new ArrayList(); for (User u : users) { if (u.getAge() 18) names.add(u.getName()); } // JDK 8 之后 ListString names users.stream() .filter(u - u.getAge() 18) .map(User::getName) .collect(Collectors.toList());优点函数式写法把 Java 从啰嗦的边缘拉了回来Stream 让集合操作的表达力和可读性上了一个台阶java.time 终于结束了 Date/Calendar 的黑暗时代Metaspace 消除了令人闻风丧胆的OutOfMemoryError: PermGen space。缺点与坑并行流默认用公共 ForkJoinPoolIO 密集任务用它反而拖慢全局Optional 被滥用当字段、当参数反而制造了新的坑Lambda 虽好过度链式调用的可读性和调试难度是真实代价。现状2026 年的今天它仍然是装机量最大的版本大量遗留系统、老中间件比如某些老版本 Hadoop 生态锁死在 8 上。Oracle 对 8 的商用更新早就收费8u211 是分水岭此后免费更新要自己找 OpenJDK 发行版继续用 8 的唯一正确姿势是切换到 Temurin/Zulu/Liberica/Corretto 这类 TCK 验证的 OpenJDK 发行版。能升就升不能升至少把发行版换掉——8 的老漏洞不会再有人免费修了。二、JDK 92017模块化——争议最大的版本核心特性JPMS 模块系统Project Jigsaw、jshell REPL、集合工厂方法List.of()、Stream 增强takeWhile/dropWhile/iterate 重载、私有接口方法、多版本 jar、统一日志系统、G1 成为默认 GC。module com.example.app { requires com.example.lib; exports com.example.api; }优点模块系统让 JDK 自身拆成了可裁剪的模块jlink可以打出带精简运行时的自包含镜像容器镜像从几百 MB 缩到几十 MBList.of()这类工厂方法现在已是日常G1 转正为默认 GC 是后来 GC 大跃进的前奏。缺点与坑这是 Java 历史上破坏性最大的版本——强封装strong encapsulation堵死了sun.misc.Unsafe等内部 API 的直接访问大量依赖内部 API 的老框架反射狂魔们集体翻车类路径到模块路径的概念切换让构建工具链折腾了整整一年JPMS 本身的复杂度也不低很多团队最后只用它做 jlink 打包应用级模块化不了了之。现状非 LTS早就 EOL没人单独用它。但它的强封装理念在 16 开始强制执行、17 全面落地是理解后续版本封堵行为的基础。升级建议只有一句9 的意义是通往 11 的桥直接上 11。三、JDK 102018var 来了核心特性局部变量类型推断var、应用类数据共享AppCDS、并行全 GC 的 G1、容器感知JVM 感知 cgroup 内存/CPU 限制。var list new ArrayListString(); // 右边明确var 减少重复 var stream users.stream().filter(u - u.isActive()); // 长类型链友好优点var看着小日常收益极大——泛型嵌套类型、长链式调用的样板代码少了一大截容器感知是容器化时代的隐形功臣之前的 JVM 在容器里默认看宿主机资源动辄 OOM 被 kill10 之后行为终于正常。缺点var只能用于局部变量且必须有初始化表达式滥用会牺牲可读性var x getData()谁知道 x 是什么G1 并行 Full GC 只是止血真正的大招在后面。现状非 LTSEOL。同 9直接上 11。四、JDK 112018LTS新节奏时代的第一个支柱核心特性标准 HTTP Client支持 HTTP/2、异步、String增强isBlank/lines/strip/repeat、Files.readString/writeString、基于嵌套的访问控制、Epsilonno-op GC、ZGC 实验性引入、JavaFX 与 Java EE 模块从 JDK 剥离、单文件源码直接运行java Hello.java。HttpClient client HttpClient.newHttpClient(); HttpRequest req HttpRequest.newBuilder(URI.create(https://api.example.com)) .header(Accept, application/json).build(); client.sendAsync(req, HttpResponse.BodyHandlers.ofString()) .thenApply(HttpResponse::body) .thenAccept(System.out::println);优点终于有了不依赖第三方库的标准 HTTP 客户端旧 HttpURLConnection 的时代结束ZGC 首次亮相目标亚毫秒级停顿为后续 GC 争霸埋下伏笔脚本式运行单文件让 Java 也能写小工具。缺点与坑剥离 Java EE 模块JAXB/JAX-WS/annotation 处理器相关是升级 8→11 最大的工作量来源——老项目里javax.xml.bind一片红Oracle JDK 从 11 起商用收费OpenJDK 免费但 Oracle 版不提供长期二进制License 问题第一次成为架构议题ZGC 此时还只能用于堆 4TB 且实验性。现状LTS企业迁移的第一站生态Spring Boot 2.x、各中间件对它的支持早已成熟。从 8 升 11 的工作量主要在依赖治理一次投入长期受益。它是 8 用户的最低升级目标。五、JDK 12~16看似平淡的版本群实则在憋大招这五个非 LTS 版本单个看都不起眼合起来却完成了 Java 语言近十年的两大跃迁GC 世代更替和数据导向语法革命。快速过一遍每版的贡献JDK 122019.03Shenandoah GCRedHat 系低停顿 GC实验性引入Switch 表达式首次预览G1 可中断混合收集。微版本。JDK 132019.09文本块Text Blocks首次预览ZGC 支持堆回退把不用的内存还给操作系统。微版本。// JDK 15 转正的文本块——写 SQL/JSON 不再是受罪 String sql SELECT id, name FROM users WHERE status ACTIVE ;JDK 142020.03Switch 表达式转正instanceof 模式匹配预览有用的 NPE 提示cannot invoke ... because is null告诉你到底哪个变量空了——日常排障幸福感提升巨大的小功能Records 预览。JDK 152020.09文本块转正ZGC 和 Shenandoah 双双转正生产可用密封类sealed预览移除 Nashorn。JDK 162021.03Records转正instanceof 模式匹配转正强封装默认生效--illegal-access 默认 denyJDK 17 彻底锁死Vector API 孵化ZGC 支持并发线程栈处理。// Records一行顶过去 60 行的 POJOequals/hashCode/toString 全有 public record Point(int x, int y) {}优点合并说预览→反馈→转正的节奏让语言演进来得又快又稳Records模式匹配文本块三件套把样板代码压缩到极限ZGC 生产化让停顿 10ms 以内从 GC 调优的奢侈品变成默认值。缺点合并说非 LTS 版本半年 EOL生产环境用它等于裸奔官方明确不承诺安全更新预览特性需要--enable-previewIDE/构建工具链频繁适配强封装对老框架的破坏从 15 开始让部分祖传依赖升级无门。升级建议这几个版本没有单独升级的意义正确姿势是把它们当中间站目标是 17。六、JDK 172021LTS生态迁移的分水岭核心特性密封类转正sealed/interface permits继承体系从此可以收口模式匹配 switch 预览移除 AOT/JIT 编译器Graal强封装内部 API彻底锁死不再有宽松开关macOS AArch64 支持伪随机数生成器新接口废弃 Applet API。// sealed record switch 模式匹配预览代数数据类型的 Java 表达 public sealed interface Shape permits Circle, Rect {} public record Circle(double radius) implements Shape {} public record Rect(double w, double h) implements Shape {} double area(Shape s) { return switch (s) { case Circle c - Math.PI * c.radius() * c.radius(); case Rect r - r.w() * r.h(); }; // 无 default编译器保证穷尽性加新形状不改这里直接编译报错 }优点sealed 让谁能继承我从文档约定变成编译器强制配合 record 和 switch 模式匹配Java 终于有了正经的代数数据类型表达能力性能上比 8/11 有可观的免费提升G1 多年的持续优化生态拐点——Spring Boot 3、Kafka 4、各主流框架的基线都定为 17此后只支持 8的框架迅速消亡。缺点与坑强封装彻底锁死是双刃剑——大量依赖 JDK 内部 API 的老库旧版反射工具、序列化框架、某些监控 agent在此断代--add-opens可以临时续命但不是长久之计从 8 直升 17 的迁移工作量明显大于升 11EE 模块移除 强封装 语法废除非兼容项三重叠加。现状LTS当前企业新项目的默认基线也是8 之后该去哪的标准答案。七、JDK 18~20虚拟线程的孵化等待期JDK 182022.03UTF-8 成为默认字符集跨平台编码差异从此基本绝迹简单 Web 服务器jwebserver用于静态文件调试代码片段javadoc snippet互联网地址解析 SPI。微版本。JDK 192022.09虚拟线程首次预览Project Loom 落地的历史性时刻结构化并发孵化Record 模式预览外部函数与内存 APIFFM预览。JDK 202023.03作用域值Scoped Values孵化Record 模式、模式匹配 switch、FFM 第二轮预览。纯过渡版本。这三年是 Java 平台憋大招的时期Loom 团队把百万级轻量并发从概念做到预览FFM 把 JNI 这个二十年老古董送上替代进程。单看每版内容不多但方向感极强。八、JDK 212023LTS近十年最重要的版本没有之一核心特性虚拟线程转正JEP 444Thread.ofVirtual()创建的轻量线程由 JVM 调度到少量平台线程上阻塞时自动让出。百万并发连接的服务端编程范式从此改写分代 ZGCJEP 439ZGC 补上分代收集吞吐提升、堆开销下降停顿依旧亚毫秒Record 模式转正解构 record、模式匹配 switch 转正JEP 441有序集合SequencedCollection接口——List/Deque 终于有了统一的 getFirst/getLast密钥封装机制KEMAPI、字符串模板预览后又被撤回重做是 21 时代少见的反复结构化并发/作用域值继续预览Loom 第二块拼图。// 虚拟线程一个 ping 应用百万连接不再是神话 try (var executor Executors.newVirtualThreadPerTaskExecutor()) { for (int i 0; i 1_000_000; i) { int id i; executor.submit(() - { Thread.sleep(1000); // 阻塞上百万个虚拟线程只占极少平台线程 handle(id); return null; }); } }优点虚拟线程把一请求一线程的朴素写法重新变成最优解——不用响应式的复杂回调链就能拿到异步框架的吞吐量分代 ZGC 让大堆服务的 GC 表现整体上一个台阶switch 模式匹配转正让 sealedrecord模式匹配三件套完整成型。缺点与坑虚拟线程不是银弹——synchronized块内的阻塞会导致载体线程钉住pinning吞吐不升反降这正是 24 要修的连接池、ThreadLocal 滥用在高密度虚拟线程下会被放大生态里大量库还没适配结构化并发早期使用有 API 变动风险。现状LTS强烈推荐的目标版本。Spring Boot 3.2 开箱支持虚拟线程一行配置spring.threads.virtual.enabledtrue真实业务的吞吐提升案例已经遍地都是。九、JDK 222024FFM 落地与语法糖成熟核心特性外部函数与内存 APIFFM转正JEP 454——替代 JNI 的现代方案直接调 C 库、安全管理堆外内存未命名变量与模式转正JEP 456_占位符G1 区域钉住JNI 临界区域不再拖死 GC启动多文件源码程序Stream Gatherers自定义中间流操作预览结构化并发/作用域值继续预览。// FFM不经 JNI 直接调 C 函数 Linker linker Linker.nativeLinker(); SymbolLookup stdlib linker.defaultLookup(); MethodHandle strlen linker.downcallHandle( stdlib.find(strlen).get(), FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS)); try (Arena arena Arena.ofConfined()) { long len (long) strlen.invoke(arena.allocateFrom(hello)); }优点FFM 转正是平台级的标志性事件——比 JNI 快无需跨界marshal的固定开销陷阱、安全Arena 管理内存生命周期、不用写 C 胶水代码_占位符干掉了无数catch (Exception e) { /* ignore */ }里的无用变量。缺点FFM 生态迁移刚起步JNI 库的替换要等各项目跟进Gatherers 还在预览API 可能变。十、JDK 232024文档与并发的打磨核心特性Markdown 文档注释JEP 467javadoc 终于可以用 Markdown 写了super(...) 之前可以有语句预览构造器前置校验的自由结构化并发第三轮预览两个子任务 Joiner 模型重构作用域值第三轮预览ZGC 的分代模式成为默认JEP 474非分代模式废弃Stream Gatherers 第二轮预览基元类型模式预览。优点Markdown javadoc 对文档质量的提升立竿见影super 前语句解决的不只是语法洁癖——参数校验终于能在 super 调用前做构造不变量更早建立分代 ZGC 转正默认大堆服务白捡性能。缺点非 LTS 短命版本结构化并发 API 重构意味着之前预览版的代码要改跟预览特性上生产的团队会体验折腾。十一、JDK 242025.03虚拟线程补完与性能细节狂魔核心特性虚拟线程消除 pinningJEP 491synchronized块内阻塞不再钉住载体线程——21 时代最大的虚拟线程性能陷阱被正面解决迁移遗留代码到虚拟线程的最后一块绊脚石移除Stream Gatherers 转正JEP 485Stream.gather()自定义中间操作成为标准流处理表达力补上最后一块短板Class-File API 转正JEP 484字节码操作的标准 APIASM 的官方替代路线紧凑对象头JEP 450产品特性对象头从 96/128 位压到 64 位以内小对象堆占用降 10~20%纯白捡的内存优化分代 Shenandoah 转正JEP 404AOT 类加载与链接JEP 483启动时间最高缩短 40%依赖缓存正式 AOT JIT 在 25 继续推进后量子密码学落地ML-KEM/ML-DSA移除 ZGC 非分代模式废弃sun.misc.Unsafe内存访问方法给所有还在用 Unsafe 的库敲响丧钟。优点24 是个细节控版本没有炫技特性但每一项都在还账——虚拟线程 pinning、启动速度、内存占用、流表达力全是生产环境的真金白银。缺点又是一个非 LTS2026 年 8 月已 EOL这些好东西要等 25 LTS 才有名分 Unsafe 废弃意味着依赖它的老库部分序列化/缓存框架面临再次断代。十二、全局观察与升级决策12.1 十年的三条主线回头看 8→24 这十年Java 的演化其实是三条主线语言表达力从 8 的 Lambda 起点经 records/sealed/pattern matching到 21 的三件套合璧——Java 终于是一门写得舒服的语言并发范式从线程太贵所以要用线程池异步回调的扭曲回到 21 虚拟线程一任务一线程的朴素代价是十年收益是回归可读性运行时效率G1 转正→ZGC/Shenandoah 双子星→分代化→紧凑对象头→AOT停顿从百毫秒进到亚毫秒启动从秒级向毫秒级推进。12.2 升级路径决策你的现状建议还在 JDK 8最低目标 17直接奔 21/25。工作量主要在依赖治理EE 模块、强封装、老库先换 OpenJDK 发行版止血JDK 11升 21 几乎无痛性能白捡重点验证 GC 行为和强封装JDK 17升 21 收益巨大虚拟线程注意 synchronized pinning或直接上 24/25 免除该顾虑新项目直接 21 或 25 LTS启用虚拟线程写法按一请求一虚拟线程设计12.3 发行版提醒自 8u211/11 起Oracle JDK 商用授权问题让用哪个 JDK和用哪个版本变成了两个问题。TemurinEclipse 采纳、Amazon Corretto、Azul Zulu、BellSoft Liberica、微软 Build of OpenJDK 都是经过 TCK 验证的免费发行版LTS 版本的安全更新周期普遍 5~8 年Almanac 显示 8/11/17/21 至今仍在发补丁。继续用 8 可以但请确保你的 8 来自这些发行版而不是 Oracle 商业授权的旧安装包。最后补一句时效2025 年 9 月发布的JDK 25 是最新 LTS作用域值、灵活构造器、紧凑源文件/实例 main 转正AOT JIT 继续推进如果你读到这篇文章时正在做新项目选型25 值得和 21 一起放进候选。主要参考Oracle/OpenJDK 各版本发布说明、Java Version Almanacjavaalmanac.io版本状态与更新时间线、各 JEP 官方文档。性能数字为官方或社区公开口径具体收益以自有业务压测为准。