使用JMH写微基准测试的核心是避免JIT预热不足、死码消除和对象逃逸等陷阱；正确做法包括：用@Benchmark标注public void方法、配合Blackhole.consume()防止优化、配置@Fork/@Warmup/@Measurement、通过@State/@Param管理状态与参数，并依据Score Error和置信区间判断性能差异是否显著。
直接用 JMH 写微基准测试，核心是避免常见陷阱（比如 JIT 预热不足、死码消除、对象逃逸），而不是堆参数或写复杂逻辑。
正确声明 Benchmark 方法
JMH 要求被测方法必须是 public、non-static、void 类型，并用 @Benchmark 标注。JMH 会自动调用它多次，不能手动调用或返回结果——返回值会被忽略，且可能触发死码消除。
- ✅ 正确写法：public void measureMyMethod(Blackhole bh) { bh.consume(target.method()); }
- ❌ 错误写法：public long measure() { return target.method(); }（JMH 不捕获返回值，JIT 可能直接优化掉整个调用）
- 用
Blackhole.consume()阻止 JIT 优化掉计算结果，尤其当方法有返回值或副作用时
配置合理的 Benchmark 运行模式
默认的 @Fork + @Warmup + @Measurement 组合是底线配置，不能省略：
-
@Fork(3)：每个 benchmark 单独 fork 3 次 JVM 进程，隔离 GC、JIT 编译状态干扰 -
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)：预热 5 轮，每轮 1 秒，让 JIT 充分编译热点代码 -
@Measurement(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)：正式采集 10 轮数据，每轮 1 秒，取平均值和误差 - 避免在 IDE 中直接运行 main 方法——务必用
mvn clean package && java -jar target/benchmarks.jar启动
控制变量，聚焦方法级差异
微基准的目标是比对两个实现的性能差异（如 StringBuilder vs String.concat），不是测整条业务链路：
立即学习“Java免费学习笔记（深入）”；
- 把待比较的逻辑封装成独立方法，入参尽量从
@State或@Param注入，避免在 benchmark 方法里 new 对象或读文件 - 用
@State(Scope.Benchmark)管理共享状态（如预构造的字符串、缓存对象），确保每次迭代用同一份数据 - 若需测不同输入规模的影响，用
@Param({"10", "100", "1000"})自动生成多组测试，JMH 自动报告各档位耗时 - 禁用 GC 日志干扰：
-jvmArgs "-Xmx1g -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly"（仅调试时加，日常压测去掉）
解读结果，关注统计意义
JMH 输出的 Score 是每秒操作数（ops/s）或平均耗时（ns/op），关键看 Score Error 和 Score Confidence：
- 误差范围（Error）超过 ±5%，说明运行环境不稳定（CPU 抢占、GC 干扰、后台进程），需重跑或加
-jvmArgs "-XX:+UseSerialGC"降低 GC 波动 - 两组结果差异要大于各自误差之和，才算真实性能提升（例如 A: 100±2 ns/op，B: 90±1.5 ns/op → 差值 10 > 2+1.5，B 确实更快）
- 警惕 “快 10%” 的结论——如果原始耗时只有 20ns，10% 就是 2ns，很可能落在测量噪声里，不具工程价值
