如何进行基准测试的方法，Java微基准测试实战指南，Java微基准测试实战与基准测试方法解析

💥 ​​同事优化代码后性能反而暴跌50%！​​ 只因他用System.currentTimeMillis()测试耗时——​​90% Java程序员都踩过这个坑​​！今天手撕 ​​JMH实战避雷指南​​，3步教你测出代码​​真实性能​​👇

🔍 自问：为啥普通计时器测不准？

​​血泪真相​​：Java代码在JVM中运行会经历 ​​三重扭曲​​：

• ​​JIT编译优化​​：热点代码被编译后提速百倍 → 手工测试忽略预热阶段❌

• ​​ *** 代码消除​​：未使用的计算结果被JVM直接删除 → 你以为测了，实际测了个空气💨

• ​​GC突然打断​​：垃圾回收卡顿让单次耗时暴涨 → 误判性能瓶颈📉

💡 ​​反常识结论​​：

for循环跑10000次取平均值→ ​​比不测更危险​​！可能得出完全相反的优化方向

🛠️ 五步搞定JMH：测出代码“真实力”

✅ ​​第一步：注入JMH依赖（Maven为例）​​

xml复制
<dependency><groupId>org.openjdk.jmhgroupId><artifactId>jmh-coreartifactId><version>1.37version>dependency><dependency><groupId>org.openjdk.jmhgroupId><artifactId>jmh-generator-annprocessartifactId><version>1.37version>dependency>

⚠️ ​​避坑​​：

用provided→ 否则打包报错💥

✅ ​​第二步：写个“防忽悠”测试类​​

java下载复制运行
@BenchmarkMode(Mode.AverageTime) // 测试平均耗时  @OutputTimeUnit(TimeUnit.NANOSECONDS) // 结果单位：纳秒  @Warmup(iterations = 3, time = 1) // 预热3轮，每轮1秒  @Measurement(iterations = 5, time = 1) // 正式测5轮  public class MyBenchmark {@Param({"10", "1000", "100000"}) // 参数化：不同数据规模  private int size;private List data;@Setup // 初始化（不在测试方法内！）  public void init() {data = new ArrayList<>();for (int i = 0; i < size; i++) {data.add("test" + i);}}@Benchmarkpublic String testStringConcat() {String result = "";for (String s : data) {result += s; // 故意用低效写法！  }return result;}}

💡 ​​设计心机​​：

用@Param暴露​​数据规模对性能的影响​​ → 一眼看出算法是否可扩展

✅ ​​第三步：运行并解读结果​​

bash复制
mvn clean installjava -jar target/benchmarks.jar

​​关键输出示例​​：

复制
Benchmark                   (size)  Mode  Cnt      Score    ErrorMyBenchmark.testStringConcat    10  avgt    5    100.25 ±  1.23 ns/opMyBenchmark.testStringConcat  1000  avgt    5  12000.67 ± 45.67 ns/opMyBenchmark.testStringConcat 100000  avgt    5  304500.50 ± 678.33 ns/op

📊 ​​看懂数据​​：

• Score：平均每次操作耗时（​​越小越好​​）

• ± Error：误差范围 → ​​超过10%需重测！​​

🧩 三大避坑技巧：JMH高手才知道

❌ ​​陷阱1： *** 代码消除​​

java下载复制运行
@Benchmarkpublic int test() {int a = 10;int b = 20;return a + b; // JVM可能直接返回30，不执行计算！  }

✅ ​​破解​​：

在方法末尾加Blackhole.consume(result)→ ​​强制JVM执行计算​​

❌ ​​陷阱2：常量折叠​​

java下载复制运行
@Benchmarkpublic String testConcat() {return "A" + "B"; // 编译时直接变成"AB"！  }

✅ ​​破解​​：

用@State变量存"A"和"B" → 阻止编译期优化

❌ ​​陷阱3：线程不同步​​

java下载复制运行
@Benchmark@Threads(4) // 模拟4线程并发  public void testMultiThread() {// 未用同步机制 → 结果全乱！  }

✅ ​​破解​​：

加@Group和@GroupThreads→ ​​精确控制并发模型​​

💎 暴论：JMH测出的不是性能，是认知！

​​为什么StringBuilder比+快100倍？​​

看JMH对比结果：

​​数据量​​	+拼接耗时	StringBuilder耗时
10次	100 ns/op	50 ns/op ✅
1万次	12000 ns/op	200 ns/op ✅

​​真相​​：

+拼接每次循环​​隐式创建新StringBuilder对象​​ → 海量小对象拖垮GC！

💡 ​​优化启示​​：

​​算法复杂度≠代码性能​​ → 没有JMH，你可能还在优化错误的方向！

​​