JMH微基准测试因JVM优化失真？Blackhole防消除与状态对象逃逸分析屏蔽 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

JMH 微基准测试：对抗 JVM 优化失真

各位听众，大家好。今天，我们来探讨一个微基准测试中经常遇到的问题：JVM 优化带来的失真。在使用 JMH 进行微基准测试时，我们必须认真考虑 JVM 的各种优化策略，否则测试结果很可能无法反映真实情况，甚至得出错误的结论。我们将重点讨论两种常用的对抗 JVM 优化的技术：Blackhole 防消除和状态对象逃逸分析屏蔽。

1. JVM 优化概览

JVM 旨在尽可能提高程序运行效率，它会进行各种优化，包括但不限于：

即时编译 (JIT Compilation): 将热点代码编译成本地机器码，提升执行速度。
内联 (Inlining): 将小的方法调用直接替换为方法体，减少方法调用的开销。
死代码消除 (Dead Code Elimination): 移除永远不会执行的代码。
常量折叠 (Constant Folding): 在编译时计算常量表达式的结果。
循环展开 (Loop Unrolling): 展开循环体，减少循环控制的开销。
逃逸分析 (Escape Analysis): 分析对象的生命周期，如果对象不会逃逸出方法或线程，则可以进行栈上分配或锁消除。

这些优化在正常程序中可以显著提升性能，但在微基准测试中，它们可能会导致测试结果失真。例如，如果一个计算结果没有被使用，JVM 可能会直接消除掉整个计算过程，导致测试结果显示极快的速度，但这并不代表实际应用中的性能。

2. `Blackhole`：防止结果消除

Blackhole 是 JMH 提供的一个工具类，用于防止 JVM 消除无用的计算结果。它的作用是“消费”计算结果，阻止 JVM 认为这些结果是无用的。

原理:

Blackhole 提供了一个 consume(Object obj) 方法，该方法接受一个对象作为参数，但实际上不做任何操作。它的存在仅仅是为了告诉 JVM，这个对象是被使用过的，因此不能被优化掉。

代码示例:

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;
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.Random;
import java.util.concurrent.TimeUnit;

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class BlackholeExample {

    private int x;
    private int y;

    @Setup(Level.Trial)
    public void setup() {
        Random random = new Random();
        x = random.nextInt();
        y = random.nextInt();
    }

    @Benchmark
    public int baseline() {
        return x + y; // 可能被优化掉
    }

    @Benchmark
    public void blackhole(Blackhole bh) {
        bh.consume(x + y); // 阻止优化
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(BlackholeExample.class.getSimpleName())
                .forks(1)
                .warmupIterations(5)
                .measurementIterations(5)
                .build();

        new Runner(opt).run();
    }
}

说明:

@State(Scope.Thread): 每个线程都拥有自己的 BlackholeExample 实例，避免线程间的干扰。
@Benchmark: 标记需要进行基准测试的方法。
baseline() 方法: 没有使用 Blackhole，计算结果可能被 JVM 优化掉。
blackhole() 方法: 使用 Blackhole 消费计算结果，防止优化。
Blackhole bh: JMH 会自动将 Blackhole 实例注入到带有 Blackhole 参数的基准测试方法中。
bh.consume(x + y): 将 x + y 的结果传递给 Blackhole 进行消费。

运行结果对比:

不使用 Blackhole 时，baseline() 方法的运行时间可能会非常短，甚至接近于 0，这是因为 JVM 认为 x + y 的结果没有被使用，直接优化掉了整个计算过程。使用 Blackhole 后，blackhole() 方法的运行时间会更接近于真实的计算时间。

注意事项:

Blackhole 只能防止结果消除，不能阻止其他的 JVM 优化。
过度使用 Blackhole 可能会影响测试结果的准确性。应该只在必要时使用 Blackhole。
Blackhole 也有一定的开销，在比较细粒度的操作时需要考虑。

3. 状态对象与逃逸分析屏蔽

逃逸分析是 JVM 的一项优化技术，用于分析对象的生命周期。如果 JVM 确定一个对象不会逃逸出方法或线程，它可以将该对象分配在栈上，而不是堆上，从而减少垃圾回收的压力，提高性能。此外，还可以进行锁消除，避免不必要的同步开销。

在微基准测试中，逃逸分析可能会导致测试结果失真。例如，如果一个对象被分配在栈上，它的创建和访问速度会比分配在堆上的对象快很多，这可能会影响到测试结果的准确性。

逃逸分析的影响:

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;

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class EscapeAnalysisExample {

    static class Point {
        int x;
        int y;

        public Point(int x, int y) {
            this.x = x;
            this.y = y;
        }
    }

    @Benchmark
    public Point allocatePoint() {
        return new Point(1, 2); // 可能被分配在栈上
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(EscapeAnalysisExample.class.getSimpleName())
                .forks(1)
                .warmupIterations(5)
                .measurementIterations(5)
                .build();

        new Runner(opt).run();
    }
}

