JDK 27 正式发布｜9大JEP核心特性全面解析

2026 年 9 月 15 日，Oracle 正式发布了 JDK 27，对应 JSR 402，是 Java SE 27 的参考实现。

说实话，每次 Java 发布新版本，我都会习惯性看一眼 JEP 列表，然后判断“这个版本值不值得升级”。

很多版本是“预览版加预览版”，真正能落到生产环境的东西不多。

但 JDK 27 不太一样。

它包含 9 项足以单独成为 JEP 的增强，其中 4 项是预览功能、1 项是孵化器功能。

更重要的是，其中有几项是默认行为变更——也就是说，你什么都不做，升级 JDK 就能受益。

今天这篇文章，我就把 JDK 27 的核心变化从头到尾给你拆解一遍。

希望对你会有所帮助。

一、JDK 27 到底变了什么？

在深入每个特性之前，我先用一张表帮你建立整体认知。

这 9 项 JEP，我按“对普通开发者影响程度”从高到低排列，逐一拆解。

二、G1 成为所有环境的默认 GC

这是最大的变化。

有些小伙伴在工作中可能遇到过这样的场景：写了个小工具、跑了个批处理脚本，启动的时候发现用的是 Serial GC——单线程回收，启动快但一旦数据量上来就卡得不行。你以为是代码问题，其实是 GC 选错了。

从 JDK 9 开始，G1 就已经是服务器环境的默认 GC。

但如果你在一个内存受限的环境里跑 Java——比如小容器、嵌入式设备、或者一个简单的命令行工具——JVM 会默认选择 Serial GC。

Serial GC 的问题很明显：单线程，Full GC 时会长时间停顿。

在小内存场景下，你可能感觉不到；但一旦数据量稍微大一点，停顿时间就会变得不可接受。

JDK 27 的 JEP 523 把这件事改了：G1 成为所有环境的默认 GC，不再区分服务器和受限环境。

2.1 为什么敢这么做？

Oracle 在 JEP 里给出了明确的理由：经过这些年的持续优化，G1 在所有指标上都已经和 Serial 持平了。

具体来说：

吞吐量：JDK 27 中减少了 G1 的同步开销（JEP 522），G1 的最大吞吐量已经接近 Serial。

延迟：G1 在老年代回收时走的是增量回收，而不是 Serial 那种全量回收，所以最大延迟一直比 Serial 好。

原生内存：最近几个版本把 G1 的原生内存占用降到了和 Serial 相当的水平。

启动时间：在小堆场景下，G1 的启动开销已经优化到不再明显。

2.2 对你意味着什么？

什么都不用改。

你升级到 JDK 27，不指定 GC 参数，JVM 自动用 G1。

如果你之前在小内存环境里被 Serial GC 的 Full GC 停顿折磨过，升级 JDK 27 后这个问题会自动消失。

当然，如果你需要极致启动速度，仍然可以显式指定 Serial：-XX:+UseSerialGC。

但默认情况下，G1 已经是更好的选择。

三、紧凑对象头成为默认

对象头从 96 位砍到 64 位。

这是另一个默认行为变更，而且是“悄悄生效”的那种。

3.1 对象头里到底存了什么？

Java 对象在堆里是怎么存的？

每个对象都有一个“对象头”，里面至少包含 Mark Word 和 Klass Pointer 两部分。

在 64 位 JVM 上，传统布局是：

• Mark Word：64 位（哈希码、GC 年龄、锁状态等）
• Klass Pointer：64 位（指向类元数据）

对象头总共 96 位，也就是 12 字节。

加上对象体，一个最简单的new Object()，在 64 位 JVM 上实际占用 16 字节（对象头 12 字节 + 对齐填充 4 字节）。

3.2 紧凑对象头怎么做的？

JEP 534 把 Klass Pointer 从 64 位压缩到了 32 位，对象头总共变成 64 位，即 8 字节。

为什么能压缩？

因为 JVM 的类元数据空间（Metaspace）通常不会超过 4GB（32 位地址空间足够寻址）。

Klass Pointer 其实只需要存一个索引，不需要完整的 64 位地址。

效果：new Object()从 16 字节降到 12 字节（8 字节对象头 + 4 字节对齐填充）。堆占用直接减少**25%**。

3.3 为什么这很重要？

堆占用减少 25%，意味着：

• 同样的内存能装更多对象
• GC 压力更小（对象少了，扫描和回收的负担就小了）
• 数据局部性更好（对象更紧凑，CPU 缓存命中率更高）

对于大规模 Java 应用——特别是那些创建大量小对象的场景——这是一个实打实的性能提升。

