在 Java 中,异常通常被认为是成本昂贵的,不应该用于控制控制。本文将证明这个观点的正确性,并验证导致性能问题的原因。
在编写代码评估Java异常的性能成本之前,我们需要搭建一个基准测试环境。
测量异常的成本开销,并不像在简单循环中执行方法并记录总时间那么容易。
原因是JIT即时编译器会阻碍并优化代码。这种优化可能会使代码比在生产环境中实际执行的更好。换句话说,它可能会产生假阳性结果。
为了创建可以减轻 JVM 优化的受控环境,我们将使用Java Microbenchmark Harness(简称 JMH)Java微基准测试框架来评估Java异常的性能成本。
org.openjdk.jmh
jmh-core
1.35
org.openjdk.jmh
jmh-generator-annprocess
1.35
我们需要一个类来保存基准测试用例:
@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 注释:
此外,类体内有一个静态字段,即LIMIT。用于控制每个方法主体中的迭代次数。
让我们从一个正常返回的方法开始;也就是说,一个不抛出异常的方法:
@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中保存的堆栈跟踪,开销将变得更大。
由于抛出和处理异常的代价很高,我们不应该将它用于正常的程序流程。相反,正如其名称所暗示的那样,异常应该只用于特殊情况。