JMH中预热分支（forked warmups）相对分支内预热的独特价值是什么？

首先明确JMH两种预热方式的本质差异：

• 分支内预热：通过@Warmup注解在同一个JVM进程内执行预热迭代，之后直接在该进程中运行正式测试。
• 预热分支：通过@Fork(warmups = N)启动N个独立的废弃JVM进程完成预热流程（结果丢弃），再启动全新JVM进程执行正式测试。

分支内预热虽能让JVM自身的JIT优化达到稳定，但无法解决以下关键问题，这正是预热分支的实用价值所在：

1. 消除进程级残留状态的污染 #

无论预热迭代次数多少，同一个JVM进程内的静态变量初始化、单例实例、ThreadLocal数据、JVM内部GC统计信息、类加载元数据等状态都会永久残留。

• 如果基准测试需要模拟「组件首次启动调用」的场景，分支内预热后的进程已处于「初始化完成」状态，完全无法还原真实的冷启动性能。
• 预热分支的正式测试是全新JVM，所有状态从零开始，彻底避免了进程内残留状态对测试结果的干扰。

2. 完成系统级别的缓存预热 #

JVM启动时需要加载大量类文件、JAR包，这些操作依赖操作系统的页缓存、CPU指令缓存。分支内预热的系统缓存仅局限于当前进程，无法模拟生产环境中「长期运行的系统已填满缓存」的状态。

• 预热分支通过先启动N个废弃JVM，提前将类文件、指令等数据加载到系统缓存中。正式测试的JVM启动时，可直接复用这些缓存，大幅降低启动阶段的IO开销，让测试结果更贴近生产环境中稳定运行的进程性能。

3. 避免JIT编译的上下文偏差 #

JVM的JIT编译会根据运行时的调用统计、分支预测数据生成优化代码。分支内预热时，预热迭代的调用模式、输入数据可能与正式测试存在差异，导致JIT生成的优化代码并不适配正式测试的场景。

• 预热分支的正式测试是全新JVM，JIT编译完全基于正式测试自身的运行上下文生成，消除了预热阶段的上下文干扰。同时，多次废弃JVM的运行也能让CPU分支预测器提前熟悉代码路径，进一步稳定正式测试的性能表现。

内容的提问来源于stack exchange，提问作者Alexandros