转载请注明出处：
在定位一个问题的时候，发现日志只打印了异常的类型，却没有堆栈，对问题定位造成了影响，而且很多时候这个异常页很容易被忽略：
遇到的这个现象，是 HotSpot JVM 中一个名为 Fast Throw（快速抛出） 的性能优化机制导致的。它的核心逻辑是：当同一个异常（如 NPE）在代码的同一位置被反复抛出后，JIT 编译器会将其替换为一个预先分配好的、不含堆栈信息的"空壳"异常，以此大幅提升性能。
🧠 为什么会发生：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，没有任何行号和方法信息，这会让线上问题的定位变得非常困难。
🔍 如何"抓到它"：定位与诊断策略
既然知道了原因，解决思路就很清晰了。
1. 定位问题根源：向前追溯日志
在不修改任何配置 的情况下，最实用的方法是立即回溯查询历史日志 。Fast Throw 机制有一个关键特性：在优化生效前，前几次异常是带有完整堆栈的。
你需要做的是：
- 在当前无堆栈的异常日志时间点之前 ，搜索相同的异常（例如
NullPointerException）。 - 很可能会找到同一异常在更早时间点打印出的完整堆栈，里面就包含了具体的代码行号。
这是京东团队在 618 大促期间处理类似问题的标准做法，通过追溯定位到了根本原因。
2. 临时排查手段：关闭 Fast Throw
如果需要现场调试或必须立即拿到堆栈，可以在 JVM 启动参数中显式关闭该优化：
bash
-XX:-OmitStackTraceInFastThrow重要提醒 ：强烈不建议在生产环境长期开启此参数 。因为在高频异常场景下（例如代码有 bug 导致每秒都在抛 NPE），关闭此优化会导致堆栈信息疯狂刷屏，可能迅速写满磁盘，引发日志风暴。
3. 长期方案：修复代码 Bug
Fast Throw 通常意味着代码中存在逻辑漏洞 。一个 NullPointerException 能在同一处被反复触发，说明这是一个高频执行的代码路径。正确的做法是修复这个 NPE 本身，而不是让 JVM 帮你"隐藏"它。