在这个例子中，Point 对象很可能被 JVM 分析出不会逃逸出 allocatePoint() 方法，因此会被分配在栈上。这会导致 allocatePoint() 方法的执行速度非常快，但这并不能反映实际应用中 Point 对象在堆上分配的性能。

屏蔽逃逸分析的方法:

对象注入 @State: 将对象作为 @State 对象的一部分，并让该状态对象具有更高的 Scope。
对象传递: 将对象传递给其他方法或线程，使其逃逸出当前方法或线程。
@CompilerControl(CompilerControl.Mode.DONT_INLINE): 阻止方法内联，间接影响逃逸分析。

代码示例 (对象注入 @State):

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.ArrayList;
import java.util.List;
import java.util.concurrent.TimeUnit;

@State(Scope.Benchmark) // Scope.Benchmark 保证对象在所有线程间共享，阻止逃逸分析
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class EscapeAnalysisPreventedExample {

    static class Point {
        int x;
        int y;

        public Point(int x, int y) {
            this.x = x;
            this.y = y;
        }
    }

    private final List<Point> points = new ArrayList<>();

    @Setup(Level.Trial)
    public void setup() {
        for (int i = 0; i < 100; i++) {
            points.add(new Point(i, i));
        }
    }

    @Benchmark
    public Point allocatePoint() {
        Point p = new Point(1, 2); // 现在更可能被分配在堆上
        points.set(0, p); // 将对象放入共享的列表中，防止逃逸分析
        return p;
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(EscapeAnalysisPreventedExample.class.getSimpleName())
                .forks(1)
                .warmupIterations(5)
                .measurementIterations(5)
                .build();

        new Runner(opt).run();
    }
}

说明:

@State(Scope.Benchmark): Scope.Benchmark 意味着所有线程共享同一个 EscapeAnalysisPreventedExample 实例。这确保了 points 列表在所有线程之间共享，从而阻止了 Point 对象的逃逸分析。
points.set(0, p): 将新创建的 Point 对象放入共享的 points 列表中。由于 points 列表是共享的，Point 对象很可能被分配在堆上。

代码示例 (对象传递):

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;

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class EscapeAnalysisPreventedExample2 {

    static class Point {
        int x;
        int y;

        public Point(int x, int y) {
            this.x = x;
            this.y = y;
        }
    }

    @Benchmark
    public Point allocatePoint() {
        Point p = new Point(1, 2);
        consumePoint(p); // 将对象传递给其他方法，阻止逃逸分析
        return p;
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE) // 阻止内联，进一步影响逃逸分析
    private void consumePoint(Point p) {
        // 模拟使用对象，防止被优化掉
        p.x = p.x + 1;
        p.y = p.y + 1;
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(EscapeAnalysisPreventedExample2.class.getSimpleName())
                .forks(1)
                .warmupIterations(5)
                .measurementIterations(5)
                .build();

        new Runner(opt).run();
    }
}

说明:

consumePoint(Point p): 将 Point 对象传递给 consumePoint 方法。
@CompilerControl(CompilerControl.Mode.DONT_INLINE): 阻止 consumePoint 方法被内联，这有助于防止 JVM 对 Point 对象进行逃逸分析。

注意事项:

屏蔽逃逸分析可能会降低性能，因此应该只在必要时使用。
不同的 JVM 版本和配置可能会影响逃逸分析的结果，因此需要进行充分的测试。
@CompilerControl 的使用需要谨慎，过度使用可能会影响测试结果的准确性。

4. 其他优化策略的影响

除了消除和逃逸分析，JVM 还有许多其他的优化策略可能会影响微基准测试的结果。例如，JIT 编译、内联和常量折叠等。

JIT 编译: JIT 编译会将热点代码编译成本地机器码，这可以显著提高性能。但是，在微基准测试中，JIT 编译可能会导致测试结果不稳定，因为 JIT 编译需要一定的预热时间。为了减少 JIT 编译的影响，可以使用 @Warmup 注解设置预热迭代次数。
内联: 内联会将小的方法调用直接替换为方法体，这可以减少方法调用的开销。但是，在微基准测试中，内联可能会导致测试结果失真，因为内联可能会改变代码的执行路径。为了阻止内联，可以使用 @CompilerControl(CompilerControl.Mode.DONT_INLINE) 注解。
常量折叠: 常量折叠会在编译时计算常量表达式的结果。例如，int x = 1 + 2; 会被编译器优化为 int x = 3;。在微基准测试中，常量折叠可能会导致测试结果失真，因为编译器可能会直接计算出结果，而不需要实际执行代码。为了阻止常量折叠，可以使用 volatile 关键字或者使用运行时计算。

5. JMH 配置最佳实践

为了获得更准确的微基准测试结果，可以采用以下 JMH 配置最佳实践：

