1. 为什么我们需要JMH从一次线上事故说起很多Java开发者对性能测试的理解还停留在“写个循环记录开始和结束时间一减就完事”的阶段。我早期也这么干过直到有一次在某个数据处理模块的优化中我信心满满地告诉团队把ArrayList换成LinkedList之后插入性能提升了三倍结果上线后接口响应时间反而涨了。复盘时才发现我那个“性能测试”是在一个被JIT即时编译器优化得面目全非的环境里跑出来的测出来的数字跟生产环境完全是两码事。这就是JMH存在的意义。JMHJava Microbenchmark Harness是OpenJDK团队专门为Java微基准测试打造的一套工具框架它帮你处理了JIT预热、死代码消除、常量折叠、循环优化等一系列手动测试根本搞不定的坑。简单说它让你测出来的数字是“能信”的。这篇文章适合谁看如果你写过Java代码对性能优化有需求或者曾经被“为什么我的测试结果和生产环境对不上”这个问题困扰过那这篇内容就是给你准备的。我会从JMH的核心设计思路讲起把参数配置、实操步骤、常见坑点全部拆开揉碎让你看完就能直接上手写自己的基准测试。2. JMH整体设计与核心思路拆解2.1 手动测试的三大致命伤在讲JMH怎么工作之前先搞清楚手动测试到底哪里不行。我用一个最简单的例子来说明// 典型的手动测试写法 public class BadBenchmark { public static void main(String[] args) { long start System.nanoTime(); for (int i 0; i 1000000; i) { doSomething(); } long end System.nanoTime(); System.out.println(耗时: (end - start) / 1000000 ms); } }这段代码至少有三个致命问题第一JIT预热缺失。JVM运行代码时最开始解释执行然后逐步把热点代码编译成本地机器码。你测的前几万次循环可能还在解释执行阶段速度慢得离谱后面JIT编译完了速度又飞快。你测出来的平均值到底代表哪个阶段说不清楚。第二死代码消除。如果你的doSomething()方法没有副作用JIT编译器可能直接把整个循环优化掉——因为它发现计算结果根本没被使用。你测了个寂寞。第三常量折叠和循环优化。如果循环体里的计算涉及常量JIT可能在编译期就把结果算好了运行时直接返回常量。你测的是编译器的优化能力不是代码的真实性能。JMH的设计思路就是用魔法打败魔法——它通过注解和框架层面的控制强制JVM按照你期望的方式运行测试代码同时用统计方法消除各种噪声。2.2 JMH的核心工作机制JMH的工作流程可以拆成几个关键环节预热迭代Warmup Iterations在正式测量之前先跑若干轮测试代码让JIT编译器有足够的时间完成编译优化。你可以指定预热轮数和每轮时长JMH会自动执行。测量迭代Measurement Iterations预热完成后进入正式测量阶段。每轮迭代独立运行最终汇总统计结果给出平均值、标准差、置信区间等指标。Fork隔离Forking每次测试可以在独立的JVM进程中运行。这解决了两个问题一是不同测试之间的状态污染二是JIT编译器的优化决策可能受到其他代码的影响。默认情况下JMH会fork出新的JVM来跑每一组测试。Blackhole消费Blackhole ConsumptionJMH提供了Blackhole对象你可以在测试方法中调用它的consume()方法强制JIT认为计算结果被使用了从而避免死代码消除。状态管理State Management通过State注解定义测试状态对象JMH负责在合适的时机创建、初始化和销毁这些对象。你可以指定状态的作用范围是线程级别还是基准测试级别。提示JMH的Benchmark方法必须放在被State标注的类中或者通过State对象作为参数传入。这是JMH框架的硬性要求不遵守会直接报错。2.3 为什么选择JMH而不是其他方案市面上做Java性能测试的工具不止JMH一个比如还有System.nanoTime()手动封装、Apache Commons Benchmark等。但JMH的优势在于官方背书OpenJDK团队开发和维护对JVM内部机制的理解最深处理JIT优化的方式最权威。注解驱动通过注解配置测试参数代码简洁可读性强不需要写大量样板代码。统计严谨内置多种统计模式支持置信区间计算结果更可靠。生态完善可以和Maven、Gradle无缝集成支持生成JSON、CSV等格式的报告方便持续集成。我个人的经验是如果你需要做任何严肃的Java性能对比——比如选型两个JSON库、对比两种锁的实现、评估不同GC策略的影响——JMH应该是你的第一选择。3. 核心细节解析与实操要点3.1 环境搭建与依赖配置JMH的使用方式有两种一种是作为独立项目运行另一种是集成到现有Maven/Gradle项目中。我推荐后者因为方便管理依赖和持续集成。Maven配置dependency groupIdorg.openjdk.jmh/groupId artifactIdjmh-core/artifactId version1.37/version /dependency dependency groupIdorg.openjdk.jmh/groupId artifactIdjmh-generator-annprocess/artifactId version1.37/version scopeprovided/scope /dependencyGradle配置plugins { id java id me.champeau.jmh version 0.7.2 } dependencies { jmh org.openjdk.jmh:jmh-core:1.37 jmh org.openjdk.jmh:jmh-generator-annprocess:1.37 }版本选择上1.37是当前比较稳定的版本支持JDK 8到JDK 21。如果你用的是JDK 17以上建议至少用1.36的版本避免一些兼容性问题。注意jmh-generator-annprocess的scope必须是provided因为JMH在编译期生成基准测试的辅助类运行时不需要这个依赖。如果scope配错了可能会遇到注解处理器不生效的问题。3.2 核心注解详解JMH的注解体系是整个框架的骨架理解每个注解的作用是写好基准测试的前提。我把最常用的几个注解整理成了一张表注解作用常用参数Benchmark标记基准测试方法无BenchmarkMode指定测试模式Mode.Throughput、Mode.AverageTime等OutputTimeUnit指定输出时间单位TimeUnit.MILLISECONDS等Warmup配置预热参数iterations、time、timeUnitMeasurement配置测量参数iterations、time、timeUnitFork配置JVM fork参数value、jvmArgsState定义状态对象Scope.Thread、Scope.BenchmarkSetup标记初始化方法Level.Trial、Level.IterationTearDown标记清理方法同SetupParam参数化测试指定参数值数组Threads指定线程数整数BenchmarkMode的几种模式需要特别说明一下Throughput测量单位时间内完成的操作次数适合评估吞吐量。AverageTime测量每次操作的平均耗时适合评估延迟。SampleTime采样测量给出耗时分布适合分析尾延迟。SingleShotTime只运行一次适合冷启动测试。All运行所有模式适合全面评估。我一般会先用Throughput和AverageTime各跑一遍对性能有个整体印象然后再根据需要深入。3.3 状态管理与线程安全State注解定义了测试状态的作用范围这个细节很多人会忽略但它直接影响测试结果的正确性。Scope.Thread每个测试线程拥有独立的状态实例。适合测试无共享状态的场景比如测试一个无状态的工具类方法。Scope.Benchmark所有测试线程共享同一个状态实例。适合测试有共享状态的场景比如测试一个并发数据结构。Scope.Group同一组内的线程共享状态。这个用得比较少一般在测试多线程协作时使用。State(Scope.Thread) public class MyBenchmark { private ListString list; Setup(Level.Trial) public void setup() { list new ArrayList(); for (int i 0; i 1000; i) { list.add(item- i); } } Benchmark public void testAdd() { list.add(new-item); } }上面这个例子中如果Scope改成Benchmark多个线程同时往同一个ArrayList里添加元素不仅测试结果不准还可能直接抛异常。所以状态范围的选择必须和测试场景匹配。提示Setup的Level参数决定了初始化方法的执行时机。Level.Trial在整个测试开始前执行一次Level.Iteration在每轮迭代前执行Level.Invocation在每次方法调用前执行。Level.Invocation要慎用它会显著增加测试开销。4. 实操过程与核心环节实现4.1 第一个完整的JMH基准测试光说不练假把式我们从一个完整的例子开始逐步拆解每个环节。假设我们要对比StringBuilder和StringBuffer在单线程下的拼接性能。这个场景很经典因为StringBuffer是线程安全的理论上会有额外的同步开销。import org.openjdk.jmh.annotations.*; import org.openjdk.jmh.runner.Runner; import org.openjdk.jmh.runner.RunnerException; import org.openjdk.jmh.runner.options.Options; import org.openjdk.jmh.runner.options.OptionsBuilder; import java.util.concurrent.TimeUnit; BenchmarkMode(Mode.Throughput) OutputTimeUnit(TimeUnit.MILLISECONDS) Warmup(iterations 3, time 1, timeUnit TimeUnit.SECONDS) Measurement(iterations 5, time 2, timeUnit TimeUnit.SECONDS) Fork(2) State(Scope.Thread) public class StringConcatBenchmark { Benchmark public String testStringBuilder() { StringBuilder sb new StringBuilder(); for (int i 0; i 100; i) { sb.append(item).append(i); } return sb.toString(); } Benchmark public String testStringBuffer() { StringBuffer sb new StringBuffer(); for (int i 0; i 100; i) { sb.append(item).append(i); } return sb.toString(); } public static void main(String[] args) throws RunnerException { Options opt new OptionsBuilder() .include(StringConcatBenchmark.class.getSimpleName()) .build(); new Runner(opt).run(); } }参数配置的考量Warmup(iterations 3, time 1)预热3轮每轮1秒。对于这种简单的字符串操作3轮预热足够让JIT完成编译。如果是复杂的方法可能需要5轮以上。Measurement(iterations 5, time 2)测量5轮每轮2秒。5轮测量可以给出比较稳定的统计结果2秒的时长保证了每轮有足够的采样量。Fork(2)fork两个JVM进程。每个进程独立运行完整的预热和测量流程最终结果取平均。fork两次可以一定程度上消除单次运行的偶然误差。BenchmarkMode(Mode.Throughput)测量吞吐量单位是“操作次数/毫秒”。因为我们关心的是单位时间内能完成多少次拼接。运行结果解读跑完测试后JMH会输出类似下面的结果Benchmark Mode Cnt Score Error Units StringConcatBenchmark.testStringBuilder thrpt 10 1256.432 ± 23.451 ops/ms StringConcatBenchmark.testStringBuffer thrpt 10 987.654 ± 18.234 ops/msScore是吞吐量得分Error是误差范围。从结果看StringBuilder的吞吐量比StringBuffer高了约27%这个差距主要来自StringBuffer方法上的synchronized关键字带来的锁开销。4.2 参数化测试与多维度对比实际工作中我们往往需要在不同参数下对比性能。比如测试不同初始容量对ArrayList扩容性能的影响。JMH的Param注解可以帮我们实现这个需求。State(Scope.Thread) BenchmarkMode(Mode.AverageTime) OutputTimeUnit(TimeUnit.NANOSECONDS) public class ArrayListCapacityBenchmark { Param({10, 100, 1000, 10000}) private int initialCapacity; Benchmark public ListString testAddWithCapacity() { ListString list new ArrayList(initialCapacity); for (int i 0; i 1000; i) { list.add(item- i); } return list; } Benchmark public ListString testAddWithoutCapacity() { ListString list new ArrayList(); for (int i 0; i 1000; i) { list.add(item- i); } return list; } }运行后JMH会为每个initialCapacity值分别执行两组测试输出一个二维的结果表。这样你就能清楚地看到当初始容量设为1000时testAddWithCapacity几乎不需要扩容性能最优而testAddWithoutCapacity因为默认容量是10需要多次扩容和数组拷贝性能明显更差。参数选择的经验Param的值不要太多一般3到5个就够了。太多会导致测试时间成倍增长而且结果表格会变得难以阅读。另外参数值要有代表性比如测试容量时选10、100、1000、10000这种数量级跨度。4.3 多线程基准测试JMH对多线程测试的支持也很完善。通过Threads注解指定线程数配合Scope.Benchmark状态可以测试并发场景下的性能表现。State(Scope.Benchmark) BenchmarkMode(Mode.Throughput) OutputTimeUnit(TimeUnit.MILLISECONDS) Threads(4) public class ConcurrentMapBenchmark { private ConcurrentHashMapString, String map; Setup(Level.Trial) public void setup() { map new ConcurrentHashMap(); for (int i 0; i 10000; i) { map.put(key- i, value- i); } } Benchmark public String testGet() { return map.get(key-5000); } Benchmark public void testPut() { map.put(new-key, new-value); } }这里Threads(4)表示用4个线程同时跑测试方法。Scope.Benchmark确保所有线程共享同一个ConcurrentHashMap实例模拟真实的并发访问场景。注意多线程测试时Setup方法只会执行一次因为Level.Trial所以初始化代码不需要考虑线程安全问题。但如果用Level.Iteration每个线程每轮迭代都会执行一次Setup这时候就要注意状态对象的线程安全性了。4.4 结果可视化与报告生成JMH支持将结果输出为JSON格式方便后续用脚本或工具做可视化分析。只需要在OptionsBuilder中加一行Options opt new OptionsBuilder() .include(StringConcatBenchmark.class.getSimpleName()) .resultFormat(ResultFormatType.JSON) .result(benchmark-result.json) .build();生成的JSON文件包含了每轮迭代的原始数据、统计指标、环境信息等。我一般会用Python的pandas和matplotlib做进一步分析比如画出不同参数下的性能曲线或者对比多个版本的性能变化趋势。如果不想写脚本也可以直接用JMH自带的报告生成功能输出CSV格式后用Excel打开做个简单的柱状图或折线图效果也够用了。5. 常见问题与排查技巧实录5.1 测试结果波动大怎么办这是新手最常遇到的问题同样的代码跑两次结果差很多。原因可能有以下几种JIT编译未完成。预热轮数不够JIT还在编译过程中。解决办法是增加Warmup的iterations和time比如从3轮1秒增加到5轮2秒。GC干扰。测试过程中发生了垃圾回收导致某轮迭代耗时异常。可以通过Fork的jvmArgs参数添加GC日志观察是否有Full GC发生。如果确实有可以考虑增大堆内存或者优化测试代码减少对象分配。CPU频率调节。某些CPU会根据负载动态调整频率导致测试结果不稳定。可以在BIOS中关闭节能模式或者用cpupower等工具锁定CPU频率。后台进程干扰。测试机器上跑了其他占用CPU的进程。建议在专用测试机上运行或者至少关闭不必要的后台服务。统计方法JMH默认输出平均值和标准差。如果标准差很大超过平均值的10%说明结果不够稳定。可以增加测量轮数或者用Mode.SampleTime查看耗时分布定位异常值。5.2 死代码消除的识别与规避死代码消除是JMH测试中最隐蔽的坑。看下面这个例子Benchmark public void testIncrement() { int x 0; for (int i 0; i 1000; i) { x; } // x没有被使用JIT可能直接消除整个循环 }这段代码测出来的时间可能接近0因为JIT发现x的计算结果没有被使用直接把循环优化掉了。规避方法有三种返回计算结果把x作为方法返回值返回JMH会消费这个返回值。使用Blackhole在方法参数中注入Blackhole对象调用blackhole.consume(x)。使用CompilerControl通过CompilerControl(CompilerControl.Mode.DONT_INLINE)等注解控制JIT行为但这种方法比较高级一般不需要。我个人的习惯是优先用返回值的方式简单直接。如果方法本身没有返回值比如测试void方法就用Blackhole。5.3 常量折叠的陷阱常量折叠是另一个容易忽略的问题Benchmark public int testConstantFold() { return 10 * 20 30; }JIT在编译期就把10 * 20 30算成了230运行时直接返回常量。你测的是“返回一个整数”的时间而不是“做乘法加法”的时间。规避方法让计算涉及运行时才能确定的值。比如从State对象中读取字段或者用Param注入参数。这样JIT就无法在编译期完成计算了。5.4 常见问题速查表问题现象可能原因排查方法解决方案结果波动大JIT未完成、GC干扰、CPU调频增加预热、查看GC日志、锁定CPU频率增加预热轮数、优化内存分配、关闭节能模式结果接近0死代码消除、常量折叠检查方法是否有返回值、计算是否涉及常量返回计算结果、使用Blackhole、引入运行时变量测试报错状态范围不匹配、注解配置错误检查State的Scope、确认注解参数调整Scope、修正注解配置测试时间过长参数过多、迭代轮数过多检查Param数量、Warmup和Measurement配置减少参数、降低迭代轮数多线程结果异常共享状态竞争、线程数配置不当检查State的Scope、确认Threads设置改用Scope.Thread、调整线程数5.5 几个我踩过的坑坑一在IDE里直接运行main方法。JMH的注解处理器需要在编译期生成辅助类如果你在IDE里直接运行有时候注解处理器没有正确执行会报“找不到Benchmark方法”之类的错误。解决办法是先用Maven/Gradle编译一遍确保target/generated-sources目录下有生成的类。坑二Setup方法抛异常。如果Setup方法里抛了异常JMH会直接终止测试但错误信息可能不够明确。建议在Setup里加try-catch把异常信息打印出来方便定位问题。坑三测试方法参数过多。JMH的Benchmark方法参数是有限制的一般只支持Blackhole、State对象等少数几种类型。如果你需要传入多个参数应该把它们封装到一个State对象里。坑四忽略Fork的默认值。Fork不写的话默认是1也就是只fork一个JVM。对于需要高置信度的测试建议至少fork 2到3次。但fork次数越多测试时间越长需要根据实际情况权衡。坑五在虚拟机里跑测试。虚拟机的CPU调度和内存管理跟物理机差异很大测试结果参考价值有限。如果条件允许尽量在物理机上跑JMH测试。6. 进阶技巧让基准测试更贴近生产环境6.1 模拟真实负载JMH默认的测试模式是“连续调用同一个方法”这跟生产环境的负载模式可能差别很大。比如一个缓存生产环境可能是读多写少而且读的key分布不均匀。这时候可以用State对象模拟真实的数据分布State(Scope.Thread) public class CacheBenchmark { private MapString, String cache; private String[] keys; private Random random; Setup(Level.Trial) public void setup() { cache new ConcurrentHashMap(); keys new String[10000]; random new Random(42); for (int i 0; i 10000; i) { keys[i] key- i; cache.put(keys[i], value- i); } } Benchmark public String testGetWithZipfDistribution() { // 模拟Zipf分布少数key被频繁访问 int index (int) (Math.pow(random.nextDouble(), 2) * keys.length); return cache.get(keys[index]); } }这种测试方式比简单的map.get(key-5000)更接近真实场景测出来的结果也更有参考价值。6.2 结合JFR做深度分析JMH本身只给出性能数字但如果你想深入分析“为什么慢”可以结合JFRJava Flight Recorder一起用。在Fork的jvmArgs里加上JFR参数Fork(value 1, jvmArgs { -XX:StartFlightRecordingfilenamebenchmark.jfr,duration60s, -XX:FlightRecorderOptionsstackdepth128 })测试跑完后用JDK Mission Control打开生成的.jfr文件就能看到方法调用栈、内存分配、锁竞争等详细信息。这对于定位性能瓶颈非常有帮助。6.3 持续集成中的JMH把JMH集成到CI流程中可以持续监控性能变化。我的做法是在CI脚本中运行JMH测试输出JSON结果。把JSON结果上传到制品库保留历史记录。用脚本对比当前结果和基线结果如果性能下降超过阈值比如5%就发出告警。这样可以在代码合并之前就发现性能退化避免上线后才发现问题。提示CI环境通常资源有限JMH测试时间不宜过长。可以适当减少预热和测量轮数但要注意结果的可信度会相应降低。建议在CI中用快速模式做初步筛查在专用测试机上做最终验证。6.4 一些实用的JVM参数跑JMH测试时JVM参数的选择也会影响结果。以下是我常用的几组配置基础配置-XX:UseG1GC -Xms2g -Xmx2g -XX:AlwaysPreTouchAlwaysPreTouch让JVM在启动时就分配好所有堆内存避免测试过程中动态扩展堆带来的抖动。低延迟场景-XX:UseZGC -Xms4g -Xmx4g -XX:AlwaysPreTouchZGC的停顿时间极短适合测试对延迟敏感的场景。高吞吐场景-XX:UseParallelGC -Xms4g -Xmx4g -XX:AlwaysPreTouchParallel GC在多核环境下吞吐量表现优秀适合测试批处理类任务。这些参数可以通过Fork的jvmArgs传入也可以在启动JMH的脚本里统一配置。关键是保持测试环境和生产环境的JVM参数一致否则测出来的数字参考价值会大打折扣。7. 从基准测试到性能优化一个完整的案例最后分享一个我实际做过的优化案例把JMH的整个使用流程串起来。背景某个数据处理模块需要频繁地对一个大型List做过滤和转换操作原始实现用的是StreamAPI但团队反馈性能不理想。第一步建立基准。我用JMH写了一个基准测试对比Stream、传统for循环、Iterator三种方式的性能BenchmarkMode(Mode.AverageTime) OutputTimeUnit(TimeUnit.MICROSECONDS) State(Scope.Thread) public class FilterBenchmark { private ListInteger data; Setup(Level.Trial) public void setup() { data new ArrayList(); for (int i 0; i 100000; i) { data.add(i); } } Benchmark public ListInteger testStream() { return data.stream() .filter(x - x % 2 0) .map(x - x * 2) .collect(Collectors.toList()); } Benchmark public ListInteger testForLoop() { ListInteger result new ArrayList(); for (Integer x : data) { if (x % 2 0) { result.add(x * 2); } } return result; } Benchmark public ListInteger testIterator() { ListInteger result new ArrayList(); IteratorInteger it data.iterator(); while (it.hasNext()) { Integer x it.next(); if (x % 2 0) { result.add(x * 2); } } return result; } }第二步分析结果。测试结果显示Stream的平均耗时是for循环的1.8倍Iterator和for循环性能接近。进一步用JFR分析发现Stream的瓶颈主要在自动装箱和Collectors.toList()的中间对象分配上。第三步优化验证。我把Stream改成了IntStream避免了装箱开销Benchmark public int[] testIntStream() { return data.stream() .mapToInt(Integer::intValue) .filter(x - x % 2 0) .map(x - x * 2) .toArray(); }再次跑JMHIntStream版本的耗时降到了和for循环相当的水平同时代码可读性比手动循环好很多。第四步回归验证。优化上线后我用同样的JMH测试跑了一遍生产环境的代码确认性能提升符合预期。同时把JMH测试加入CI流程防止后续代码改动导致性能退化。这个案例的关键点在于JMH不仅告诉你“哪个快”还能结合JFR告诉你“为什么快”。只有理解了性能差异的根本原因才能做出正确的优化决策。我个人在实际操作中的体会是JMH的学习曲线前期比较陡注解多、配置项多第一次跑可能各种报错。但一旦跑通第一个测试后面就是复制粘贴改改参数的事。真正需要花心思的是测试场景的设计——怎么让基准测试尽可能贴近生产环境的真实负载这比调JMH参数重要得多。另外不要迷信单次测试结果多跑几轮、多换几组参数看看结果是否稳定再做判断。性能优化这件事谨慎永远比激进更靠谱。
1. 为什么我们需要JMH从一次线上事故说起很多Java开发者对性能测试的理解还停留在“写个循环记录开始和结束时间一减就完事”的阶段。我早期也这么干过直到有一次在某个数据处理模块的优化中我信心满满地告诉团队把ArrayList换成LinkedList之后插入性能提升了三倍结果上线后接口响应时间反而涨了。复盘时才发现我那个“性能测试”是在一个被JIT即时编译器优化得面目全非的环境里跑出来的测出来的数字跟生产环境完全是两码事。这就是JMH存在的意义。JMHJava Microbenchmark Harness是OpenJDK团队专门为Java微基准测试打造的一套工具框架它帮你处理了JIT预热、死代码消除、常量折叠、循环优化等一系列手动测试根本搞不定的坑。简单说它让你测出来的数字是“能信”的。这篇文章适合谁看如果你写过Java代码对性能优化有需求或者曾经被“为什么我的测试结果和生产环境对不上”这个问题困扰过那这篇内容就是给你准备的。我会从JMH的核心设计思路讲起把参数配置、实操步骤、常见坑点全部拆开揉碎让你看完就能直接上手写自己的基准测试。2. JMH整体设计与核心思路拆解2.1 手动测试的三大致命伤在讲JMH怎么工作之前先搞清楚手动测试到底哪里不行。我用一个最简单的例子来说明// 典型的手动测试写法 public class BadBenchmark { public static void main(String[] args) { long start System.nanoTime(); for (int i 0; i 1000000; i) { doSomething(); } long end System.nanoTime(); System.out.println(耗时: (end - start) / 1000000 ms); } }这段代码至少有三个致命问题第一JIT预热缺失。JVM运行代码时最开始解释执行然后逐步把热点代码编译成本地机器码。你测的前几万次循环可能还在解释执行阶段速度慢得离谱后面JIT编译完了速度又飞快。你测出来的平均值到底代表哪个阶段说不清楚。第二死代码消除。如果你的doSomething()方法没有副作用JIT编译器可能直接把整个循环优化掉——因为它发现计算结果根本没被使用。你测了个寂寞。第三常量折叠和循环优化。如果循环体里的计算涉及常量JIT可能在编译期就把结果算好了运行时直接返回常量。你测的是编译器的优化能力不是代码的真实性能。JMH的设计思路就是用魔法打败魔法——它通过注解和框架层面的控制强制JVM按照你期望的方式运行测试代码同时用统计方法消除各种噪声。2.2 JMH的核心工作机制JMH的工作流程可以拆成几个关键环节预热迭代Warmup Iterations在正式测量之前先跑若干轮测试代码让JIT编译器有足够的时间完成编译优化。你可以指定预热轮数和每轮时长JMH会自动执行。测量迭代Measurement Iterations预热完成后进入正式测量阶段。每轮迭代独立运行最终汇总统计结果给出平均值、标准差、置信区间等指标。Fork隔离Forking每次测试可以在独立的JVM进程中运行。这解决了两个问题一是不同测试之间的状态污染二是JIT编译器的优化决策可能受到其他代码的影响。默认情况下JMH会fork出新的JVM来跑每一组测试。Blackhole消费Blackhole ConsumptionJMH提供了Blackhole对象你可以在测试方法中调用它的consume()方法强制JIT认为计算结果被使用了从而避免死代码消除。状态管理State Management通过State注解定义测试状态对象JMH负责在合适的时机创建、初始化和销毁这些对象。你可以指定状态的作用范围是线程级别还是基准测试级别。提示JMH的Benchmark方法必须放在被State标注的类中或者通过State对象作为参数传入。这是JMH框架的硬性要求不遵守会直接报错。2.3 为什么选择JMH而不是其他方案市面上做Java性能测试的工具不止JMH一个比如还有System.nanoTime()手动封装、Apache Commons Benchmark等。但JMH的优势在于官方背书OpenJDK团队开发和维护对JVM内部机制的理解最深处理JIT优化的方式最权威。注解驱动通过注解配置测试参数代码简洁可读性强不需要写大量样板代码。统计严谨内置多种统计模式支持置信区间计算结果更可靠。生态完善可以和Maven、Gradle无缝集成支持生成JSON、CSV等格式的报告方便持续集成。我个人的经验是如果你需要做任何严肃的Java性能对比——比如选型两个JSON库、对比两种锁的实现、评估不同GC策略的影响——JMH应该是你的第一选择。3. 核心细节解析与实操要点3.1 环境搭建与依赖配置JMH的使用方式有两种一种是作为独立项目运行另一种是集成到现有Maven/Gradle项目中。我推荐后者因为方便管理依赖和持续集成。Maven配置dependency groupIdorg.openjdk.jmh/groupId artifactIdjmh-core/artifactId version1.37/version /dependency dependency groupIdorg.openjdk.jmh/groupId artifactIdjmh-generator-annprocess/artifactId version1.37/version scopeprovided/scope /dependencyGradle配置plugins { id java id me.champeau.jmh version 0.7.2 } dependencies { jmh org.openjdk.jmh:jmh-core:1.37 jmh org.openjdk.jmh:jmh-generator-annprocess:1.37 }版本选择上1.37是当前比较稳定的版本支持JDK 8到JDK 21。如果你用的是JDK 17以上建议至少用1.36的版本避免一些兼容性问题。注意jmh-generator-annprocess的scope必须是provided因为JMH在编译期生成基准测试的辅助类运行时不需要这个依赖。如果scope配错了可能会遇到注解处理器不生效的问题。3.2 核心注解详解JMH的注解体系是整个框架的骨架理解每个注解的作用是写好基准测试的前提。我把最常用的几个注解整理成了一张表注解作用常用参数Benchmark标记基准测试方法无BenchmarkMode指定测试模式Mode.Throughput、Mode.AverageTime等OutputTimeUnit指定输出时间单位TimeUnit.MILLISECONDS等Warmup配置预热参数iterations、time、timeUnitMeasurement配置测量参数iterations、time、timeUnitFork配置JVM fork参数value、jvmArgsState定义状态对象Scope.Thread、Scope.BenchmarkSetup标记初始化方法Level.Trial、Level.IterationTearDown标记清理方法同SetupParam参数化测试指定参数值数组Threads指定线程数整数BenchmarkMode的几种模式需要特别说明一下Throughput测量单位时间内完成的操作次数适合评估吞吐量。AverageTime测量每次操作的平均耗时适合评估延迟。SampleTime采样测量给出耗时分布适合分析尾延迟。SingleShotTime只运行一次适合冷启动测试。All运行所有模式适合全面评估。我一般会先用Throughput和AverageTime各跑一遍对性能有个整体印象然后再根据需要深入。3.3 状态管理与线程安全State注解定义了测试状态的作用范围这个细节很多人会忽略但它直接影响测试结果的正确性。Scope.Thread每个测试线程拥有独立的状态实例。适合测试无共享状态的场景比如测试一个无状态的工具类方法。Scope.Benchmark所有测试线程共享同一个状态实例。适合测试有共享状态的场景比如测试一个并发数据结构。Scope.Group同一组内的线程共享状态。这个用得比较少一般在测试多线程协作时使用。State(Scope.Thread) public class MyBenchmark { private ListString list; Setup(Level.Trial) public void setup() { list new ArrayList(); for (int i 0; i 1000; i) { list.add(item- i); } } Benchmark public void testAdd() { list.add(new-item); } }上面这个例子中如果Scope改成Benchmark多个线程同时往同一个ArrayList里添加元素不仅测试结果不准还可能直接抛异常。所以状态范围的选择必须和测试场景匹配。提示Setup的Level参数决定了初始化方法的执行时机。Level.Trial在整个测试开始前执行一次Level.Iteration在每轮迭代前执行Level.Invocation在每次方法调用前执行。Level.Invocation要慎用它会显著增加测试开销。4. 实操过程与核心环节实现4.1 第一个完整的JMH基准测试光说不练假把式我们从一个完整的例子开始逐步拆解每个环节。假设我们要对比StringBuilder和StringBuffer在单线程下的拼接性能。这个场景很经典因为StringBuffer是线程安全的理论上会有额外的同步开销。import org.openjdk.jmh.annotations.*; import org.openjdk.jmh.runner.Runner; import org.openjdk.jmh.runner.RunnerException; import org.openjdk.jmh.runner.options.Options; import org.openjdk.jmh.runner.options.OptionsBuilder; import java.util.concurrent.TimeUnit; BenchmarkMode(Mode.Throughput) OutputTimeUnit(TimeUnit.MILLISECONDS) Warmup(iterations 3, time 1, timeUnit TimeUnit.SECONDS) Measurement(iterations 5, time 2, timeUnit TimeUnit.SECONDS) Fork(2) State(Scope.Thread) public class StringConcatBenchmark { Benchmark public String testStringBuilder() { StringBuilder sb new StringBuilder(); for (int i 0; i 100; i) { sb.append(item).append(i); } return sb.toString(); } Benchmark public String testStringBuffer() { StringBuffer sb new StringBuffer(); for (int i 0; i 100; i) { sb.append(item).append(i); } return sb.toString(); } public static void main(String[] args) throws RunnerException { Options opt new OptionsBuilder() .include(StringConcatBenchmark.class.getSimpleName()) .build(); new Runner(opt).run(); } }参数配置的考量Warmup(iterations 3, time 1)预热3轮每轮1秒。对于这种简单的字符串操作3轮预热足够让JIT完成编译。如果是复杂的方法可能需要5轮以上。Measurement(iterations 5, time 2)测量5轮每轮2秒。5轮测量可以给出比较稳定的统计结果2秒的时长保证了每轮有足够的采样量。Fork(2)fork两个JVM进程。每个进程独立运行完整的预热和测量流程最终结果取平均。fork两次可以一定程度上消除单次运行的偶然误差。BenchmarkMode(Mode.Throughput)测量吞吐量单位是“操作次数/毫秒”。因为我们关心的是单位时间内能完成多少次拼接。运行结果解读跑完测试后JMH会输出类似下面的结果Benchmark Mode Cnt Score Error Units StringConcatBenchmark.testStringBuilder thrpt 10 1256.432 ± 23.451 ops/ms StringConcatBenchmark.testStringBuffer thrpt 10 987.654 ± 18.234 ops/msScore是吞吐量得分Error是误差范围。从结果看StringBuilder的吞吐量比StringBuffer高了约27%这个差距主要来自StringBuffer方法上的synchronized关键字带来的锁开销。4.2 参数化测试与多维度对比实际工作中我们往往需要在不同参数下对比性能。比如测试不同初始容量对ArrayList扩容性能的影响。JMH的Param注解可以帮我们实现这个需求。State(Scope.Thread) BenchmarkMode(Mode.AverageTime) OutputTimeUnit(TimeUnit.NANOSECONDS) public class ArrayListCapacityBenchmark { Param({10, 100, 1000, 10000}) private int initialCapacity; Benchmark public ListString testAddWithCapacity() { ListString list new ArrayList(initialCapacity); for (int i 0; i 1000; i) { list.add(item- i); } return list; } Benchmark public ListString testAddWithoutCapacity() { ListString list new ArrayList(); for (int i 0; i 1000; i) { list.add(item- i); } return list; } }运行后JMH会为每个initialCapacity值分别执行两组测试输出一个二维的结果表。这样你就能清楚地看到当初始容量设为1000时testAddWithCapacity几乎不需要扩容性能最优而testAddWithoutCapacity因为默认容量是10需要多次扩容和数组拷贝性能明显更差。参数选择的经验Param的值不要太多一般3到5个就够了。太多会导致测试时间成倍增长而且结果表格会变得难以阅读。另外参数值要有代表性比如测试容量时选10、100、1000、10000这种数量级跨度。4.3 多线程基准测试JMH对多线程测试的支持也很完善。通过Threads注解指定线程数配合Scope.Benchmark状态可以测试并发场景下的性能表现。State(Scope.Benchmark) BenchmarkMode(Mode.Throughput) OutputTimeUnit(TimeUnit.MILLISECONDS) Threads(4) public class ConcurrentMapBenchmark { private ConcurrentHashMapString, String map; Setup(Level.Trial) public void setup() { map new ConcurrentHashMap(); for (int i 0; i 10000; i) { map.put(key- i, value- i); } } Benchmark public String testGet() { return map.get(key-5000); } Benchmark public void testPut() { map.put(new-key, new-value); } }这里Threads(4)表示用4个线程同时跑测试方法。Scope.Benchmark确保所有线程共享同一个ConcurrentHashMap实例模拟真实的并发访问场景。注意多线程测试时Setup方法只会执行一次因为Level.Trial所以初始化代码不需要考虑线程安全问题。但如果用Level.Iteration每个线程每轮迭代都会执行一次Setup这时候就要注意状态对象的线程安全性了。4.4 结果可视化与报告生成JMH支持将结果输出为JSON格式方便后续用脚本或工具做可视化分析。只需要在OptionsBuilder中加一行Options opt new OptionsBuilder() .include(StringConcatBenchmark.class.getSimpleName()) .resultFormat(ResultFormatType.JSON) .result(benchmark-result.json) .build();生成的JSON文件包含了每轮迭代的原始数据、统计指标、环境信息等。我一般会用Python的pandas和matplotlib做进一步分析比如画出不同参数下的性能曲线或者对比多个版本的性能变化趋势。如果不想写脚本也可以直接用JMH自带的报告生成功能输出CSV格式后用Excel打开做个简单的柱状图或折线图效果也够用了。5. 常见问题与排查技巧实录5.1 测试结果波动大怎么办这是新手最常遇到的问题同样的代码跑两次结果差很多。原因可能有以下几种JIT编译未完成。预热轮数不够JIT还在编译过程中。解决办法是增加Warmup的iterations和time比如从3轮1秒增加到5轮2秒。GC干扰。测试过程中发生了垃圾回收导致某轮迭代耗时异常。可以通过Fork的jvmArgs参数添加GC日志观察是否有Full GC发生。如果确实有可以考虑增大堆内存或者优化测试代码减少对象分配。CPU频率调节。某些CPU会根据负载动态调整频率导致测试结果不稳定。可以在BIOS中关闭节能模式或者用cpupower等工具锁定CPU频率。后台进程干扰。测试机器上跑了其他占用CPU的进程。建议在专用测试机上运行或者至少关闭不必要的后台服务。统计方法JMH默认输出平均值和标准差。如果标准差很大超过平均值的10%说明结果不够稳定。可以增加测量轮数或者用Mode.SampleTime查看耗时分布定位异常值。5.2 死代码消除的识别与规避死代码消除是JMH测试中最隐蔽的坑。看下面这个例子Benchmark public void testIncrement() { int x 0; for (int i 0; i 1000; i) { x; } // x没有被使用JIT可能直接消除整个循环 }这段代码测出来的时间可能接近0因为JIT发现x的计算结果没有被使用直接把循环优化掉了。规避方法有三种返回计算结果把x作为方法返回值返回JMH会消费这个返回值。使用Blackhole在方法参数中注入Blackhole对象调用blackhole.consume(x)。使用CompilerControl通过CompilerControl(CompilerControl.Mode.DONT_INLINE)等注解控制JIT行为但这种方法比较高级一般不需要。我个人的习惯是优先用返回值的方式简单直接。如果方法本身没有返回值比如测试void方法就用Blackhole。5.3 常量折叠的陷阱常量折叠是另一个容易忽略的问题Benchmark public int testConstantFold() { return 10 * 20 30; }JIT在编译期就把10 * 20 30算成了230运行时直接返回常量。你测的是“返回一个整数”的时间而不是“做乘法加法”的时间。规避方法让计算涉及运行时才能确定的值。比如从State对象中读取字段或者用Param注入参数。这样JIT就无法在编译期完成计算了。5.4 常见问题速查表问题现象可能原因排查方法解决方案结果波动大JIT未完成、GC干扰、CPU调频增加预热、查看GC日志、锁定CPU频率增加预热轮数、优化内存分配、关闭节能模式结果接近0死代码消除、常量折叠检查方法是否有返回值、计算是否涉及常量返回计算结果、使用Blackhole、引入运行时变量测试报错状态范围不匹配、注解配置错误检查State的Scope、确认注解参数调整Scope、修正注解配置测试时间过长参数过多、迭代轮数过多检查Param数量、Warmup和Measurement配置减少参数、降低迭代轮数多线程结果异常共享状态竞争、线程数配置不当检查State的Scope、确认Threads设置改用Scope.Thread、调整线程数5.5 几个我踩过的坑坑一在IDE里直接运行main方法。JMH的注解处理器需要在编译期生成辅助类如果你在IDE里直接运行有时候注解处理器没有正确执行会报“找不到Benchmark方法”之类的错误。解决办法是先用Maven/Gradle编译一遍确保target/generated-sources目录下有生成的类。坑二Setup方法抛异常。如果Setup方法里抛了异常JMH会直接终止测试但错误信息可能不够明确。建议在Setup里加try-catch把异常信息打印出来方便定位问题。坑三测试方法参数过多。JMH的Benchmark方法参数是有限制的一般只支持Blackhole、State对象等少数几种类型。如果你需要传入多个参数应该把它们封装到一个State对象里。坑四忽略Fork的默认值。Fork不写的话默认是1也就是只fork一个JVM。对于需要高置信度的测试建议至少fork 2到3次。但fork次数越多测试时间越长需要根据实际情况权衡。坑五在虚拟机里跑测试。虚拟机的CPU调度和内存管理跟物理机差异很大测试结果参考价值有限。如果条件允许尽量在物理机上跑JMH测试。6. 进阶技巧让基准测试更贴近生产环境6.1 模拟真实负载JMH默认的测试模式是“连续调用同一个方法”这跟生产环境的负载模式可能差别很大。比如一个缓存生产环境可能是读多写少而且读的key分布不均匀。这时候可以用State对象模拟真实的数据分布State(Scope.Thread) public class CacheBenchmark { private MapString, String cache; private String[] keys; private Random random; Setup(Level.Trial) public void setup() { cache new ConcurrentHashMap(); keys new String[10000]; random new Random(42); for (int i 0; i 10000; i) { keys[i] key- i; cache.put(keys[i], value- i); } } Benchmark public String testGetWithZipfDistribution() { // 模拟Zipf分布少数key被频繁访问 int index (int) (Math.pow(random.nextDouble(), 2) * keys.length); return cache.get(keys[index]); } }这种测试方式比简单的map.get(key-5000)更接近真实场景测出来的结果也更有参考价值。6.2 结合JFR做深度分析JMH本身只给出性能数字但如果你想深入分析“为什么慢”可以结合JFRJava Flight Recorder一起用。在Fork的jvmArgs里加上JFR参数Fork(value 1, jvmArgs { -XX:StartFlightRecordingfilenamebenchmark.jfr,duration60s, -XX:FlightRecorderOptionsstackdepth128 })测试跑完后用JDK Mission Control打开生成的.jfr文件就能看到方法调用栈、内存分配、锁竞争等详细信息。这对于定位性能瓶颈非常有帮助。6.3 持续集成中的JMH把JMH集成到CI流程中可以持续监控性能变化。我的做法是在CI脚本中运行JMH测试输出JSON结果。把JSON结果上传到制品库保留历史记录。用脚本对比当前结果和基线结果如果性能下降超过阈值比如5%就发出告警。这样可以在代码合并之前就发现性能退化避免上线后才发现问题。提示CI环境通常资源有限JMH测试时间不宜过长。可以适当减少预热和测量轮数但要注意结果的可信度会相应降低。建议在CI中用快速模式做初步筛查在专用测试机上做最终验证。6.4 一些实用的JVM参数跑JMH测试时JVM参数的选择也会影响结果。以下是我常用的几组配置基础配置-XX:UseG1GC -Xms2g -Xmx2g -XX:AlwaysPreTouchAlwaysPreTouch让JVM在启动时就分配好所有堆内存避免测试过程中动态扩展堆带来的抖动。低延迟场景-XX:UseZGC -Xms4g -Xmx4g -XX:AlwaysPreTouchZGC的停顿时间极短适合测试对延迟敏感的场景。高吞吐场景-XX:UseParallelGC -Xms4g -Xmx4g -XX:AlwaysPreTouchParallel GC在多核环境下吞吐量表现优秀适合测试批处理类任务。这些参数可以通过Fork的jvmArgs传入也可以在启动JMH的脚本里统一配置。关键是保持测试环境和生产环境的JVM参数一致否则测出来的数字参考价值会大打折扣。7. 从基准测试到性能优化一个完整的案例最后分享一个我实际做过的优化案例把JMH的整个使用流程串起来。背景某个数据处理模块需要频繁地对一个大型List做过滤和转换操作原始实现用的是StreamAPI但团队反馈性能不理想。第一步建立基准。我用JMH写了一个基准测试对比Stream、传统for循环、Iterator三种方式的性能BenchmarkMode(Mode.AverageTime) OutputTimeUnit(TimeUnit.MICROSECONDS) State(Scope.Thread) public class FilterBenchmark { private ListInteger data; Setup(Level.Trial) public void setup() { data new ArrayList(); for (int i 0; i 100000; i) { data.add(i); } } Benchmark public ListInteger testStream() { return data.stream() .filter(x - x % 2 0) .map(x - x * 2) .collect(Collectors.toList()); } Benchmark public ListInteger testForLoop() { ListInteger result new ArrayList(); for (Integer x : data) { if (x % 2 0) { result.add(x * 2); } } return result; } Benchmark public ListInteger testIterator() { ListInteger result new ArrayList(); IteratorInteger it data.iterator(); while (it.hasNext()) { Integer x it.next(); if (x % 2 0) { result.add(x * 2); } } return result; } }第二步分析结果。测试结果显示Stream的平均耗时是for循环的1.8倍Iterator和for循环性能接近。进一步用JFR分析发现Stream的瓶颈主要在自动装箱和Collectors.toList()的中间对象分配上。第三步优化验证。我把Stream改成了IntStream避免了装箱开销Benchmark public int[] testIntStream() { return data.stream() .mapToInt(Integer::intValue) .filter(x - x % 2 0) .map(x - x * 2) .toArray(); }再次跑JMHIntStream版本的耗时降到了和for循环相当的水平同时代码可读性比手动循环好很多。第四步回归验证。优化上线后我用同样的JMH测试跑了一遍生产环境的代码确认性能提升符合预期。同时把JMH测试加入CI流程防止后续代码改动导致性能退化。这个案例的关键点在于JMH不仅告诉你“哪个快”还能结合JFR告诉你“为什么快”。只有理解了性能差异的根本原因才能做出正确的优化决策。我个人在实际操作中的体会是JMH的学习曲线前期比较陡注解多、配置项多第一次跑可能各种报错。但一旦跑通第一个测试后面就是复制粘贴改改参数的事。真正需要花心思的是测试场景的设计——怎么让基准测试尽可能贴近生产环境的真实负载这比调JMH参数重要得多。另外不要迷信单次测试结果多跑几轮、多换几组参数看看结果是否稳定再做判断。性能优化这件事谨慎永远比激进更靠谱。
