JDK 25/26 性能与工具演进

• G1 的适用场景
• ZGC 的适用场景
• Shenandoah 的适用场景

选型依据：1）G1——默认 GC，适合中小堆（几 GB 到几十 GB）、对暂停有一定容忍的通用场景，吞吐较高，暂停目标数百 ms；2）ZGC——分代 ZGC（JDK 21+）适合超大堆（几十 GB 到 TB）、要求极低暂停（毫秒级）的场景，暂停目标低但吞吐略低于 G1（并发开销）；3）Shenandoah——类似 ZGC，低暂停，适合对暂停敏感的场景，分代 Shenandoah（JDK 25/26）提升了吞吐。权衡：暂停目标（G1 数百 ms vs ZGC/Shenandoah 毫秒级）、堆规模（大堆用 ZGC/Shenandoah）、吞吐（G1 吞吐较高，ZGC/Shenandoah 并发开销大）。JDK 25/26 中分代 ZGC 与分代 Shenandoah 的默认化（大堆）让低暂停 GC 更易用。

GC 选型是"暂停、吞吐、堆规模"的三角权衡。G1 通用优先，ZGC/Shenandoah 面向低延迟与大堆，分代化降低了并发开销。

• 原生镜像与 HotSpot 的差异
• JFR/JVMTI/堆转储/动态附加/栈符号化
• 能力缺口

GraalVM Native Image 与 HotSpot 相比，生产工具链存在能力缺口：1）JFR——原生镜像提供受限的 JFR 支持（部分事件），非完整 JFR；2）JVMTI Agent——原生镜像不支持 JVMTI Agent（无运行时 JVM 栈），动态附加、instrumentation 不可用；3）堆转储——原生镜像的堆转储格式与 HotSpot 不同，部分工具不兼容；4）动态附加——原生镜像不支持运行时动态加载 Agent（没有 attach 机制）；5）栈符号化——原生镜像的栈是原生栈，需用原生符号化（如 debug 信息、backtrace），与 HotSpot 的 Java 栈转储不同。语义差异：原生镜像的"运行时"是提前编译的 AOT 代码，无 JIT 的运行时编译，因此 JIT 相关工具（如 JFR 的 JIT 事件、JITWatch）不适用。

原生镜像的 AOT 本质决定了它没有完整的 JVM 运行时工具链。投入生产前需评估 JFR/JVMTI/堆转储/动态附加/栈符号化的替代方案（如外部监控、专用 profiling）。

• Leyden 的渐进式能力
• 闭世界假设
• 峰值吞吐与缓存可移植性

Project Leyden 交付的是渐进式能力（CDS/AOT 缓存、提前类加载链接、方法画像），而非把应用编译成独立原生可执行文件。与 GraalVM Native Image 的本质差异：1）闭世界假设——GraalVM 要求"闭世界"（静态可达分析，禁止动态类加载），Leyden 不要求，保留动态类加载能力；2）峰值吞吐——GraalVM 的 AOT 代码无运行时优化，峰值吞吐可能低于 JIT 的 HotSpot；Leyden 的 AOT 缓存保留 JIT 升级能力，峰值吞吐接近 JIT；3）缓存可移植性——Leyden 的 CDS/AOT 缓存可移植（运行时校验，失效回退），GraalVM 原生镜像不可移植（编译时绑定）；4）动态类加载——Leyden 支持动态类加载（在缓存基础上继续），GraalVM 禁止。

Leyden 是"渐进式、可移植、保留 JVM 动态性"的 AOT 路线，GraalVM 是"激进闭世界、面向独立可执行"的路线。Leyden 牺牲峰值优化换取兼容性与动态性。

• 分代 Shenandoah
• 大堆的吞吐与暂停
• 与旧版对比

分代 Shenandoah（JDK 21 引入，JDK 25/26 增强）将堆分为年轻代与老年代，针对大堆（几十 GB 到上百 GB）的优势：1）吞吐提升——分代让大多数对象在年轻代回收，减少全堆扫描的并发工作量，较非分代 Shenandoah 吞吐更高；2）暂停稳定——保持低暂停（毫秒级），但分代降低了并发回收开销；3）大堆适配——分代化让大堆的回收更高效，避免非分代随堆增长的性能退化。JDK 25/26 中分代 Shenandoah 在特定大堆场景可能成为默认，适合对暂停敏感且堆较大的应用。

