Java异常, 性能有多差

2023-10-28

在 Java 中，异常通常被认为是成本昂贵的，不应该用于控制控制。本文将证明这个观点的正确性，并验证导致性能问题的原因。

Java微基准测试框架

在编写代码评估Java异常的性能成本之前，我们需要搭建一个基准测试环境。

测量异常的成本开销，并不像在简单循环中执行方法并记录总时间那么容易。
原因是JIT即时编译器会阻碍并优化代码。这种优化可能会使代码比在生产环境中实际执行的更好。换句话说，它可能会产生假阳性结果。

为了创建可以减轻 JVM 优化的受控环境，我们将使用Java Microbenchmark Harness（简称 JMH）Java微基准测试框架来评估Java异常的性能成本。

添加pom依赖

<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-core</artifactId>
    <version>1.35</version>
</dependency>
<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-generator-annprocess</artifactId>
    <version>1.35</version>
</dependency>

基准类

我们需要一个类来保存基准测试用例：

@Fork(1)
@Warmup(iterations = 2)
@Measurement(iterations = 10)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class ExceptionBenchmark {
    private static final int LIMIT = 10_000;
    // benchmarks go here
}

让我们看一下类上标注的 JMH 注释：

@Fork：指定 JMH 必须生成新进程以运行基准测试的次数。我们将它的值设置为1，只生成一个进程，避免等待太久才能看到结果
@Warmup：预热参数。iterations元素为 2 表示在计算结果时忽略前两次运行
@Measurement：测量参数。迭代值为 10 表示 JMH 将每个方法执行 10次
@BenchmarkMode：这是 JHM 收集执行结果的方式。AverageTime值要求 JMH 计算方法完成其操作所需的平均时间
@OutputTimeUnit：表示输出时间单位，本例为毫秒

此外，类体内有一个静态字段，即LIMIT。用于控制每个方法主体中的迭代次数。

Java异常成本开销的度量

创建普通对象并正常返回

让我们从一个正常返回的方法开始；也就是说，一个不抛出异常的方法：

@Benchmark
public void doNotThrowException(Blackhole blackhole) {
    for (int i = 0; i < LIMIT; i++) {
        blackhole.consume(new Object());
    }
}

blackhole参数是Blackhole类型的一个实例。Blackhole是JMH提供的一个用于消耗方法返回值的工具类，其作用是防止JIT编译器对方法返回值的优化，从而更准确地测量方法的性能。

在这种情况下，该基准测试不会抛出任何异常。事实上，我们将使用它作为评估那些抛出异常的性能的参考。

执行该基准测试，会给我们一个报告：

Benchmark                               Mode  Cnt  Score   Error  Units
ExceptionBenchmark.doNotThrowException  avgt   10  0.049 ± 0.006  ms/op

这个结果没有什么特别的。基准测试的平均执行时间为 0.049 毫秒，这本身毫无意义。

创建异常、抛出并捕获

这是另一个创建异常、抛出并捕获的基准测试：

@Benchmark
public void throwAndCatchException(Blackhole blackhole) {
    for (int i = 0; i < LIMIT; i++) {
        try {
            throw new Exception();
        } catch (Exception e) {
            blackhole.consume(e);
        }
    }
}

让我们看一下输出：

Benchmark                                  Mode  Cnt   Score   Error  Units
ExceptionBenchmark.doNotThrowException     avgt   10   0.048 ± 0.003  ms/op
ExceptionBenchmark.throwAndCatchException  avgt   10  17.942 ± 0.846  ms/op

doNotThrowException方法执行时间的微小变化并不重要。这只是底层操作系统和 JVM 状态的波动。关键要点是抛出异常会使方法运行速度慢数百倍。
接下来的几小节将找出究竟是什么导致了如此巨大的差异。

创建异常而不抛出

我们仅仅创建异常，而不抛出

@Benchmark
public void createExceptionWithoutThrowingIt(Blackhole blackhole) {
    for (int i = 0; i < LIMIT; i++) {
        blackhole.consume(new Exception());
    }
}

现在，让我们执行已声明的三个基准测试：

