JDK 25 新特性

• Spring Boot 4.x 的最低 Java 版本要求与实际支持范围
• JDK 25 与 Spring Framework 7 的兼容矩阵
• 升级到 JDK 25 时对 Spring Boot 4.1.0 应用的影响点

Spring Boot 4.0 起将基线提升到 Java 17，同时支持更高的 Java 版本。Spring Boot 4.1.0 与 JDK 25 兼容，官方支持在其发布时已正式支持的 JDK 版本上运行。JDK 25 是 LTS 版本（2025 年 9 月发布），Spring Boot 4.1.0 针对其进行了验证，包括部署若干部件（如嵌入式 Tomcat、Jetty、Undertow）与 JDK 25 的字节码版本、虚拟线程集成和反射访问。JDK 17 基线意味着 Spring Boot 4.x 编译的字节码版本为 61（Java 17），因此可以在 JDK 25 的高版本 JVM 上无缝运行，同时利用 JDK 17+ 的虚拟线程、记录类和 sealed 类等特性。

Spring Boot 4 与 Spring Framework 7 对齐，将基线提升背后的动机是弃用老旧的 Java 8/11 支持成本，并充分利用记录类、虚拟线程等现代特性。JDK 25 作为 LTS，Spring Boot 4.1.0 官方声明支持，为生产环境提供了长期稳定的升级路径。JDK 25 的字节码版本为 69，Spring Boot 4.1.0 编译产物使用 61 版本，因此高版本 JVM 可向下兼容执行。

• JEP 451 的动态 Agent 加载警告机制
• 自附加（self-attach）日志告警的触发条件
• 字节码工具与 Agent 的常见告警场景

JEP 451（JDK 21）对动态加载的 Java Agent 增加了一条警告，当运行中的 JVM 通过 com.sun.tools.attach 动态附加并在启动后加载 Agent 时，JDK 会打印类似 "WARNING: A Java agent has been loaded dynamically" 的日志。Byte Buddy、Mockito inline mock 和 APM（如 Datadog、New Relic）类工具都依赖在应用启动后动态附加 Agent 并重写字节码，因此这些工具在每次启动时都会触发该警告。JDK 21 起用户可通过 -XX:+EnableDynamicAgentLoading 显式允许动态加载且不再打印警告，或使用 -XX:-EnableDynamicAgentLoading 禁用动态 Agent 加载以增强安全性。

该警告并非错误，而是 JDK 出于安全与可维护性考虑，暴露动态修改运行中 JVM 的行为。它推动工具链在应用启动时通过命令行参数（-javaagent）提前加载 Agent，而不是运行中自附加。Mockito 5.0 起默认使用 inline mock maker，需要动态附加以支持 final 类 mock，因此会触发该警告。

• GraalVM 版本号与 Oracle JDK 版本的对齐策略
• GraalVM 25+ 对 JDK 25 的支持
• 原生镜像与 AOT 的配合

从 GraalVM for JDK 20（20.0.0）起，GraalVM 的版本号与 Oracle JDK 保持一致（23.0 及之前为旧编号方案），GraalVM 25 对应 JDK 25，GraalVM 25.0 之后提供基于 JDK 25 的发行版。GraalVM 25+ 支持 JDK 25 的新特性（如分代 ZGC、AOT 缓存等），并针对 JDK 25 的字节码与 API 进行了适配。两者对齐意味着 GraalVM Native Image 与 JDK 25 的 AOT 缓存（JEP 483/514）可以协同工作，Spring Boot 4.x 的 AOT 处理也同时面向 GraalVM 原生镜像与 JDK 25 的 CDS/AOT 缓存。

版本号对齐简化了用户的选型与升级心智：当 JDK 升级到 25，对应使用 GraalVM 25 即可获得一致的特性集。GraalVM 25 的 Native Image 与 Project Leyden 的 AOT 缓存都做"提前优化"，但理念不同，前者是闭世界分析，后者是渐进式 CDS/AOT 缓存。

• 虚拟线程在 JDK 25 的稳定状态
• JFR 对虚拟线程的诊断事件
• 结构化并发与虚拟线程的配合

