1. 微基准测试的必要性
开发者在实际开发中常需要在两种实现方案间做出性能抉择，例如 ArrayList 与 LinkedList 的选择，或者 JSON 序列化框架到底该用 Jackson 还是 Protobuf。然而，直接使用 for 循环并手动计时的方法往往不可靠——JVM 会引入 JIT 编译、死代码消除、循环优化等机制，导致测量结果严重失真。JMH（Java Microbenchmark Harness）是 OpenJDK 官方推出的微基准测试框架，专为应对此类场景设计，能够提供真实可信的性能测量数据。
2. JMH 的核心概念
掌握 JMH 的几个核心概念至关重要。首先是状态（State），通过 @State 注解定义基准测试上下文，可指定 Scope.Benchmark（所有线程共享同一实例）或 Scope.Thread（每个线程独自持有）。基准测试方法本身需使用 @Benchmark 标注，初始化与清理工作则交给 @Setup 和 @TearDown 完成。执行模式共有四种：Throughput（单位时间内的执行次数）、AverageTime（单次平均耗时）、SampleTime（统计执行时间分布）以及 SingleShotTime（单次执行并跳过预热）。预热阶段通过 @Warmup 指定迭代次数，确保 JIT 编译充分后再进入正式测量。分叉（Fork）通过 @Fork 设置独立 JVM 进程数量，避免不同测试间的干扰。
3. 编写一个简单基准测试
假设你要比较 StringBuilder 与 StringBuffer 的 append 性能，用 JMH 编写起来非常直观。首先引入核心依赖：org.openjdk.jmh:jmh-core 和 jmh-generator-annprocess。接着定义一个带有 @State(Scope.Thread) 的类，并在其中准备好 StringBuilder 与 StringBuffer 的实例。然后编写两个 @Benchmark 方法，分别调用 append 操作。最后执行 JMH 的 main 方法，控制台将输出纳秒级别的耗时及置信区间。整个流程清晰明了。
4. 常见陷阱与规避策略
尽管 JMH 功能强大，但仍有诸多易犯错误需要留意。最常见的陷阱是死代码消除——若基准方法的结果未被消费，JVM 可能直接将整个运算优化掉。解决方法是借助 Blackhole.consumeCPU 或直接返回结果。另一个典型问题是常量折叠：当输入为常量时，JVM 可能在编译期完成计算，导致测量失真。可使用 @State 传入参数化输入，或从 ThreadLocalRandom 获取随机数。多线程环境下还需警惕虚假共享（False Sharing），即不同线程访问相邻缓存行引发的性能干扰。JMH 提供了 @CompilerControl 和 @AuxCounters 等工具来协助检测此类问题。
5. 案例：比较 JSON 序列化库
以实际项目为例，团队需要在 Jackson、Gson、Fastjson 三个 JSON 库中做出选择。通过 JMH 设计基准测试：准备相同复杂度的 Java 对象，分别进行序列化与反序列化，并测量吞吐量。同时设置不同数据规模，例如小对象和大数组。测试结果清晰显示：Jackson 在吞吐量上领先 Gson 约 30%，但 Gson 的启动速度更快。最终团队依据 JMH 的数据报告采用了 Jackson。数据驱动决策，避免了凭感觉拍板。
6. 集成到 CI 流水线
JMH 还可以无缝集成到 CI 流程中。它可以作为独立 JAR 运行，输出 JSON 格式的结果，便于 CI 系统抓取并绘制性能趋势图。例如，每次 Git 提交后自动触发关键基准测试，与历史数据对比，一旦性能下降超过阈值，立即触发告警。这样就能提前发现性能退化，避免线上问题。
7. 与其他工具对比
许多开发者习惯使用 System.nanoTime 在循环中手动计时，但这种做法过于粗糙。JVM 预热、死代码消除等问题几乎无法避免，测量结果可信度低。而 JMH 作为官方标准工具，已妥善处理这些底层细节，输出的结果具有更高的可靠性和权威性。
8. 总结
总而言之，JMH 是 Java 开发者进行性能比较的利器。无论是评估数据结构、类库、算法，还是验证优化效果，它都能提供坚实的数据支撑。掌握 JMH 可以帮助你从“感觉快”的主观判断跃升至数据驱动决策，这才是真正可靠的性能分析方法。
