JMH专为微基准测试设计，聚焦纳秒级方法开销测量，通过自动预热、防死代码消除、进程隔离和严谨统计排除干扰；它支持可控并发（如@Threads+@State共享变量）对比AtomicLong与LongAdder等原子操作性能，但不适用于模拟真实业务压力场景（如QPS、长连接、熔断等），后者应选用JMeter、Gatling等工具。
JMH 不适合做“多线程压力测试”，它专为微基准测试设计，目标是精确测量单个方法在受控 JVM 环境下的纳秒级开销。所谓“多线程环境下的变量操作”，JMH 支持的是可控并发（如固定线程数执行同一方法），而非模拟真实业务压力场景（如 QPS、长连接、资源争抢、超时熔断等）。
明确 JMH 的适用边界
JMH 的核心价值在于排除干扰、聚焦代码本身。它通过以下机制保障精度：
- 自动预热：默认执行多轮 warmup 迭代，确保 JIT 编译完成、类已加载、热点代码已优化
- 防死代码消除：所有 @Benchmark 方法返回值或副作用必须被 Blackhole.consume() 或赋值给 @State 字段，否则 JVM 可能直接优化掉整段逻辑
- 进程隔离：每次 fork 启动新 JVM 实例，避免 GC 状态、类元数据缓存、JIT 编译残留等跨测试污染
- 统计严谨：对每次 measurement 迭代采集数百至数千次样本，输出平均值、标准差、置信区间，而非单次
System.nanoTime()差值
正确建模“多线程变量操作”
以对比 AtomicLong 与 LongAdder 的递增性能为例，关键不在“开了多少线程”，而在“如何让线程真正执行并反映竞争真实开销”：
- 用 @State(Scope.Group) 或 @State(Scope.Benchmark) 共享变量，避免每个线程操作独立副本
- 用 @Threads(8) 指定并发线程数，配合 @Fork(3) 多进程运行取均值
- 禁用循环展开：@Fork(jvmArgs = {"-XX:+UnlockDiagnosticVMOptions", "-XX:+DisableExplicitGC"}) 防止 JVM 对简单循环做激进优化
- 选择合适模式：@BenchmarkMode(Mode.AverageTime) 看单次操作耗时，@BenchmarkMode(Mode.Throughput) 看单位时间吞吐量
避开常见陷阱
很多“多线程 JMH 测试”结果失真，往往源于配置或写法错误：
- 误用 @State(Scope.Thread) 存储被测变量 → 每个线程操作自己的副本，完全无竞争，测不出真实同步开销
- 忘记调用 Blackhole.consume() → 返回值未被使用，JVM 消除整个计算链，结果接近 0 ns
- 预热次数太少（如 @Warmup(iterations = 1)）→ 测试跑在解释器或 C1 编译态，不代表生产环境的 C2 优化态
- 混用不同 JVM 参数或未统一 GC 策略 → 比较 AtomicLong 和 LongAdder 时，若一个用 G1、一个用 ZGC，结果不可比
需要真实压力测试？换工具
如果你的目标是验证“接口能否扛住 1000 并发用户持续 5 分钟”，或“数据库连接池在高负载下是否泄漏”，JMH 不是答案：
- 选 JMeter 或 Gatling 做 HTTP 层压测，关注响应时间分布（TP90/TP99）、错误率、吞吐量（QPS）
- 用 async-profiler + JFR 定位高并发下的锁竞争、GC 停顿、CPU 热点
- 手工编写带 CountDownLatch 和 ExecutorService 的压测脚本时，务必让每个任务自行计时、异常路径确保 countDown、监控 completedTaskCount 校验并发度达标