JDK 25 中虚拟线程（Loom）已完全稳定，JFR 提供 jdk.VirtualThreadStart、jdk.VirtualThreadEnd、jdk.VirtualThreadPinned、jdk.VirtualThreadSubmitFailed 等事件，用于监控虚拟线程的创建、挂起、钉住与调度失败。结构化并发（StructuredTaskScope）仍为预览特性（JDK 24 的 JEP 499 为第四次预览、JDK 25 的 JEP 505 为第五次预览），JDK 25 继续与虚拟线程深度协作，让任务层次清晰、取消传播可预测。JDK 25 还改进了 Thread.sleep 的精度，配合虚拟线程的调度，使高并发 I/O 应用可观测性更强。

虚拟线程生态的价值在于"轻量并发 + 可观测"，JFR 让百万级虚拟线程的调度与钉住问题可被诊断。JDK 25 延续了 Loom 的成熟路线，将虚拟线程与结构化并发、JFR 诊断整合为完整方案。

• Thread.sleep 的精度与操作系统调度的关系
• 忙等待与睡眠的权衡
• JDK 25 的改进实现

JDK 25 对 Thread.sleep 的精度做了改进（JDK 运行时增强，非 JEP），提高了其在短时睡眠（微秒级）下的精度。此前 short sleep 依赖 OS 定时器，可能因线程调度器的最小睡眠粒度（如 1ms 或 10ms）而显著超时。JDK 25 采用混合策略：对于极短睡眠（低于某个阈值）使用忙等待（busy-wait）以避免睡眠过长的延迟，对于较长睡眠仍使用 OS 原语。这在虚拟线程中尤其重要，因为虚拟线程的调度依赖精确的睡眠。

精度改进的关键是权衡 CPU 占用与延迟。忙等待会消耗 CPU，但避免了 OS 定时器击穿导致的延迟抖动。JDK 25 根据睡眠时长自动选择策略，兼顾了精度与功耗。对虚拟线程而言，精确的 sleep 让调度更公平。

• 分代 ZGC 的引入与默认化进程
• 分代模式的堆行为与参数变化
• 回退能力的移除

JEP 439（JDK 21）首次引入分代 ZGC，提供 -XX:+ZGenerational 开关（默认关闭），吞吐率更高、暂停时间更短，但仍是实验性。JEP 474（JDK 23）将分代 ZGC 设为默认（-XX:+ZGenerational 成为默认），并弃用非分代模式。JEP 490（JDK 24）移除了非分代 ZGC，分代成为唯一模式，-XX:+ZGenerational 不再需要，启动参数统一为 -XX:+UseZGC。堆行为上，分代 ZGC 将堆分为年轻代与老年代，通过并发标记与重定位降低暂停，适合更大的堆；回退能力从"可在分代/非分代间切换"退化为"只能使用分代"，简化了维护与参数面。

三步走展示了 JDK 特性从实验到默认再到移除的完整生命周期：先引入实验特性验证，再默认化推广，最后清理非分代实现以降低维护成本。用户在 JDK 24+ 上不再使用 -XX:+ZGenerational，只需 -XX:+UseZGC。

• AOT 缓存的一步式与两阶段流程差异
• 子进程预留堆的原因
• 方法画像的采选与失效识别

传统 CDS/AOT 流程是 record/create 两阶段：先用 record 阶段记录类加载与 AOT 编译信息，再在 create 阶段生成缓存。JEP 514 提供一步式 -XX:AOTCacheOutput，在训练运行中直接生成 AOT 缓存，省去显式中间步骤。一步式需要为子进程预留额外堆，因为 AOT 编译在子进程中进行，需要堆空间来编译与缓存，主进程堆不变，故需额外预留避免 OOM。JEP 515 将方法执行画像（profile）写入 AOT 缓存，使 JVM 在启动时更早地应用优化。选择训练流量需覆盖代表性路径（如健康检查、核心 API、热路径），识别画像偏斜需对比训练与生产流量分布；缓存失效可通过 JFR 的 AOT 缓存未命中事件或比较缓存命中率来识别。要证明收益来自更早优化而非普通 CDS，可对比"仅 CDS"与"CDS+AOT 画像"两种配置的启动时间与首请求延迟，并观察 JIT 编译计数（AOT 命中时的编译次数更低）。

一步式流程简化了训练，但资源开销更大（子进程堆），需在构建时权衡。收益归因的关键是控制变量：单独启用 CDS 与启用 AOT 缓存对比，确保差异来自 AOT 的提前优化而非类加载加速。