分代化是 Shenandoah 突破大堆性能瓶颈的关键。年轻代集中回收 + 老年代低频率回收，兼顾低暂停与高吞吐，使大堆应用收益明显。

• JEP 483 的 AOT 加载
• JEP 516 的对象缓存
• 启动加速机制

JEP 483（JDK 24）提供 AOT 类加载与链接（Ahead-of-Time Class Loading & Linking），配合 JDK 25 的 JEP 514（-XX:AOTCacheOutput 一步式生成 AOT 缓存），启动时加载提前编译的代码，减少类加载与 JIT 编译等待。JEP 516（JDK 26）提供 AOT 对象缓存，预创建启动期高频对象（类、元数据、字符串常量），启动时直接加载，减少对象分配与类初始化。两者结合：启动时加载 AOT 编译代码 + 预创建对象，显著缩短到"应用就绪"的时间。JEP 483 基于 CDS（Class Data Sharing）扩展，JEP 516 在其上增加对象缓存。启动加速通过减少编译与分配开销实现。

AOT 启动加速的核心是"提前做"，把启动期的编译与对象创建提前到训练阶段，运行时直接加载。JEP 483（代码）与 JEP 516（对象）互补，加速扩容/无状态服务的启动。

• Lazy Constants 与单例
• 延迟初始化
• 取舍

JEP 502/526（Stable Values → Lazy Constants）提供惰性初始化常量，与单例模式的取舍：单例模式（如 Enum 或 static final + holder）通常用于管理全局唯一实例，Lazy Constants 用于"惰性初始化的常量值"。取舍点：1）延迟性——Lazy Constants 是首次访问时初始化，避免类初始化提前；单例（holder idiom）也延迟但依赖类生命周期；2）可见性——Lazy Constants 由 JVM 保证线程安全与可见性，单例需 DCL 或枚举；3）适用——Lazy Constants 适合"值"（配置、缓存、计算常量），单例适合"带状态的对象"。若只需惰性值，Lazy Constants 更简洁；若需全局唯一对象，用单例。

Lazy Constants 补充了单例模式的"惰性值"场景，降低样板代码。单例仍用于有状态、全局唯一的对象，Lazy Constants 用于纯值。

• 高并发下的性能
• 与 ThreadLocal 对比
• 虚拟线程的配合

Scoped Values 的高并发优势：1）性能——在虚拟线程下，Scoped Values 的读写比 ThreadLocal 更高效（避免每线程哈希表查找，作用域绑定直接定位），且不产生 ThreadLocal 的创建开销；2）无泄漏——不可变 + 作用域结束自动清理，避免 ThreadLocal 在百万虚拟线程下的内存泄漏；3）线程安全——不可变值并发读取无需同步；4）结构化——配合结构化并发，作用域内所有子任务共享，无复制成本。这些优势使 Scoped Values 在高并发、虚拟线程场景下比 ThreadLocal 更优。

高并发下 ThreadLocal 的哈希查找与泄漏是问题，Scoped Values 用作用域绑定 + 不可变解决。虚拟线程海量场景下，Scoped Values 的性能与内存优势显著。

• 版本对齐
• 特性协同
• Spring Boot 的 AOT

JDK 25/26 与 GraalVM 25+ 协作：GraalVM 25 版本号与 JDK 25 对齐，基于 JDK 25 发行，支持 JDK 25 特性；JDK 26 对应 GraalVM 26（后续发布）。协作方式：1）版本对齐——JDK 升级时选对应 GraalVM；2）特性协同——GraalVM Native Image 与 JDK 的 AOT 缓存（CDS/AOT）理念互补，Spring Boot 4.x 的 AOT 处理同时面向两者；3）GraalVM 利用 JDK 25/26 的 GC（分代 ZGC 等）与并发特性。JDK 25/26 的 LTS 与特性对齐让 GraalVM 生态同步演进。

版本对齐让 JDK 与 GraalVM 升级同步，特性协同（AOT、GC、并发）让原生镜像与 HotSpot 用户都能受益。Spring Boot 4 的 AOT 处理是两者协作的桥梁。

• Compact Object Headers
• 内存占用减少
• 容器内存的影响

