System.nanoTime()在微基准测试中基本无效，因其测得的多是JVM冷启动开销（如类加载、JIT未编译、逃逸分析未生效），而非代码真实耗时；不按JMH规则使用（如缺预热、无Blackhole、状态配置错误）会导致结果被优化或失真。
JMH 不是“加个注解就能测准”的工具，它靠一套对抗 JVM 欺骗行为的机制来避免失真——不按它的规则写，@Benchmark 方法大概率被 JIT 删掉、被常量折叠、或测到的是预热过程本身。
为什么 System.nanoTime() 在微基准里基本无效
手动计时测出的数字，90% 以上不是代码真实耗时，而是 JVM 冷启动开销：类加载、方法解析、JIT 编译阈值未达、逃逸分析未生效。比如一个空循环 for (int i = 0; i ，手写计时可能返回 200ns；但 JMH 下它会被 JIT 直接优化成 0ns —— 因为没副作用，结果也没被消费。这不是 bug，是 JVM 正常行为。你得主动告诉 JVM：“这行计算必须执行，且结果必须用掉”。
@State 和 Blackhole 怎么防死代码消除
死代码消除（DCE）是 JIT 最常触发的失真源。只要 @Benchmark 方法的返回值或副作用没被观测到，JVM 就有权删掉整段逻辑。
-
@State(Scope.Thread)是最常用起点：确保每个线程有独立状态实例，避免共享状态污染测量 - 方法返回值必须被消费：用
blackhole.consume(...)或直接赋值给@State字段 - 别写
return x + y;然后不接住——JIT 看到无引用，直接跳过加法 - 示例正确写法：
@Benchmark public void sum(Blackhole blackhole) { int x = 5; int y = 10; blackhole.consume(x + y); }
@Warmup 和 @Fork 为什么不能省
单轮预热或不 fork 进程，测出来的是“某次 JIT 编译中途的状态”，不是稳态性能。
-
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)：至少让 JIT 达到 C2 编译层级（通常需 10k 次调用），1 秒太短，5 轮才够 -
@Fork(3)强制每次测试在干净 JVM 进程中运行：避免 GC 堆残留、CodeCache 污染、类加载器状态干扰 - 漏掉
@Fork，两次@Benchmark方法可能共享同一个 JVM 的编译缓存，A 方法优化了，B 方法也“沾光”变快——这不是真实对比 - 实测发现：不
@Fork时，相同代码在不同顺序下测出的方差可高达 ±40%
输出模式选错会掩盖关键问题
@BenchmarkMode 不是风格偏好，它决定你看到的是什么维度的失真。
-
Mode.AverageTime：适合低延迟场景（如序列化/反序列化），但对吞吐型操作（如批量处理）不敏感 -
Mode.Throughput：更适合算法对比（如HashMapvsConcurrentHashMapput），单位是 ops/s，天然平滑 GC 波动 -
Mode.SampleTime：唯一能暴露长尾延迟的模式，必须配合@Fork和足够多的@Measurement轮次，否则分位数无统计意义 - 错误示范：用
AverageTime测含 GC 分配的操作，结果里混着 STW 时间，但你根本看不出——因为平均值把毛刺全抹平了
真正难的不是写对注解，而是理解每条配置背后对应的 JVM 不确定度来源：一次 @Warmup 不足，就可能把 C1 编译阶段当成了稳态；少一个 @Fork，就让两组测试在同一个 CodeCache 里互相污染。JMH 的数字可信，从来不是因为它“自动做了什么”，而是因为你明确控制了它“不能做什么”。