• ML-KEM 与 ML-DSA 的用途差异
• 密文/签名尺寸与性能对比
• 失败语义（解密失败 vs 校验失败）

ML-KEM（JEP 496，FIPS 203）是密钥封装机制（KEM），用于封装/解封装共享秘密，输出密文约 800~1600 字节（取决于参数），失败语义是解封装时因密文篡改或密钥不匹配而失败。ML-DSA（JEP 497，FIPS 204）是数字签名算法，用于签名/验签，输出签名约 2.4~4.6 KB，失败语义是验签时因签名或消息被篡改而失败。性能上，ML-KEM 的封装/解封装通常比 ML-DSA 的签名/验签更快，且两者都显著快于基于格的旧方案（如哈希签名），但密钥尺寸较大。用途上，ML-KEM 用于密钥交换（如 TLS），ML-DSA 用于身份认证与数据完整性。

两者都是后量子密码（PQC）标准，但解决不同问题：KEM 负责保密性（建立共享密钥），签名负责认证与完整性。尺寸与性能差异决定了它们的适用场景，TLS 中通常两者结合（KEM 做握手密钥交换，签名做证书认证）。

• KEM API 的职责边界
• KDF API 的密钥派生
• 用途隔离（domain separation）的 AEAD 密钥

JEP 452 的 KeyEncapsulation (KEM) 只负责产生共享秘密：encapsulate 生成密钥与密文，decapsulate 恢复共享秘密。JEP 510 的 KDF API 提供基于 HKDF 等的密钥派生函数，可将共享秘密作为输入，结合上下文（context）与标签（label）派生出用途不同、互不干扰的 AEAD 密钥。KDF 的输入包含"信息"字段（如协议名称、用途标签），确保不同用途派生的密钥彼此独立（domain separation），即使同一共享秘密派生出加密密钥与认证密钥，也不会互相泄露。派生出的密钥再用于 AES-GCM 等 AEAD 加密。

KEM 与 KDF 的分离遵循"单一职责"：KEM 只负责封装，KDF 负责把共享秘密扩展为多个用途隔离的密钥。用途隔离通过 KDF 的上下文信息实现，是 TLS 等协议的标准做法（如 HKDF-Expand）。

• Markdown 注释的语法差异
• 段落、代码块、链接与内联标签
• javadoc -Xdoclint 的校验

JEP 467（JDK 23）定稿 Markdown Documentation Comments，开发者可用 /// 前缀书写 Markdown 风格的文档注释。差异在于：段落通过空行分隔（而非 @author 等标签），代码块用反引号/缩进（而非

），链接用 Markdown 语法 text（而非 {@link}），内联标签用 {@code ...} 与 Markdown 反引号均可。传统 Javadoc 标签（如 @param、@return）仍可用。迁移大型 API 文档时，javadoc -Xdoclint 会检查文档注释的语法、链接与标签错误，包括无效的 {@link} 引用、断开的 Markdown 链接、缺失的 @param/@return 等，从而在编译期发现链接或示例静默失效的问题，避免文档生成后才发现错误。

Markdown 注释降低了书写门槛，但混合语法（传统 Javadoc 标签 + Markdown）需要工具校验。javadoc -Xdoclint 提供静态检查，可配置为 -Xdoclint:all 或按需开启，确保迁移过程不破坏文档的链接与示例。

• Security Manager 的弃用与禁用
• 禁用的方式与影响
• 存量代码的迁移

JEP 486（JDK 24）永久禁用 Security Manager：System.setSecurityManager 与 SecurityManager 构造器在运行时抛 UnsupportedOperationException，此前（JDK 17-23）的 -Djava.security.manager 属性与启用开关被移除。这一变更意味着依赖 SecurityManager 权限模型（如自定义 SecurityManager、AccessController.doPrivileged）的存量代码无法再运行，必须迁移到其他机制（如 JEP 500 的 final 字段完整性、模块限定、或重新设计权限模型）。JDK 24 中调 SecurityManager 相关 API 会直接报错。

Security Manager 自 JDK 17 弃用（JEP 411），JDK 24 永久移除。这是 JDK 走向"integrity-by-default"的一部分，减少对权限检查的依赖，鼓励使用语言级与模块级约束。JDK 26 中的相关存量代码（如依赖 SecurityManager 的框架）需提前迁移。