Benchmark                                            Mode  Cnt   Score   Error  Units
ExceptionBenchmark.createExceptionWithoutThrowingIt  avgt   10  17.601 ± 3.152  ms/op
ExceptionBenchmark.doNotThrowException               avgt   10   0.054 ± 0.014  ms/op
ExceptionBenchmark.throwAndCatchException            avgt   10  17.174 ± 0.474  ms/op

结果可能会出乎意料：第一种方法和第三种方法的执行时间几乎相同，而第二种方法的执行时间要短得多。
在这一点上，很明显throw和catch语句本身的执行开销是相当便宜的。另一方面，异常的产生会产生高昂的开销。

抛出异常但不添加堆栈跟踪

让我们弄清楚为什么构造异常比构造普通对象要昂贵得多：

@Benchmark
@Fork(value = 1, jvmArgs = "-XX:-StackTraceInThrowable")
public void throwExceptionWithoutAddingStackTrace(Blackhole blackhole) {
    for (int i = 0; i < LIMIT; i++) {
        try {
            throw new Exception();
        } catch (Exception e) {
            blackhole.consume(e);
        }
    }
}

此方法与示例二 throwAndCatchException 的唯一区别是jvmArgs元素。-XX:-StackTraceInThrowable是一个 JVM 选项，作用是防止堆栈跟踪被添加到异常对象中。

使用-XX:-StackTraceInThrowable参数后，Throwable.getStackTrace()将返回一个空数组。默认情况下，创建Java异常对象时，JVM 会遍历当前线程的堆栈，将VM方法调用栈保存到异常对象Throwable中。

让我们再次运行基准测试：

Benchmark                                                 Mode  Cnt   Score   Error  Units
ExceptionBenchmark.createExceptionWithoutThrowingIt       avgt   10  17.874 ± 3.199  ms/op
ExceptionBenchmark.doNotThrowException                    avgt   10   0.046 ± 0.003  ms/op
ExceptionBenchmark.throwAndCatchException                 avgt   10  16.268 ± 0.239  ms/op
ExceptionBenchmark.throwExceptionWithoutAddingStackTrace  avgt   10   1.174 ± 0.014  ms/op

通过不使用堆栈跟踪填充异常，我们将执行时间缩短了 100 多倍。显然，遍历VM堆栈并将其帧添加到Java异常对象中，会导致我们所看到的迟缓。

抛出异常并展开其堆栈跟踪

最后，让我们看看如果我们抛出异常并在捕获它时展开堆栈跟踪会发生什么：

@Benchmark
public void throwExceptionAndUnwindStackTrace(Blackhole blackhole) {
    for (int i = 0; i < LIMIT; i++) {
        try {
            throw new Exception();
        } catch (Exception e) {
            blackhole.consume(e.getStackTrace());
        }
    }
}

e.getStackTrace()只是将(Throwable)异常对象中已经保存的堆栈跟踪信息，进行展开。

这是运行结果

Benchmark                                                 Mode  Cnt    Score   Error  Units
ExceptionBenchmark.createExceptionWithoutThrowingIt       avgt   10   16.605 ± 0.988  ms/op
ExceptionBenchmark.doNotThrowException                    avgt   10    0.047 ± 0.006  ms/op
ExceptionBenchmark.throwAndCatchException                 avgt   10   16.449 ± 0.304  ms/op
ExceptionBenchmark.throwExceptionAndUnwindStackTrace      avgt   10  326.560 ± 4.991  ms/op
ExceptionBenchmark.throwExceptionWithoutAddingStackTrace  avgt   10    1.185 ± 0.015  ms/op

仅仅通过展开堆栈跟踪，我们就看到执行持续时间增加了大约 20 倍。换句话说，如果我们除了抛出异常之外还从Java异常中提取堆栈跟踪，性能会更差。

结论

本文分析了Java异常对性能的影响。具体来说，使用Java异常，性能成本主要在于将VM堆栈跟踪添加到异常对象(Throwable)中。如果继续展开Throwable中保存的堆栈跟踪，开销将变得更大。

由于抛出和处理异常的代价很高，我们不应该将它用于正常的程序流程。相反，正如其名称所暗示的那样，异常应该只用于特殊情况。

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)