紧凑对象头从 JDK 24 开始就是可选功能，经过两个版本的验证，JDK 27 正式把它设为默认。

和 G1 一样，你不需要做任何事，升级就生效。

四、TLS 1.3 后量子混合密钥交换

为“量子时代”提前上锁。

“量子计算离我还远着呢，跟我有什么关系？”

这个问题我被问过不止一次。我的回答是：等量子计算能破解 RSA 的那一天，你今天的加密数据可能已经被存了好几年了。

攻击者的策略叫“先存后破”——现在把加密流量存下来，等量子计算机成熟了再解密。所以后量子加密不是“未来的事”，是“现在就要做的事”。

4.1 JEP 527 做了什么？

JDK 27 为 TLS 1.3 引入了后量子混合密钥交换算法。

所谓“混合”，就是把抗量子算法和传统算法结合起来——即使量子计算破解了传统算法那一半，抗量子算法那一半仍然安全。

新增的算法包括：

• X25519MLKEM768（默认组列表中优先级最高）
• SecP256r1MLKEM768
• SecP384r1MLKEM1024

4.2 关键点：默认启用，无需改代码

如果你用的是 javax.net.ssl API，升级 JDK 27 后，这些算法默认就会生效，不需要修改任何代码。

这意味着：你现有的 HTTPS 通信，在升级 JDK 27 后，自动获得了后量子加密保护。

五、惰性常量

它是 AI 和数据应用的性能利器。

惰性常量（Lazy Constants）是第三次预览了，但这个特性的价值值得反复说。

5.1 它解决什么问题？

Java 里传统的 static final 常量在类加载时就必须初始化。

如果你的常量需要昂贵的计算——比如从数据库加载配置、解析一个大文件、初始化一个 ML 模型——那类加载就会变得很慢。

惰性常量允许你延迟初始化，而且 JVM 会把它当成真正的常量来优化——性能等价于 final 字段。

5.2 代码示例

// 传统的 static final——类加载时就得算
public static final List<Config> CONFIGS = loadFromDatabase();

// 惰性常量——用到的时候才算
private static final LazyConstant<List<Config>> CONFIGS = 
    LazyConstant.of(() -> loadFromDatabase());

// 第一次调用时初始化，之后直接走缓存
public List<Config> getConfigs() {
    return CONFIGS.get();
}

为什么这跟 AI 有关？

因为 AI 应用里大量存在这种场景——模型权重、tokenizer 词表、向量索引，都是初始化昂贵但后续只读的数据。

惰性常量让这些数据可以按需加载，同时不牺牲运行时的性能。

六、原始类型模式匹配

switch 终于支持 int 了。

这是第五次预览，但每预览一次，就离正式版更近一步。

6.1 解决了什么痛点？

以前的 switch 只能匹配引用类型（String、enum、包装类）。

你要匹配 int，只能用传统的 switch-case，没法用模式匹配的威力。

JEP 532 允许原始类型用于模式匹配、instanceof 和 switch。

6.2 代码对比

// 以前：int 匹配只能这样写
switch (statusCode) {
    case 200:
        return "OK";
    case 404:
        return "Not Found";
    default:
        return "Unknown";
}

// JDK 27 预览：可以用模式匹配了
Object obj = getStatusCode();
return switch (obj) {
    case int i when i == 200 -> "OK";
    case int i when i == 404 -> "Not Found";
    case String s -> "String: " + s;
    default -> "Unknown";
};

同时，这个 JEP 还加强了 switch 的支配性检查，让编译器能在编译期发现更多错误。

七、结构化并发

结构化并发第七次预览了。

虽然还是预览，但它的思路值得每个 Java 开发者关注。

7.1 传统并发的问题

// 传统写法：两个任务并发，但错误处理一团糟
Future<User> userFuture = executor.submit(() -> fetchUser(id));
Future<Order> orderFuture = executor.submit(() -> fetchOrder(id));

try {
    User user = userFuture.get();
    Order order = orderFuture.get();
    return new Result(user, order);
} catch (Exception e) {
    // 一个失败了，另一个还在跑，怎么取消？
    // 线程泄漏怎么办？
    throw e;
}

问题在于：这两个任务的生命周期没有和父任务绑定。

父任务失败了，子任务可能还在跑；子任务失败了，父任务不知道该怎么取消另一个。

7.2 结构化并发的写法

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Supplier<User> user = scope.fork(() -> fetchUser(id));
    Supplier<Order> order = scope.fork(() -> fetchOrder(id));
    
    scope.join();           // 等待所有子任务
    scope.throwIfFailed();  // 任一失败则抛出
    
    return new Result(user.get(), order.get());
}
// 离开 try 块时，scope 自动关闭，所有未完成的子任务自动取消