Compact Object Headers（JEP 450，JDK 24 孵化）通过压缩对象头来减少每个对象的内存开销。传统对象头 12-16 字节，Compact Object Headers 可压缩到 8 字节左右，减少对象内存占用。在容器内存的影响：容器内存受限（固定 -Xmx），对象头压缩使同样内存能容纳更多对象，降低堆压力、减少 GC 频率，提升内存利用率。对存储大量小对象的应用（缓存、集合、领域对象）收益显著。JDK 25/26 继续优化，让容器在受限内存下运行更高效。注意：依赖对象头布局的库（如 Unsafe 内存计算）需适配。

Compact Object Headers 通过在受限内存中减少对象开销，提升容器内存效率。对内存敏感、多小对象的应用，压缩对象头直接降低堆占用与 GC 压力。

• JFR Streaming 的概念
• 实时事件流
• 应用场景

JFR Streaming API（JDK 14 引入，JDK 25/26 增强）允许应用在运行期间实时订阅 JFR 事件流，而不必等待转储文件。通过 jdk.jfr.consumer.RecordingStream，应用可实时消费事件（如 GC、分配、虚拟线程、异常），用于监控、告警与自适应调优。JDK 25/26 增强包括：更多事件类型、更低的流式开销、与虚拟线程/结构化并发的监控事件。应用场景：实时监控内存、GC 暂停、异常率、虚拟线程，云端自动扩缩容触发。

JFR Streaming 把 JFR 从"事后转储"变为"实时事件流"，是生产可观测性的关键。JDK 25/26 扩展事件并优化流式性能，支持实时诊断与自适应。

• Class-File API
• 字节码处理
• 与 ASM 的对比

JEP 484（JDK 24 Final）将 Class-File API 定稿，提供标准化的读取、解析、生成与变换 Java 类文件（字节码）的 API。相比第三方字节码工具（ASM），Class-File API 是 JDK 标准和不可变 API，支持解析、构建、变换、验证类文件，为字节码工具（如 Lombok、Mockito、框架）提供 JDK 内置的基础。JDK 25/26 继续演进，增强对 JDK 新字节码（如 hidden classes、virtual thread 相关）的支持。演进价值：标准 API 减少对第三方库的依赖，提升字节码处理的稳定性与可维护性。

Class-File API 是 JDK 内置的字节码处理标准，替代部分 ASM 场景。定稿后成为字节码工具链的基石，与 JEP 451（Agent 警告）等配合保障字节码操控安全。

• Gatherers 的应用
• 自定义流操作
• 预置操作

JEP 485 Stream Gatherers（JDK 24 Final）的应用场景：实现自定义的 Stream 中间操作，如滑窗（window）、去重（distinct 的扩展）、分组聚合、递归处理、状态依赖的过滤等。预置的 Gatherers 操作包括 window(size)、teeing、fold 等，开发者可组合实现复杂的数据流处理。应用实例：日志批次分窗、数据流去重、滑动窗口统计、按状态聚合。相比 SQL 或外部库，Gatherers 让流处理更声明式、组合式，且与并行流兼容。

Stream Gatherers 填补了 Java Stream 中间操作的可扩展空白。滑动窗口、去重、聚合等场景用 Gatherers 表达更简洁，提升流式数据处理能力。

• jdeps 的作用
• jdeprscan 的作用
• 模块化迁移

jdeps 用于分析类文件的依赖：检测 JDK 内部 API 使用（如 sun.misc.*）、模块依赖（module-info）、以及跨模块引用，是模块化迁移的重要工具。jdeprscan 用于扫描弃用 API（@Deprecated）的使用，帮助定位需要迁移的弃用调用。在模块化迁移中：用 jdeps 找出对 JDK 内部 API 与未导出模块的依赖，用 jdeprscan 找出弃用 API，从而制定迁移计划（改依赖、降级、或使用模块化导出）。JDK 25/26 中 jdeps 增强对内部 API 与新特性的检测，配合 integrity-by-default 路线识别受限制的访问。

jdeps 与 jdeprscan 是"依赖审计"工具。jdeps 定位内部 API 与模块依赖，jdeprscan 定位弃用 API，二者结合是模块化迁移与 JDK 升级的必备。

• jcmd GC.heap_dump
• MAT 支配树
• JFR 配合分析

