10-JDK 24 到 27 新特性全解：启动提速、后量子加密与「默认即更快」

这一篇把 24、25、26、27 四版的关键特性一次讲清并给出「你现在该用哪个版本」的明确建议。一、先看清三个版本的定位版本GA 时间是否 LTSJEP 数主题JDK 242025-03-18否已 EOL24转正 Stream Gatherers / Class-File API虚拟线程解 pinning后量子加密首落地JDK 252025-09-16是支持到 2033 年18作用域值、紧凑对象头转正AOT 三连击JFR 三件套JDK 262026-03-17否10Leyden 再进一步任意 GC 的对象缓存、HTTP/3、final 真正不可变JDK 272026-09-15否9G1 全环境默认 GC、紧凑对象头默认开启、后量子 TLS 混合密钥交换、JFR 敏感数据脱敏一句话结论生产新项目直接上JDK 25 LTSJDK 24 已在 2025 年 9 月停止更新不要再新上JDK 26 / 27 都是非 LTS26 的更新已在 2026 年 9 月停止可以拿来试点那几个新 API等下一个 LTSJDK 29预计 2027 年 9 月再大规模铺。JDK 27 把 G1 和紧凑对象头变成默认等于「默认即更快更省」作为非 LTS 很适合在新镜像里无痛跟上。二、JDK 24把攒了几版的东西一次性转正JDK 24 有 24 个 JEP是数量较多的一版。挑最影响日常开发的说。2.1 Stream Gatherers 转正JEP 485第 09 篇介绍过这个「Stream 十年最大扩展」在 24 里正式定稿可以放心用在生产代码里// 固定窗口分批批量入库、批量调用接口场景神器ListListOrderbatchesorders.stream().gather(Gatherers.windowFixed(500)).toList();// 滑动窗口计算移动平均ListListIntegerwindowsStream.of(1,2,3,4,5).gather(Gatherers.windowSliding(3)).toList();// [[1,2,3],[2,3,4],[3,4,5]]// 带并发度的映射IO 密集 虚拟线程友好ListResultresultstasks.stream().gather(Gatherers.mapConcurrent(20,this::remoteCall)).toList();2.2 Class-File API 转正JEP 484官方标准的 class 文件解析/生成 API终结了「想操作字节码只能引 ASM / ByteBuddy」的历史// 读取 class 文件并遍历方法ClassModelcmClassFile.of().parse(Path.of(MyClass.class));for(MethodModelmm:cm.methods()){System.out.println(mm.methodName().stringValue());}// 生成一个简单类byte[]bytesClassFile.of().build(ClassDesc.of(Hello),cb-cb.withMethod(hello,MethodTypeDesc.of(CD_void),ClassFile.ACC_PUBLIC,mb-mb.withCode(code-code.getstatic(CD_System,out,CD_PrintStream).ldc(Hi).invokevirtual(CD_PrintStream,println,MethodTypeDesc.of(CD_void,CD_String)).return_())));价值主要在框架和工具链JDK 自身已用它替换掉内部的 ASM 副本构建工具、Agent、编译器插件会逐步迁移。业务代码一般碰不到。2.3 虚拟线程不再被 synchronized 钉住JEP 491这是JDK 24 对并发最有价值的一条。在 24 之前虚拟线程执行synchronized代码块时会被「钉住」pinned在载体线程上——即使里面发生了阻塞载体线程也释放不掉等于虚拟线程的优势直接失效。这也是很多团队「上了虚拟线程但没看到吞吐提升」的真实原因。JDK 24 重写了这部分实现虚拟线程在 synchronized 中阻塞时会释放载体线程。// 以前这会 pinning现在不会了synchronized(lock){Thread.sleep(1000);// 24 之前载体线程被占用 1 秒}// 24 之后载体线程释放给其他虚拟线程实践意义如果你的代码里有大量 synchronized尤其是老代码、或用 synchronized 的第三方库升级到 24 才能真正吃到虚拟线程的红利。2.4 后量子加密首次落地JEP 496 / 497两个 NIST 标准化的抗量子算法进 JDK// ML-KEM密钥封装机制JEP 496KeyPairGeneratorkpgKeyPairGenerator.getInstance(ML-KEM);kpg.initialize(MLKEMParameterSpec.ML_KEM_768);KeyPairkpkpg.generateKeyPair();// ML-DSA数字签名JEP 497KeyPairGeneratordsaKeyPairGenerator.getInstance(ML-DSA);dsa.initialize(MLDSAParameterSpec.ML_DSA_65);这件事的战略意义大于当下实用价值量子计算机真正威胁现有 RSA/ECC 还需若干年但「现在被窃听存档、将来被破解」的风险已经存在Harvest Now Decrypt Later。金融、政务、长周期保密数据应该开始规划。2.5 另外几条必须知道的JEP内容影响486永久禁用 Security Manager17 标记废弃24 起彻底不能启用。依赖它的老应用必须迁移到容器/OS 层安全机制490ZGC 移除非分代模式分代 ZGC 是唯一选择23 起已是默认472准备限制 JNI 使用未显式开启 native 访问时会告警需加--enable-native-access498sun.misc.Unsafe内存访问方法告警用了 Unsafe 的库部分老版本 Netty、Kryo需要关注483AOT 类加载与链接Leyden 首个成果见下文 JDK 25 部分404 / 450分代 Shenandoah、紧凑对象头实验25 里转正三、JDK 25 LTS新项目的新起点JDK 25 是自 JDK 21 之后的第一个 LTS18 个 JEP 里有7 个转正。它是未来几年企业 Java 的主线版本。3.1 作用域值转正JEP 506ThreadLocal 在虚拟线程时代的问题百万线程 × ThreadLocal 内存爆炸、不可继承、忘记 remove 就泄漏终于有官方替代staticfinalScopedValueUserCURRENT_USERScopedValue.newInstance();voidhandle(Requestreq){Useruserauthenticate(req);ScopedValue.where(CURRENT_USER,user).run(()-process());// 作用域内所有调用链可见}voidprocess(){UseruCURRENT_USER.get();// 子线程含虚拟线程也能读到auditLog(u);}相比 ThreadLocal 的三个优势不可变只能绑定不能改、作用域自动清理出了 run 就没了、子线程继承配合结构化并发。新代码里传递链路上下文用户信息、TraceId、租户 ID应该优先用它。3.2 紧凑对象头转正JEP 519—— 白捡的性能对象头从 96~128 bit 压缩到 64 bit。官方基准堆占用降低约 22%CPU 时间降低约 8%。java-XX:UseCompactObjectHeaders-jarapp.jar这是那种「改一个启动参数就白拿收益」的特性性价比极高。注意它在 24 里是实验特性25 转正后才建议上生产。3.3 三个语法糖转正JEP 511 / 512 / 513模块导入声明JEP 511importmodulejava.base;// 一次性导入 java.base 导出的所有包// 不用再写一堆 import java.util.*; import java.io.*; ...紧凑源文件与实例 main 方法JEP 512// HelloWorld.java 完整内容就这么点voidmain(){IO.println(Hello, World!);}不用写类、不用public static void main(String[] args)。对新手友好写脚本、demo、单文件工具也很爽。灵活构造函数体JEP 513classPositivePoint{privatefinalintx,y;PositivePoint(intx,inty){if(x0||y0){thrownewIllegalArgumentException(坐标不能为负);// ✅ 可以在 super() 之前校验}this.xx;this.yy;super();// 可以不在第一行了}}以前必须在super()之前完成参数校验只能绕道静态工厂或辅助方法现在直接写。3.4 紧凑对象头之外的性能三连Project LeydenJEP内容收益48324 引入AOT 类加载与链接启动时类已是「已加载已链接」状态省掉解析开销514AOT 命令行易用化两条命令合成一条java -XX:AOTCacheOutputapp.aot -jar app.jar515AOT 方法剖析把上一次运行的方法执行剖析数据存进 AOT 缓存JVM 启动即可让 JIT 生成优化代码大幅缩短预热时间AOT 缓存完整用法# 第一步训练运行生成缓存java-XX:AOTCacheOutputapp.aot-jarapp.jar# 第二步正式运行使用缓存java-XX:AOTCacheapp.aot-jarapp.jar典型收益启动时间降低 20%-40%达到峰值性能的时间显著缩短。对 Serverless、短生命周期任务、需要频繁扩缩容的微服务最有价值。3.5 JFR 三件套JEP 509 / 518 / 520JEP内容509CPU 时间剖析Linux 内核 CPU 计时器精确到 CPU 周期518协作式采样在安全点遍历调用栈采样更稳定、偏差更小520方法计时与追踪字节码插桩精确统计单个方法耗时这三条加起来让 JFR 从「不错的 profiler」升级到「可以替代大部分商业 APM 的底层能力」。排查性能问题时值得优先用起 JFR。3.6 其他510KDF API 转正标准密钥派生函数HKDF 等521分代 Shenandoah 转正低延迟 GC 又多一个可选502Stable Values 预览JDK 26 里改名 Lazy Constants见下文503移除 32 位 x86 端口彻底告别 32 位四、JDK 26Leyden 再进一步final 终于要真不可变了JDK 26 于 2026 年 3 月 17 日 GA10 个 JEP。虽然非 LTS但有几条很值得关注。4.1 final 真正不可变JEP 500Java 的final字段其实一直有个后门通过深度反射可以修改它。很多框架早期 ORM、序列化库、测试 mock依赖这个后门。JDK 26 开始JVM会对通过深反射修改 final 字段的行为发出警告未来版本会直接禁止WARNING: Final field com.example.User#name has been mutated via reflection该做什么检查你依赖的框架是否还在改 final 字段升级到新版本通常已修复自己代码里的反射 hack 要改掉改用构造器注入或 VarHandle如确有必要可通过启动参数显式开启但只是过渡方案这是 Java「默认完整性integrity by default」路线的一部分——跟禁用 Security Manager、限制 JNI 是同一套思路。4.2 HTTP/3 支持JEP 517HTTP Client API 支持 HTTP/3代码几乎不用改HttpClientclientHttpClient.newBuilder().version(HttpClient.Version.HTTP_3)// 新增.connectTimeout(Duration.ofSeconds(10)).build();HttpResponseStringrespclient.send(HttpRequest.newBuilder(URI.create(https://example.com)).build(),HttpResponse.BodyHandlers.ofString());HTTP/3 基于 QUIC解决了 TCP 队头阻塞在高丢包、移动端网络上收益明显。微服务间通信如果跨公网或弱网环境值得试点。4.3 AOT 对象缓存支持任意 GCJEP 516JDK 24 的 AOT 缓存有个限制只能用 Serial GC 或 G1。26 里改成 GC 中立格式ZGC 也能用 AOT 缓存了。java-XX:AOTCacheOutputapp.aot-XX:UseZGC-jarapp.jarjava-XX:AOTCacheapp.aot-XX:UseZGC-jarapp.jar意义低延迟ZGC和快启动AOT不再二选一。4.4 Lazy ConstantsJEP 526第二次预览JDK 25 里叫 Stable ValuesJEP 50226 更名为Lazy Constants并进入第二次预览// 延迟初始化但 JVM 把它当真常量来优化跟 final 字段同等性能privatestaticfinalLazyConstantLoggerLOGGERLazyConstant.of(()-LoggerFactory.create(Expensive.class));voidlog(Stringmsg){LOGGER.get().info(msg);// 首次调用时初始化之后JVM可常量折叠}对比现有方案static final 静态块类加载时就初始化慢启动双重检查锁正确但啰嗦且 JVM 无法当常量优化LazyConstant延迟 JVM 级优化两者兼得对启动性能敏感的应用尤其是大量常量的 AI 推理服务很有价值。4.5 G1 吞吐量优化JEP 522降低应用线程与 GC 线程之间的同步开销提升 G1 吞吐。纯运行时改进升级即可获得无需改任何配置。4.6 其余五条JEP内容状态504移除 Applet API清理17 已废弃几乎无影响524PEM 编解码 API第二次预览25 首次525结构化并发第六次预览仍在打磨 API529Vector API第十一次孵化等 Valhalla 到位530基本类型模式匹配第四次预览结构化并发和 Vector API 是两条「长跑」特性一个六次预览一个十一次孵化。它们的共同点是都依赖更底层的项目Loom / Valhalla先落地。生产代码暂时别依赖它们但值得跟进——尤其结构化并发它会改变并发代码的写法。4.7 26 里那些没单列 JEP 但有用的改进支持HPKE混合公钥加密标准简化加密流程后量子算法签名 JAR供应链安全面向未来Unicode 17.0 / CLDR v48 更新HttpClient 支持区域型文件上传更严格的运行时镜像构建改进的 JVM 指标 APIJavaDoc 深色模式五、JDK 27默认即更快、更省、更安全JDK 27 于 2026-09-15 GA是 JDK 25 之后的第二个非 LTS下一个 LTS 是 29预计 2027-09。这一版只有9 个 JEP其中4 个转正、4 个预览、1 个孵化。它最显眼的特点不是新增 API而是两个 JVM 默认值的改变——你什么都不用做升级到 27 就自动「更快、更省内存」。5.1 G1 成为全环境默认 GCJEP 523转正自 JDK 9 起G1 就是「服务器级」环境≥2 核、内存约 2GB 以上的默认 GC但一旦环境受限单核或内存 1792MBHotSpot 以前会自动降级到 Serial GC。JDK 27 把这个「自动降级」逻辑整个拿掉# 不指定 GC 时无论 CPU 核数、内存大小一律 G1java-jarapplication.jar# 确实需要 Serial 的极小容器现在必须显式指定java-XX:UseSerialGC-jarapplication.jar# ZGC / Parallel / Shenandoah 等显式指定的不受影响java-XX:UseZGC-jarapplication.jar为什么现在敢这么改G1 这几年的原生内存占用持续下降JDK 26 的 JEP 522 又通过引入第二张卡表去掉了写屏障的同步开销G1 的吞吐已经追平 Serial。所以小容器用 G1 不会明显变慢却统一了心智模型——调优只需要聚焦「G1 还是 ZGC」二选一。⚠️配套清理-XX:AlwaysActAsServerClassMachine/-XX:NeverActAsServerClassMachine在 JDK 26 标记废弃JDK 27 直接移除。如果你的 Dockerfile / 启动脚本里还有这两个参数JVM 会打印Ignoring option ... support was removed in 27.0然后继续跑不阻断启动——但建议你顺手删掉。5.2 紧凑对象头默认开启JEP 534转正对象头从 96 bit12 字节压缩到 64 bit8 字节在 64 位 HotSpot 上默认生效——这是 Project Lilliput 的终章JDK 24实验特性JEP 450JDK 25转正但需手动开-XX:UseCompactObjectHeadersJEP 519JDK 27默认开启什么都不用加java-jarapp.jar# 27 起自动用紧凑布局java-XX:-UseCompactObjectHeaders-jarapp.jar# 遇兼容问题才需回退旧布局价值亚马逊在数百个生产服务上做过大规模验证官方给出的典型业务堆节省约20%微基准里纯小对象场景能到 ~29%但大数组 / 字符串几乎不受益。它和 25 那一条-XX:UseCompactObjectHeaders是同一件事——你之前手动加的开关在 27 上可以删了。5.3 后量子混合密钥交换 for TLS 1.3JEP 527转正JDK 24 的 JEP 496/497 把 ML-KEM / ML-DSA 的密钥生成 API带进了 JDKJDK 27 更进一步把后量子混合密钥交换直接焊进 TLS 1.3 握手混合hybrid把抗量子的 ML-KEM 与传统算法X25519 / ECDHE组合使用既防「现在被窃听、将来被破解」Harvest Now Decrypt Later又不会因 PQ 算法单点失效而降低现有安全性。零代码改动用javax.net.ssl的应用默认就获得这套更强握手不需要改一行代码。对跨公网 / 弱网的企业 AI 系统、业务关键链路最有意义——安全底座提前就位等量子威胁真正来临时不用紧急改造。5.4 JFR 进程内敏感数据脱敏JEP 536转正JFR 是生产诊断利器但它记录的启动信息里会包含命令行参数、环境变量、系统属性——这些值里常常躺着密码、API Key、Token、凭证。过去这些明文会出现在jdk.InitialEnvironmentVariable、jdk.InitialSystemProperty、jdk.JVMInformation等事件里一旦.jfr文件外发给支持团队或第三方分析就成泄露风险。JEP 536 做的是进程内脱敏——敏感信息在离开 JVM 进程之前就被抹掉。这意味着可以放心地把.jfr丢给外部团队排障满足合规 / 隐私要求同时不损失 JFR 的诊断价值对处理敏感客户 / 员工 / 受监管数据的 AI 系统尤其关键。5.5 预览与孵化特性继续推进JDK 27 里 4 个预览 1 个孵化基本是 25/26 那条线的延续没有新面孔JEP内容在 27 的状态提示531Lazy Constants第三次预览25 叫 Stable Values26 二预延迟常量 API 趋于稳定AI 推理服务友好532模式匹配支持基本类型第五次预览放开基本类型在instanceof/switch/ 模式里的限制AI 推理场景更顺手533结构化并发第七次预览仍不能上生产但值得持续跟进537Vector API第十二次孵化等 Valhalla 落地538PEM 编解码 API第三次预览25 首现26 二预密钥 / 证书 / CRL 的 PEM 编解码标准化结构化并发和 Vector API 依旧是「长跑」特性一个七次预览、一个十二次孵化都依赖更底层项目Loom / Valhalla。生产代码先别依赖但 JDK 27 已经把它们往前又推了一步。5.6 其他清理非 JEP 但值得知道移除实验性 JVMCI 特性JDK-8382582——此前依赖 JVMCI 的 GraalVM 企业版相关路径受影响社区版路线不受影响。TLS 默认命名组移除 ffdhe6144、ffdhe8192JDK-8373426——弱 DH 群组退出默认列表。AOT 增强-XX:AOTModerequired成为-XX:AOTModeon的别名JDK-8374348可强制要求 AOT 缓存命中。安全加固证书解析、TLS 证书处理、Jar 文件处理、认证检查多处增强JDK-8381796 / 8368041 / 8377833 / 8380672。易用性jcmd新增 bash 自动补全JDK-8357439IANA 语言子标签注册表更新到 2026-05-05TLS 1.3 的KeyUpdate消息行为调整。六、版本选型与迁移建议6.1 你现在该用哪个你的情况建议新项目JDK 25 LTS一步到位在 JDK 21 LTS 上评估升级到 25收益虚拟线程解 pinning、紧凑对象头、AOT、作用域值。21 支持到 2031 年不急可以等在 JDK 17 LTS 上建议规划升级到 25。17 的免费更新已陆续到期且 21→25 之间有大量收益在 JDK 8 / 11 上必须升级。除了新特性更关键的是安全更新与容器支持在 JDK 24 上立刻升级到 2524 已于 2025-09 停止更新无安全补丁想尝鲜JDK 26 / 27 可以试点 HTTP/3、Lazy Constants但别放生产核心链路非 LTS更新只维持 6 个月6.2 升级到 25/26/27 的避坑清单□ Security Manager 相关代码全部移除24 起永久禁用启动会失败或告警 □ JNI / FFM 使用处加 --enable-native-accessJEP 472 告警 → 未来禁止 □ sun.misc.Unsafe 内存访问方法替换JEP 498 告警 □ 32 位 x86 环境确认已淘汰25 起彻底移除 □ synchronized 密集的代码在 24 上重测并发解 pinning 后行为可能变化是变好但要验证 □ 反射修改 final 字段的地方整改JEP 500 开始告警 □ ZGC 用户确认已用分代模式非分代在 24 已移除 □ AOT 缓存需要「训练运行」要纳入构建/发布流程 □ 依赖库版本检查老版本 Netty / Kryo / Mockito / 序列化框架可能触发上述告警6.3 一个务实的渐进路线第一步低风险升级 JDK 版本不改代码加 -XX:UseCompactObjectHeaders → 直接拿到 8% CPU 22% 堆的收益 第二步中风险打开 AOT 缓存训练 运行两阶段 → 启动提速 20%-40%需要改发布流程 第三步需改造新代码用 ScopedValue 替代 ThreadLocal、用模块导入/紧凑 main 简化代码 → 长期可维护性收益 第四步观察跟进结构化并发、Vector API、Lazy Constants等转正后再引入七、这三年 Java 重心的转变回头看 JDK 24→27能清楚看到一条主线维度变化代表 JEP启动与预热从「JVM 天生慢启动」到 AOT 三连击483 / 514 / 515 / 516内存效率对象头压缩转正27 起默认开启再省一截450 / 519 / 534并发模型虚拟线程解 pinning配套逐步转正491 / 506 / 525安全与完整性后量子加密与 TLS 混合密钥交换、禁 SM、限 JNI、final 真不可变、JFR 脱敏486 / 472 / 496 / 497 / 500 / 527 / 536开发者友好语法糖持续简化511 / 512 / 513面向 AIVector API、Lazy Constants、HTTP/3、快速启动529 / 526 / 517最值得注意的一点Oracle 在 JDK 26 的官方宣传里反复强调这些特性「特别适合 AI 与云原生负载」——快速启动Serverless 友好、延迟常量AI 推理服务友好、Vector API向量计算、HTTP/3微服务通信。Java 正在主动把自己打造成 AI 应用的工程底座。小结四个版本一句话总结JDK 24把攒了几版的东西转正Stream Gatherers、Class-File API修好了虚拟线程 pinning 这个「隐形杀手」后量子加密首次落地Security Manager 彻底退场JDK 25 LTS新项目的默认选择。作用域值、紧凑对象头转正AOT 三连击大幅改善启动与预热JFR 能力跃升三个语法糖转正JDK 26Leyden 再进一步AOT 缓存支持任意 GC、HTTP/3 支持、final 开始真正不可变结构化并发与 Vector API 仍在长跑JDK 27非 LTS 但「默认即更快更省」——G1 全环境默认、紧凑对象头默认开启外加后量子 TLS 混合密钥交换和 JFR 敏感数据脱敏预览特性稳步推进等 JDK 29 LTS 再全面铺开立刻能做的三件事新项目直接上JDK 25 LTS加-XX:UseCompactObjectHeaders白拿 22% 堆 8% CPU把 AOT 缓存纳入发布流程启动提速 20%-40%