如何用JMH基准测试框架比较代码性能？

wen java案例 2026-06-06 62

本文目录导读：

如何用JMH基准测试框架比较代码性能？

目录导读
为什么需要JMH？——性能测试的陷阱与真相
JMH核心概念速览
实战：从零搭建JMH项目
常见性能比较场景与代码示例
JMH结果解读与常见误区
QA：开发者最关心的5个问题

JMH基准测试框架实战指南：如何科学比较Java代码性能

目录导读

为什么需要JMH？——性能测试的陷阱与真相
JMH核心概念速览
实战：从零搭建JMH项目
常见性能比较场景与代码示例
JMH结果解读与常见误区
QA：开发者最关心的5个问题

为什么需要JMH？——性能测试的陷阱与真相

痛点场景：
你写了两段代码：ArrayList遍历 vs LinkedList遍历，在循环里加100万个元素后测试时间——结果发现一次快、一次慢，甚至不同环境结果完全相反，这是为什么？

关键真相：

JVM预热机制：热点代码会被JIT编译，第一次运行和第十次运行速度天差地别。
死代码消除：如果计算结果未被使用，JVM可能直接优化掉整个循环。
系统噪声：GC暂停、线程调度、CPU降频都会干扰测试结果。

JMH（Java Microbenchmark Harness）正是为解决这些问题而生，它由OpenJDK官方开发，通过精确控制预热次数、GC行为、运行温等，给出统计学上有效的性能对比。

一句话总结：不用JMH测性能，就像不用温度计测体温——全凭感觉。

JMH核心概念速览

概念	作用	常见配置
`@Benchmark`	标记要测试的方法	无参数
`@BenchmarkMode`	测试维度（吞吐量/平均时间/采样时间等）	`Mode.Throughput`
`@Warmup`	预热次数与时间	`iterations = 5, time = 1`
`@Measurement`	正式测量次数与时间	`iterations = 10, time = 1`
`@Fork`	独立进程运行次数（避免GC交互污染）	`value = 2`
`@State`	定义共享或线程私有状态对象	`Scope.Thread`

核心原则：

每个@Benchmark方法应只测单一操作。
使用Blackhole对象消费计算结果，防止死代码消除。
必须配置合理的预热（至少3-5轮）与迭代次数。

实战：从零搭建JMH项目

1 Maven依赖（推荐）

<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-core</artifactId>
    <version>1.37</version>
</dependency>
<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-generator-annprocess</artifactId>
    <version>1.37</version>
    <scope>provided</scope>
</dependency>

2 第一个测试类

@BenchmarkMode(Mode.Throughput)
@Warmup(iterations = 3, time = 1)
@Measurement(iterations = 5, time = 2)
@Fork(1)
@State(Scope.Thread)
public class StringConcatBenchmark {
    private String a = "Hello";
    private String b = "World";
    private int count = 1000;
    @Benchmark
    public String plusConcat() {
        String s = "";
        for (int i = 0; i < count; i++) {
            s += a + b;
        }
        return s;
    }
    @Benchmark
    public String builderConcat() {
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < count; i++) {
            sb.append(a).append(b);
        }
        return sb.toString();
    }
    public static void main(String[] args) throws Exception {
        org.openjdk.jmh.Main.main(args);
    }
}

3 运行与输出

执行后控制台会输出类似：

Benchmark                               Mode  Cnt     Score     Error   Units
StringConcatBenchmark.plusConcat       thrpt    5  1245.123 ± 34.567  ops/ms
StringConcatBenchmark.builderConcat    thrpt    5  9876.543 ± 89.012  ops/ms

解读：

Score：每秒操作次数（越高越好）。
Error：置信区间（越小越稳定）。
plusConcat 性能远低于 builderConcat——这正是JMH能清晰揭示的性能差距。

常见性能比较场景与代码示例

场景1：ArrayList vs LinkedList 插入性能

@Benchmark
public void arrayListAdd(Blackhole bh) {
    List<Integer> list = new ArrayList<>();
    for (int i = 0; i < 10000; i++) list.add(i);
    bh.consume(list);
}
@Benchmark
public void linkedListAdd(Blackhole bh) {
    List<Integer> list = new LinkedList<>();
    for (int i = 0; i < 10000; i++) list.add(i);
    bh.consume(list);
}

ArrayList尾部插入快于LinkedList（基于数组复制更快）。

场景2：同步锁 vs 原子类 vs 乐观锁

@State(Scope.Benchmark)
public class CounterBenchmark {
    private int value = 0;
    private final AtomicInteger atomic = new AtomicInteger(0);
    @Benchmark
    public synchronized int syncIncrement() {
        return value++;
    }
    @Benchmark
    public int atomicIncrement() {
        return atomic.incrementAndGet();
    }
}

典型结果：atomicIncrement 比 syncIncrement 快2-5倍（无竞争环境下）。

JMH结果解读与常见误区

1 误区：数值越大/越小就代表代码更好？

不是，需要结合误差范围与业务场景：

吞吐量（ops/ms）高 → 适合高并发场景。
平均时间（us/op）低 → 适合低延迟场景。

throughput与averageTime的反向关系并不绝对，需要看具体实现。

2 如何判断测试结果是否可信？

观察Error值：若误差超过10%，说明测试不稳定（需增加预热或迭代次数）。
检查Fork次数：至少@Fork(2)，避免单次JVM的GC毛刺影响。

3 一定需要Blackhole吗？

是。

// 错误写法：JVM可能会优化掉整个循环
@Benchmark
public void badTest() {
    Math.pow(2, 10);
}
// 正确写法
@Benchmark
public void goodTest(Blackhole bh) {
    bh.consume(Math.pow(2, 10));
}

Blackhole会“欺骗”JVM：这个结果我还在用，别优化掉。