java服务异常日志只打印异常类型，没有堆栈定位分析

转载请注明出处：

在定位一个问题的时候，发现日志只打印了异常的类型，却没有堆栈，对问题定位造成了影响，而且很多时候这个异常页很容易被忽略：

遇到的这个现象，是 HotSpot JVM 中一个名为 Fast Throw（快速抛出） 的性能优化机制导致的。它的核心逻辑是：当同一个异常（如 NPE）在代码的同一位置被反复抛出后，JIT 编译器会将其替换为一个预先分配好的、不含堆栈信息的"空壳"异常，以此大幅提升性能。

JVM 在运行 Java 代码时，并非一开始就进行高效编译。对于 HotSpot 虚拟机，特别是 Server 模式下的 C2 编译器，它会监控代码的执行情况。

初次发生 ：当某个 NullPointerException 第一次在代码的某个位置（比如 a.b.c 且 a 为 null）被抛出时，JVM 会正常地构建一个完整的异常对象，包含详细的堆栈信息。这时的开销是完整的。
触发优化 ：当 JIT 发现同一个位置 的 NullPointerException 被抛出的次数足够多（达到了"热点"阈值），它就会认为这个异常"不值得"每次都花费高昂的代价去收集堆栈。于是，在方法被重新编译后，编译器会采取一种"更快的策略"。
Fast Throw 生效 ：这个"更快的策略"就是 Fast Throw 。此后，该位置不再创建新的异常对象，而是直接抛出一个全局预分配的、类型匹配的异常单例 。这个单例的 message 和 stack trace 都是空的。

这个机制是纯粹的性能取舍。

巨大的性能收益：构建异常堆栈需要遍历调用栈，这是一个相当昂贵的操作。Fast Throw 直接跳过了这个步骤，也避免了为新异常对象分配内存，因此抛出速度极快。
可量化的差距 ：根据京东技术团队的测试数据，在抛出 100 万次 NullPointerException 的场景下，开启 Fast Throw 仅需约 6 秒，而关闭后则需要约 28 秒，性能差距超过 4 倍。
丢失的排查线索 ：代价就是日志中只剩下 java.lang.NullPointerException: null，没有任何行号和方法信息，这会让线上问题的定位变得非常困难。

既然知道了原因，解决思路就很清晰了。

在不修改任何配置 的情况下，最实用的方法是立即回溯查询历史日志 。Fast Throw 机制有一个关键特性：在优化生效前，前几次异常是带有完整堆栈的。

你需要做的是：

这是京东团队在 618 大促期间处理类似问题的标准做法，通过追溯定位到了根本原因。

如果需要现场调试或必须立即拿到堆栈，可以在 JVM 启动参数中显式关闭该优化：

bash 复制代码

-XX:-OmitStackTraceInFastThrow

重要提醒 ：强烈不建议在生产环境长期开启此参数 。因为在高频异常场景下（例如代码有 bug 导致每秒都在抛 NPE），关闭此优化会导致堆栈信息疯狂刷屏，可能迅速写满磁盘，引发日志风暴。

Fast Throw 通常意味着代码中存在逻辑漏洞 。一个 NullPointerException 能在同一处被反复触发，说明这是一个高频执行的代码路径。正确的做法是修复这个 NPE 本身，而不是让 JVM 帮你"隐藏"它。