异常日志不打印堆栈？谈谈 JVM 的 Fast Throw

文章目录

1、事件缘由
[2、Fast Throw](#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参数：

java 复制代码

-XX:-OmitStackTraceInFastThrow

但是，在生产环境中，并不建议关闭 Fast Throw！

它的存在是出于对性能的考虑，如果系统某短时间频繁出现异常日志输出，关闭 Fast Throw 会造成 CPU 明显上升！

3、代码复现

通过下述代码，模拟出高频抛出NPE：

java 复制代码

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控制台上可以看到，确实后续的日志不再打印堆栈信息了！