现代堆分析流程：1）用 jcmd GC.heap_dump 生成堆转储（hprof），或用 jcmd GC.heap_dump -all 转储全部对象；2）用 JFR 记录堆分配与 GC 事件作为补充；3）用 MAT（Memory Analyzer）打开堆转储，通过支配树（Dominator Tree）识别"支配"大量内存的对象（内存泄漏的根因），用可疑泄漏检测（Leak Suspects）快速定位；4）结合 JFR 的分配采样、GC 暂停与对象生命周期事件，关联堆分析结果与运行时行为。JFR 的配合：JFR 提供分配热点、GC 压力与对象统计，与 MAT 的静态堆分析互补，形成"动态 + 静态"的完整分析。

堆分析是"转储 + 支配树 + 动态数据"的组合。jcmd 生成转储，MAT 支配树定位大对象，JFR 提供分配与 GC 的运行时上下文，配合诊断内存问题。

• Arena 生命周期
• MemorySegment 跨线程与释放
• downcall/upcall 迁移

JEP 454（JDK 22 Final）的 Arena 生命周期：confined——只能由创建线程访问，释放时无需同步，性能最好但不跨线程；shared——可跨线程访问（如 multiple threads），释放需同步；auto——由 GC 自动管理释放，可跨线程但释放时机不确定。约束 MemorySegment 跨线程访问与释放：confined 限制单线程，shared 允许多线程但需谨慎，auto 依赖 GC。迁移 JNI 到 Linker：结构体布局用 MemoryLayout 定义（需与原生布局匹配，含对齐）；回调（upcall）需保证存活期（回调对象在原生调用期间保持引用）；errno 捕获用 Linker 的 errno 访问（如 Option 绑定）；原生崩溃隔离测试可通过隔离测试进程、JVM 崩溃文件（hs_err）分析。测试需覆盖布局匹配、回调寿命、errno 正确性与崩溃恢复。

FFM 的 Arena 生命周期让内存管理显式且可控。迁移 JNI 需严格测试布局、回调、errno 与崩溃隔离，确保与原生库交互正确与安全。

• 延迟初始化收益
• 启动加速
• 资源节约

Stable Values / Lazy Constants 的延迟初始化收益：1）启动加速——值在首次访问时才初始化，而非类加载时，减少启动期的初始化开销；2）资源节约——未访问的值不初始化，避免不必要的对象创建与内存占用；3）线程安全——JVM 保证单次初始化与可见性，避免 DCL 样板；4）避免类初始化锁——初始化不触发类初始化，消除类初始化顺序问题。收益在使用场景：昂贵的配置加载、单例缓存、计算常量，按需初始化减少启动与内存开销。

延迟初始化的收益是"按需计算"。Lazy Constants 将惰性单次初始化下沉到 JVM，让未用即不创建，同时保证线程安全，是启动与内存优化的工具。

• FFM 的演进
• 新特性
• 与 JNI 的对比

JDK 25/26 的 Foreign Function & Memory API（FFM）演进：在 JEP 454（JDK 22 定稿）基础上，增强 Linker 的 downcall/upcall 支持、更丰富的 MemoryLayout 与 VarHandle、对 errno 与受限方法的处理、以及安全与性能优化。JDK 24 的 JEP 472 警示 JNI 受限方法，推动迁移到 FFM；JDK 26 继续增强 FFM 的可移植性与性能（如 AOT 配合）。FFM 是 JNI 的现代替代，提供更安全、更可移植、更易用的原生互操作，随 JDK 演进持续完善。

FFM 替代 JNI 是 integrity-by-default 的一部分。JDK 25/26 的演进聚焦安全性（受限方法警告）、可移植性与性能，是 JNI 迁移的官方路径。

• jlink 的模块化
• jpackage 的打包
• 与 AOT 的配合

JDK 25/26 的 jlink/jpackage 演进：jlink 增强模块化运行时裁剪（更小的运行时），支持在链接时生成 CDS/AOT 缓存（配合 JEP 483/514/516），使定制运行时启动更快；jpackage 增强跨平台打包（macOS、Windows、Linux），支持原生安装包、签名、自定义 icon，并可与 jlink 生成的运行时配合。演进目标：生成更小、更快、更易分发的自包含应用。jpackage 还支持将 AOT 缓存打包进安装包，提升桌面与云应用的启动体验。

jlink 裁剪 + jpackage 打包 + AOT 缓存，是 JDK 25/26 面向自包含应用分发的优化主线。演进提升运行时体积与启动性能。