设置合理的预热迭代次数: 使用 @Warmup 注解设置足够的预热迭代次数，以便 JVM 有足够的时间进行 JIT 编译。
设置合理的测量迭代次数: 使用 @Measurement 注解设置足够的测量迭代次数，以便获得更稳定的测试结果。
使用多个 Fork: 使用 @Fork 注解设置多个 Fork，以便消除 JVM 启动和 JIT 编译的影响。
禁用 GC 日志: 在运行 JMH 测试时，禁用 GC 日志，以避免 GC 日志对测试结果的影响。可以使用 -gc:none 参数来禁用 GC 日志。
使用正确的 BenchmarkMode: 根据测试的目标选择合适的 BenchmarkMode。例如，如果测试的是平均执行时间，可以使用 Mode.AverageTime。如果测试的是吞吐量，可以使用 Mode.Throughput。
仔细分析结果: 仔细分析 JMH 的测试结果，并考虑 JVM 优化可能带来的影响。

6. 案例分析

假设我们需要测试两种不同的字符串拼接方法的性能：

使用 StringBuilder 进行拼接。
使用 String.concat() 方法进行拼接。

代码示例:

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;

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class StringConcatExample {

    private String a = "hello";
    private String b = "world";

    @Benchmark
    public String stringBuilderConcat() {
        return new StringBuilder().append(a).append(b).toString();
    }

    @Benchmark
    public String stringConcat() {
        return a.concat(b);
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(StringConcatExample.class.getSimpleName())
                .forks(1)
                .warmupIterations(5)
                .measurementIterations(5)
                .build();

        new Runner(opt).run();
    }
}

分析:

在这个例子中，JVM 可能会对 stringConcat() 方法进行优化，例如将 String.concat() 方法内联。为了获得更准确的测试结果，可以采取以下措施：

使用 @CompilerControl(CompilerControl.Mode.DONT_INLINE) 注解阻止 String.concat() 方法内联。
使用 Blackhole 消费字符串拼接的结果，防止结果被消除。

修改后的代码示例:

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;
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;

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class StringConcatExample {

    private String a = "hello";
    private String b = "world";

    @Benchmark
    public void stringBuilderConcat(Blackhole bh) {
        bh.consume(new StringBuilder().append(a).append(b).toString());
    }

    @Benchmark
    public void stringConcat(Blackhole bh) {
        bh.consume(stringConcatInternal());
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    private String stringConcatInternal() {
        return a.concat(b);
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(StringConcatExample.class.getSimpleName())
                .forks(1)
                .warmupIterations(5)
                .measurementIterations(5)
                .build();

        new Runner(opt).run();
    }
}

通过以上措施，可以获得更准确的字符串拼接性能测试结果。

7. JVM 优化策略总结

优化策略	描述	影响	对抗方法
JIT 编译	将热点代码编译成本地机器码。	导致测试结果不稳定，需要预热。	设置合理的预热迭代次数 (`@Warmup`)。
内联	将小的方法调用直接替换为方法体。	改变代码的执行路径，导致测试结果失真。	使用 `@CompilerControl(CompilerControl.Mode.DONT_INLINE)` 阻止内联。
死代码消除	移除永远不会执行的代码。	消除计算过程，导致测试结果显示极快的速度。	使用 `Blackhole` 消费计算结果。
常量折叠	在编译时计算常量表达式的结果。	直接计算出结果，而不需要实际执行代码。	使用 `volatile` 关键字或者使用运行时计算。
逃逸分析	分析对象的生命周期，如果对象不会逃逸出方法或线程，则可以进行栈上分配或锁消除。	对象的创建和访问速度会比分配在堆上的对象快很多，锁消除会影响同步性能的测试。	将对象作为 `@State` 对象的一部分，并让该状态对象具有更高的 `Scope`。将对象传递给其他方法或线程。使用 `@CompilerControl(CompilerControl.Mode.DONT_INLINE)` 阻止方法内联。

总而言之，理解 JVM 优化策略对于编写准确的微基准测试至关重要。通过合理使用 Blackhole 和屏蔽逃逸分析等技术，我们可以有效地对抗 JVM 优化带来的失真，从而获得更可靠的测试结果。希望今天的分享对大家有所帮助。谢谢！

对抗JVM优化，需要理解并使用合适的工具

为了写出更准确的基准测试，我们需要了解JVM优化，并使用JMH提供的Blackhole 和 @CompilerControl等工具来减少这些优化带来的影响。不同的策略适用于不同的场景，需要仔细分析和选择。

JMH 微基准测试：对抗 JVM 优化失真

1. JVM 优化概览

2. Blackhole：防止结果消除

3. 状态对象与逃逸分析屏蔽

4. 其他优化策略的影响

5. JMH 配置最佳实践

6. 案例分析

7. JVM 优化策略总结

对抗JVM优化，需要理解并使用合适的工具

发表回复 取消回复

2. `Blackhole`：防止结果消除

发表回复取消回复