异常日志不打印堆栈?谈谈 JVM 的 Fast Throw
文章目录
- 1、事件缘由
- 2、Fast Throw
- 3、代码复现
1、事件缘由
今天在公司生产环境的消费者服务出现了钉钉警告,得知消费出现了问题赶紧登录到阿里云SLS看一下错误日志,结果发现是NullPointerException,正当准备看一下异常发生的代码位置,奇怪的事情发生了,该异常信息没有打印出对应的堆栈日志信息。
这就比较麻烦了,如果不打印出对应的堆栈信息,就很难确定到底是代码的那个位置出现NPE问题。通过调查发现:只有最开始的NPE异常打印出了完整的堆栈日志信息,后续由于不断重复抛出该NPE异常,就把堆栈信息进行了隐藏(不输出了),后来通过调查了解到,JVM 会省略/重用异常的完整栈信息,从而把抛异常的开销大幅降低,但代价是后续这些异常的 stack trace 变得不可用或非常简略,给调试和日志排查带麻烦。 这个优化现象称之为:Fast Throw 快速抛出
2、Fast Throw
Fast Throw 是 HotSpot 为了性能对“频繁抛出”的异常做的优化。JVM 会认为这个异常是“热异常”,于是不再创建新的异常对象,而是直接复用一个已经存在的异常对象并抛出,以减少异常创建与堆栈填充的开销。
但并不是所有的异常都会享受到该特性,通过翻阅资料得知,只有一下几个异常频繁抛出,才会出现 Fast Throw 隐藏堆栈日志现象:
- java.lang.NullPointerException 空指针异常
- java.lang.ArrayIndexOutOfBoundsException 数组下标越界
- java.lang.ArrayStoreException 数组存储类型错误
- java.lang.ClassCastException 类型转换错误
- java.lang.ArithmeticException 除以零等算术异常
- java.lang.IllegalMonitorStateException 同步锁状态异常
这样也就正好佐证了,为什么公司线上出现的NullPointerException会吞并堆栈信息,正是因为NPE本身就能享受到 Fast Throw 带来的性能优化。这个特性是JVM默认就开启的,想要关闭的话,需要配置该JVM参数:
-XX:-OmitStackTraceInFastThrow
但是,在生产环境中,并不建议关闭 Fast Throw!
它的存在是出于对性能的考虑,如果系统某短时间频繁出现异常日志输出,关闭 Fast Throw 会造成 CPU 明显上升!
3、代码复现
通过下述代码,模拟出高频抛出NPE:
public class FastThrowTest {public static void main(String[] args) {for (int i = 0; i < 1_000_000; i++) {try {throwNPE();} catch (Exception e) {if (i % 100000 == 0) {e.printStackTrace();}}}}static void throwNPE() {String s = null;s.length();}
}
在IDEA控制台上可以看到,确实后续的日志不再打印堆栈信息了!