• -Xlog 的统一日志框架
• 新增的日志标签与输出
• 与 GC、JIT、AOT 相关的日志

统一日志框架（-Xlog）在 JDK 9 引入，JDK 25 持续增强，包括新增 AOT 缓存（JEP 483/514）相关日志标签、改进 GC 日志的详细级别（如分代 ZGC 的分配/重定位日志）、以及新的 JIT 编译日志。开发者可通过 -Xlog:gc*,aot*,jit* 等组合输出更细粒度的诊断信息，并配合时间戳、进程号与线程号输出到文件。JDK 25 的 -Xlog 增强使 AOT 缓存命中/未命中、GC 分代行为等更可观测。

统一日志的价值在于一致的格式与可配置的过滤。JDK 25 随新特性（AOT、G1 同步削减、分代 GC）扩展日志标签，帮助开发者定位性能与启动问题。

• JEP 521 的内容
• JIT 与 GC 的优化
• 对吞吐与延迟的影响

JEP 521（Generational Shenandoah）是 JEP 521 转正为产品特性但默认仍为单代的 JEP：分代模式让大多数对象在年轻代回收、减少并发扫描工作量，在保持低暂停的同时提升吞吐，尤其适合大堆与延迟敏感场景。JDK 25 还通过 JEP 509 引入 JFR CPU-Time Profiling 实验特性，增强性能诊断能力。

JEP 521 将分代 Shenandoah 设为默认模式，使低暂停 GC 在 JDK 25 中开箱即用。分代化降低并发回收开销，是大堆与延迟敏感场景的 GC 演进方向。

• Javadoc 工具与文档格式的改进
• Markdown 文档注释的延续
• 文档搜索与导航

JDK 25 延续 JEP 467 的 Markdown 文档注释支持，并增强 Javadoc 工具：改进文档搜索、导航与可访问性，支持更丰富的代码与链接渲染。标准库新增 API 的文档同步更新，包括 AOT、HTTP/3（JEP 517 在 JDK 26）、KEM/KDF 等新特性。JDK 25 的 Javadoc 增强还包括对超大文档集的性能优化与更好的错误报告。

文档演进关注开发者体验（DX），Markdown 化、搜索增强与可访问性让 API 文档更易维护与使用。JDK 25 作为 LTS，文档质量直接影响长期采用。

• jpackage 的打包改进
• jlink 的模块化与运行时裁剪
• 与 AOT、CDS 的配合

JDK 25 改进 jpackage 与 jlink：jpackage 增强了对新平台（如 macOS 的 arm64、Windows 的安装包签名）的支持与自定义 icon 的能力；jlink 改进对模块化运行的裁剪性能，并支持在链接时生成 CDS/AOT 缓存（配合 JEP 483/514），使生成的定制运行时启动更快。两者结合可用于生成更小、启动更快的自包含应用。

jlink 裁剪运行时、jpackage 打包分发的组合，配合 AOT 缓存，是 JDK 25 面向"云原生与桌面分发"的优化主线。工具链改进让应用体积更小、启动更快。

• 未命名变量 _ 的作用域与生命周期
• JEP 456 转正后的行为
• String Templates 撤回重做的原因

_ 未命名变量在 JDK 21 作为预览（JEP 443），到 JDK 22 转正（JEP 456）。转正后 _ 只能作为未命名变量使用，不可再作为普通标识符（Java 9 起已禁止 _ 作为标识符），且每个 _ 可独立使用，不绑定值，不占用作用域。生命周期上，预览期间需 --enable-preview，转正后默认可用。JEP 430 String Templates 经过两轮预览（JDK 21、22）后被撤回重做，原因是插值处理器（FMT）的设计在组合性与安全性上存在争议：字符串模板与处理器组合的边界、插值上下文的安全（如 SQL 注入、日志注入）难以统一，导致其长期未转正。团队应通过将预览语法隔离在独立模块/类中、使用 --enable-preview 按需编译、并避免在公共 API 中暴露预览依赖来降低风险。

预览特性生命周期（Preview → 转正或撤回）反映 JDK 对语法设计审慎。_ 转正后作用域更清晰；String Templates 撤回说明"可行不一定可转正"，安全边界与组合性需更严谨设计。团队隔离预览依赖可避免特性变更对生产代码的冲击。