• jcmd 的增强
• jstat 的增强
• jfr 的增强

JDK 25/26 的工具链增强：jcmd 新增对 AOT 缓存、虚拟线程转储、final 字段诊断等命令的支持；jstat 增强对分代 GC（G1/ZGC/Shenandoah）统计的展示；jfr 增强新事件（虚拟线程、HTTP/3、AOT、final 完整性）与 Streaming API、CPU-Time Profiling（JEP 509）。这些增强让 jcmd/jstat/jfr 对 JDK 25/26 的新特性（AOT、虚拟线程、HTTP/3、final 完整性）具备完整诊断能力，提升生产可观测性。

工具链随 JDK 新特性扩展。jcmd 的命令、jstat 的 GC 统计、jfr 的事件都覆盖新特性，是运维与诊断的关键。

• SIMD 向量化
• 应用场景
• 性能收益

Vector API（JEP 508/529）的应用场景：数值计算密集型任务，如图像处理（像素运算）、机器学习推理（矩阵乘法、点积）、数据分析（聚类、统计）、密码学（哈希运算）、音频/信号处理。凡是可向量化的循环（对数组/集合的逐元素运算），Vector API 可用 SIMD 指令加速，性能提升数倍。Vector API 显式表达向量运算，由 C2 生成 AVX/NEON 指令，平台不支持时回退标量。应用场景覆盖科学计算、大数据、AI 推理等需要吞吐的场景。

Vector API 面向"可并行数据运算"，把标量循环向量化。高吞吐数值计算是主要收益场景，配合 JIT 的自动向量化释放 SIMD 性能。

• CPU-Time 剖析
• 与 wall-clock 对比
• 应用场景

JEP 509（JDK 25）的 JFR CPU-Time Profiling 提供基于 CPU 时间的剖析（CPU-time profiling），通过 JFR 记录线程实际消耗 CPU 的时间分布。相比 wall-clock 采样（记录线程"活着"的时间，含 I/O 等待与调度），CPU-time 剖析更准确反映纯计算热点，排除 I/O 与等待干扰。它基于 CPU 时间采样或统计，定位哪些线程/方法真正消耗 CPU。应用场景：CPU 密集型应用的性能剖析、定位计算热点、诊断线程竞争导致的 CPU 浪费。作为实验特性，需启用相关开关。

CPU-time 剖析补足 wall-clock 的盲区，聚焦"计算"而非"存在"。JFR 将其整合为事件流，适合生产环境持续剖析 CPU 热点。

• Spring Boot AOT 处理
• GraalVM 闭世界分析
• 分工

Spring Boot 4.x 的 AOT 处理（AOT engine）在构建时预生成 Spring 容器的元数据与配置（如 Bean 定义、反射配置、代理配置），减少运行时初始化，加速启动，并生成 GraalVM 所需的反射/资源/序列化配置。GraalVM Native Image 25+ 的闭世界分析（closed-world analysis）在构建时静态分析应用的可达对象图，确定需要保留的类、方法、资源，将应用编译为原生可执行文件。分工：Spring Boot AOT 负责"Spring 层的构建时优化"（容器元数据、配置生成），GraalVM 闭世界分析负责"JVM 层的静态分析"（可达性、原生编译）。两者配合实现 Spring Boot 原生镜像的启动加速与精简。

Spring Boot AOT 与 GraalVM 闭世界分析分工明确：前者处理框架级优化，后者处理 JVM 级分析。协作产出启动快、体积小的原生应用。

• JEP 489 的渊源
• JEP 508 的演进
• API 变化

Vector API 的演进：JEP 489（JDK 24）是其第 9 次孵化（incubator），JEP 508（JDK 25）是第 10 次孵化，JDK 26 的 JEP 529 是第 11 次。演进内容包括：优化 API 的向量操作、掩码、广播、归约、重排，改进可移植性与标量回退，增强与 C2 自动向量化的配合。JEP 489 确认了 API 的成熟度，JEP 508 继续收集反馈并微调 API。多次孵化表明 Vector API 在追求稳定、可移植、高性能的平衡，尚未转正。

Vector API 经多次孵化迭代，聚焦 API 稳定性与可移植性。JEP 489→508→529 持续推进，反映 JDK 对高性能 SIMD 的审慎设计。