问题描述

查看线上log时,发现了一些npe异常,但是没有堆栈信息。

...
java.lang.NullPointerException
...

没有堆栈信息,也就意味着没法定位问题代码,第一反应是查看记日志的代码(用的logback),确认没有问题后,开始google和stackOverflow。

结论

一般情况下,当异常发生时,JVM会回溯调用栈,构建异常对象(包含完整的堆栈信息)。但是出于性能考虑,如果某个方法一直抛出同样的异常,比如npe,JVM会重新编译该方法(JIT编译器),然后抛出事先创建好的异常(没有堆栈信息)。

JDK5.0的发布说明里有相关描述:

The compiler in the server VM now provides correct stack backtraces for all "cold" built-in exceptions. For performance purposes, when such an exception is thrown a few times, the method may be recompiled. After recompilation, the compiler may choose a faster tactic using preallocated exceptions that do not provide a stack trace. To disable completely the use of preallocated exceptions, use this new flag: -XX:-OmitStackTraceInFastThrow.

https://www.oracle.com/technetwork/java/javase/relnotes-139183.html

复现&解决方案

复现问题

执行如下代码:

for (int i = 0; i < 200000; i++) {
    try {
        ((String) null).toString();
    } catch (Exception e) {
        int stackTraceLength = e.getStackTrace().length;
        System.out.println(i + ",堆栈长度:" + stackTraceLength);
    }
}

在我的电脑上,循环115716次后,堆栈长度就为0了,即堆栈信息为空,如下:

...
115713,堆栈长度:1
115714,堆栈长度:1
115715,堆栈长度:0
115716,堆栈长度:0
...

所以,验证了JVM确实会进行一些优化,出现没有堆栈的异常。

解决方案

  • 通过JVM参数禁用此优化。
    JDK5.0 Release Notes里说的很明确,通过添加JVM参数禁用此优化:-XX:-OmitStackTraceInFastThrow。
  • 查看更早之前的log,直到相关的异常堆栈,解决掉。
    如上文所说,只有某个异常出现了若干次后,才可能触发优化条件。所以,最初的日志里肯定是有完整的堆栈信息。

如果日志比较少,考虑直接往前追溯log,找到异常堆栈,解决问题。
如果日志比较多,考虑在线上先给JVM增加参数禁用此优化,解决问题后,再移除参数,开启优化。

最后

以此为假设,在线上往前追溯log,最终在5天前的日志里找到了相关异常的堆栈信息,定位到问题,解决起来就比较简单了。
本文以流水账的方式描述了遇到的问题和解决方案,其实还是很多东西值得继续调研,比如JVM为什么要这个优化,JVM的异常机制是如何运行的,为什么会这么慢,等等。