• PEM 编码格式
• 支持的密码学对象
• 预览特性状态

JEP 470（JDK 25，Preview）为 JDK 提供一个统一的 PEM 编码 API，用于读写 PEM 格式的密码学对象。PEM 是常见的文本格式（BEGIN/END 包裹的 Base64 数据），之前 JDK 仅在私钥、证书等特定场景支持 PEM。JEP 470 提供通用的 PEM 编码/解码 API，支持密钥、证书、证书链、CRL 等对象。作为预览特性，需 --enable-preview 使用。JDK 26 中 JEP 524 提供第二次预览，并进一步改进 API。

PEM 编码是安全互操作的基础（广泛用于 TLS、密钥交换）。统一 API 消除了过去各对象各自处理 PEM 的零散状态，提升密码学互操作性。仍为预览说明 API 未完全定型。

• Stable Values 的概念
• 与 final 字段、单例的关系
• 预览特性状态

JEP 502（JDK 25，Preview）引入 Stable Values，允许声明可在首次初始化后稳定不变的字段，类似于"可延迟初始化的 final 字段"。它让类在首次访问时计算并缓存一个值，之后保持不变，且不触发类的完整初始化（避免类初始化锁）。Stable Values 常用于单例、缓存与配置值，提供比 final 更灵活的延迟初始化。JDK 26 中 JEP 526 将其重命名为 Lazy Constants 并第二次预览。

Stable Values 解决"final 字段必须构造时赋值"的限制，提供"按需初始化且只初始化一次"的语义，同时避免类初始化顺序问题。它在 JVM 层面支持这种惰性单次赋值，减少重复计算。

• Scoped Values 的绑定与运行
• 与 ThreadLocal 的对比
• 常见应用模式

JEP 506（JDK 25）将 Scoped Values 定稿为最终版。Scoped Values 通过 ScopedValue.where(key, value).run(...) 绑定值，在结构化并发作用域内让线程（包括虚拟线程与子任务）读取，且不可变、不可继承给任意线程。应用模式包括：在请求级传递用户身份、请求 ID、事务上下文（替代 ThreadLocal 避免泄漏与可变）；配合 StructuredTaskScope 派生子任务传播上下文；在虚拟线程下高并发安全传递上下文。相比 ThreadLocal，Scoped Values 不可变、有明确生命周期、不泄漏给无关线程，是推荐替代。

Scoped Values 的核心价值是"绑定的作用域内安全共享不可变上下文"，与结构化并发（StructuredTaskScope）天然契合，解决了 ThreadLocal 的泄漏、可变与继承混乱问题。JDK 25/26 继续推荐在 Web 请求、虚拟线程场景使用。

• Vector API 的 SIMD 化
• 孵化状态
• 与 C2 的合作

JEP 508（JDK 25，10th Incubator）继续孵化 Vector API。Vector API 提供表达 SIMD（单指令多数据）向量运算的 Java API，让开发者显式写出向量化计算，由 C2 编译器生成高效的向量指令（AVX、NEON 等）。API 支持 IntVector、FloatVector、LongVector 等，以及向量掩码、广播、归约等操作。经过 10 次孵化仍未转正，说明 API 设计仍在演进，JDK 26 的 JEP 529 提供第 11 次孵化。

Vector API 的价值是让 Java 获得接近手写 SIMD 的性能，同时保持可移植性（平台不支持时自动回退标量）。多次孵化反映 API 在设计函数式向量运算与平台抽象上的复杂性。

• JFR 的 CPU 取样
• 实验特性状态
• 与采样剖析的对比

JEP 509（JDK 25，Experimental）引入 JFR CPU-Time Profiling，通过 JFR 提供基于 CPU 时间的剖析（CPU-time profiling），这与传统的 wall-clock 采样不同，能更准确地反映线程实际消耗 CPU 的时间分配。它利用 JFR 事件记录每个线程的 CPU 时间，帮助定位 CPU 热点与线程竞争。作为实验特性，需 -XX:+EnableJFRCpuTimeProfiling 或相关开关启用。

CPU-time 剖析比 wall-clock 更能反映纯计算热点，减少 I/O 等待与调度噪声的干扰。JFR 将其整合为事件流，便于生产环境持续剖析，是 JDK 25 性能诊断的增强。