核心价值：子任务的生命周期严格嵌套在父任务内。父任务失败，子任务全部取消；子任务失败，父任务感知并处理。没有线程泄漏，没有孤儿任务。

八、Vector API

它是 AI 推理的加速器。

Vector API 第十二次孵化了。

虽然还在孵化阶段，但它在 AI 推理和科学计算领域的价值已经非常明确。

Vector API 允许开发者在支持的 CPU 上利用 SIMD 指令——一条指令同时处理多个数据。

对于矩阵运算、向量相似度计算这类 AI 推理中高频出现的操作，性能提升可以是数量级的。

// 向量加法——一次处理多个 float
FloatVector a = FloatVector.fromArray(SPECIES, arr1, i);
FloatVector b = FloatVector.fromArray(SPECIES, arr2, i);
FloatVector c = a.add(b);
c.intoArray(result, i);

如果你的 AI 应用跑在支持 AVX-512 或 ARM SVE 的 CPU 上，Vector API 能把这些硬件的向量计算能力直接暴露给 Java 代码。

九、其他值得关注的改进

除了 9 项 JEP，JDK 27 还有几十项非 JEP 改进：

JEP 536：JFR 进程内数据脱敏——JDK Flight Recorder 在记录离开进程前，对命令行参数、环境变量和系统属性进行脱敏。生产环境做性能分析时，不会再意外泄露密钥。

ML-KEM/ML-DSA 私钥编码更新——后量子密码算法的密钥编码标准化，X25519 和 Ed25519 性能提升。

JSON 线程转储——线程转储中的线程标识、线程数和进程标识改为 JSON 数字，监控工具解析更方便。

jcmd VM.security_properties——新增命令，可在运行时查看活动的安全属性。

移除 JVMCI——部分旧选项和功能被移除。

十、优缺点

优点

1. G1 全场景默认，小内存环境不再受 Serial GC 折磨吞吐量、延迟、内存占用、启动时间全面持平甚至优于 Serial，默认用 G1 是更安全的选择。

2. 对象头砍到 64 位，堆占用降低 25%同样的内存能装更多对象，GC 压力更小，数据局部性更好。大规模应用直接受益。

3. 后量子加密默认启用，无需改代码用 javax.net.ssl 的应用自动获得抗量子攻击能力。这是安全层面的基础性升级。

4. 惰性常量为 AI/数据应用优化模型权重、向量索引等昂贵初始化数据可以按需加载，运行时性能等价于 final。

5. 结构化并发让并发编程更可靠子任务生命周期严格嵌套，没有线程泄漏，没有孤儿任务。

6. JFR 数据脱敏，生产环境更安全性能分析时不会意外泄露密钥和环境变量。

注意事项

1. 非 LTS 版本，生产环境需谨慎 JDK 27 不是 LTS，Oracle 更新到 2027 年 3 月。生产环境建议用 JDK 25 LTS。

2. 预览/孵化特性需要–enable-preview 惰性常量、原始类型模式匹配、结构化并发、Vector API 都需要显式启用预览标志，且可能与未来版本不兼容。

3. JVMCI 被移除如果你用了 Graal JIT 编译器（基于 JVMCI），需要确认兼容性。

4. 紧凑对象头可能影响某些诊断工具依赖对象头布局的工具（如某些 Profiler）可能需要更新。

十一、适用场景

十二、写在最后

回到最初的问题：JDK 27 值不值得升级？

我的判断是：值得尝鲜，但生产环境等 JDK 28 或 JDK 29 LTS 更稳妥。

JDK 27 最大的价值不在于某个“炫酷的新语法”，而在于三个默认行为变更：

G1 成为全场景默认——你什么都不做，启动更快、延迟更低。

对象头砍到 64 位——你什么都不做，堆占用降 25%。

后量子加密默认启用——你什么都不做，HTTPS 通信就获得了抗量子保护。

这三件事加起来，是实打实的运行时收益，不是“预览版的预览版”。

预览特性里，结构化并发和惰性常量是最值得关注的。

结构化并发如果转正，会改变 Java 并发编程的写法；惰性常量如果转正，会成为 AI 应用的标配。

JDK 27 不是 LTS，如果你现在的生产环境跑在 JDK 21 或 JDK 25 LTS 上，不用急着升。

但如果你在开发新项目、跑实验环境、或者想提前感受 Java 的演进方向——JDK 27 值得下载跑一跑。

以上关于JDK 27 正式发布｜9大JEP核心特性全面解析的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。