Java 25 LTS：下一轮生产升级的现实起点

分享日期：2026-06-10
主题：Java / JDK LTS 升级 / 虚拟线程生态 / 运行时性能

1. 为什么今天值得关注

Java 25 已在 2025-09-16 达到 GA，并且 OpenJDK 官方说明它会成为多数厂商的长期支持版本。对还停留在 Java 8、11、17，甚至刚完成 Java 21 升级的团队来说，Java 25 的意义不是“又多了一批语法糖”，而是把过去几轮预览、孵化和运行时优化集中到一个新的 LTS 基线里。

当前 Java 26 已进入 2026 年发布周期，但它不是 LTS。生产系统更值得优先评估 Java 25：它继承 Java 21 以来的虚拟线程路线，同时补齐上下文传递、结构化并发、对象头压缩、JFR 观测、KDF 安全 API 等落地点。

2. Java 25 的核心变化

2.1 Scoped Values 正式交付

ScopedValue 在 Java 25 中正式交付，用于在调用链和子线程之间共享不可变上下文。它最适合替代一部分 ThreadLocal 场景，例如请求 ID、租户信息、认证上下文、审计上下文。

和 ThreadLocal 相比，它的关键差异是：

• 值是单向传递的，调用链下游不能随意 set 改写上游上下文。
• 生命周期由代码块边界限定，执行结束后绑定自动失效。
• 与虚拟线程、结构化并发一起使用时，子任务可以继承上下文，但不需要为每个子线程复制一份线程本地存储。

简单示例：

    private static final ScopedValue<String> TRACE_ID = ScopedValue.newInstance();
    void handle(String traceId) {
        ScopedValue.where(TRACE_ID, traceId).run(() -> { 
            serviceCall(); 
        });
    }
    void serviceCall() {
        log.info("traceId={}", TRACE_ID.get()); 
    }

落地建议：不要把所有 ThreadLocal 机械迁移成 ScopedValue。优先选择“请求内只读上下文”这类场景；如果业务确实依赖中途改写或跨生命周期缓存，仍需保留现有模型或重新设计边界。

2.2 Structured Concurrency 继续预览，但 API 更接近定型

结构化并发在 Java 25 中是第五次预览。它的目标是把一组相关并发任务作为一个工作单元处理，从而让错误传播、取消、等待和观测更清晰。

典型收益：

• 任一子任务失败时，更容易统一取消其他子任务。
• 任务生命周期绑定在 try 作用域里，避免后台任务泄漏。
• 线程 dump、诊断和日志更容易看出父子任务关系。

适合先试点的代码：

• 聚合多个远程调用的接口。
• 同一请求内并行读取缓存、数据库、HTTP 服务。
• 原来用 ExecutorService + Future.get() 拼装并发结果的代码。

注意：这仍是 preview API，生产使用前需要明确编译、运行参数和未来 API 调整成本。

2.3 Compact Object Headers 成为产品特性

紧凑对象头从 Java 24 的实验特性变成 Java 25 的产品特性。它不是默认开启，但对对象数量巨大、堆占用敏感的服务很值得压测。

为什么它重要：

• 对象头变小，可能降低整体堆占用。
• 堆压力下降后，GC 频率和 CPU 消耗也可能下降。
• 对高并发 JSON 处理、缓存服务、内存型索引等对象密集场景尤其值得测试。

启用方式比 Java 24 简化：

java -XX:+UseCompactObjectHeaders -jar app.jar

落地建议：只在压测和灰度环境打开，不要直接全量启用。重点观察对象布局相关库、JNI、agent、序列化框架、监控探针是否存在兼容性问题。

2.4 KDF API 正式进入 Java 安全库

Java 25 新增并最终确定了 Key Derivation Function API。KDF 用于从密钥材料、盐值等输入中派生出新的密钥，是现代加密协议、混合公钥加密和后量子迁移路线中的基础能力。

对业务研发的直接影响：

• 不需要每个团队各自维护 HKDF 等派生逻辑。
• 安全提供方可以通过标准 javax.crypto 体系提供实现。
• 对接硬件加密模块、TLS 相关能力、后量子密码演进时更容易复用 JDK 标准能力。

落地建议：安全相关代码不要急于重写。先盘点自研 KDF、HKDF、密钥派生工具类，统一由安全团队评估迁移策略和测试向量。

2.5 小程序、脚本和教学代码更轻量

Java 25 最终确定了 compact source files 和 instance main methods。它降低了编写小型 Java 程序的样板代码成本，对教学、脚本、运维小工具、技术分享 demo 都有价值。

示例：

void main() { IO.println("Hello, Java 25"); }

这不是让 Java 变成脚本语言，而是降低进入门槛。大型工程仍然应该保持清晰的包结构、模块边界和构建规范。

3. 对团队的升级判断

建议优先升级的团队

• 当前在 Java 17 或 Java 21，依赖栈已经比较现代。
• 服务以 I/O 密集型为主，已经或准备使用虚拟线程。
• 对内存成本、启动路径、JFR 观测、安全能力有持续优化需求。
• 有稳定 CI、压测和灰度发布能力。

建议暂缓的团队

• 仍有大量 Java 8 专属依赖、老旧应用服务器或强绑定字节码增强工具。
• 线上 agent、APM、mock、热部署工具没有明确支持 Java 25。
• 构建链还没有统一 toolchain，开发机、CI、镜像版本不一致。

4. 迁移清单

1. 先把构建工具升级到支持 Java 25 的版本，包括 Maven/Gradle、编译插件、测试插件、代码扫描工具。
2. 用 jdeps、依赖扫描和 CI 全量测试找出非法反射、内部 API、废弃 API 和 agent 兼容性问题。
3. 先在非核心服务跑 Java 25，不要同时改业务逻辑和 JDK 版本。
4. 对虚拟线程、ScopedValue、结构化并发单独做试点，不和 JDK 升级强绑定上线。
5. 针对 -XX:+UseCompactObjectHeaders 做 A/B 压测，保留独立开关。
6. 建立 Java 25 基础镜像，确保本地、CI、测试、生产运行时一致。

5. 一句话总结

Java 25 LTS 的价值不在于单点语法变化，而在于它把 Java 21 之后的并发模型、上下文传递、运行时内存优化和安全 API 汇总成了新的长期支持基线。对生产团队来说，最务实的动作是现在开始兼容性验证，把升级拆成“先换运行时，再试新能力”两步走。

参考资料

• OpenJDK JDK 25 项目页
• JEP 506: Scoped Values
• JEP 505: Structured Concurrency
• JEP 519: Compact Object Headers
• JEP 510: Key Derivation Function API
• JEP 512: Compact Source Files and Instance Main Methods