我们在进行生产问题排查时发现日志的异常只打印了异常类型，没有打印详细堆栈。调研发现JVM默认在同一个异常大概抛出2800次以后为了提升效率进行了优化，详情不打印。

这个问题有两种解决方法：

第一种

JVM为了提高处理异常的性能，引入了“回边计数器”（Back Edge Count）的概念。当异常被抛出的次数超过一个阈值（这个阈值在不同版本的JVM中可能会有所不同，比如在HotSpot中，这个值大约是2800），JVM会认为异常的处理是热点代码，并对其进行优化。优化的方式可能包括：

  • 预加载：JVM可能会预测到异常处理的路径，并提前加载相关的类和方法。
  • 内联：异常处理代码可能被内联，减少方法调用的开销。
  • 分析异常的频率，进行更高效的异常处理策略。

解决方法：

如果这个问题影响了程序的正确性，那么需要检查代码中的异常处理逻辑。确保异常处理的逻辑是正确的，并且适合于你的应用场景。

如果这个问题只是出于性能考虑，并且没有影响程序的正确性，那么通常不需要采取任何行动，因为JVM已经自动进行了优化。如果你想要禁用这种优化，可以通过JVM启动参数来控制，例如-XX:-UseCounterDecay，但这通常不建议，除非你有充分的理由。

第二种

上面的优化里提到:分析异常的频率，进行更高效的异常处理策略。那具体有什么策略呢？

JVM在默认启动的时候会加上OmitStackTraceInFastThrow参数，含义是当大量抛出同样的异常的后，后面的异常输出将不打印堆栈。原因是打印堆栈的时候底层会调用到Throwable.getOurStackTrace()方法，而这个方法是synchronized的，对性能有比较明显的影响。所以这个参数设置是合理的。

如果JVM的默认优化对排查问题有影响。则在JVM启动参数加上-XX:-OmitStackTraceInFastThrow，意思就是去掉堆栈打印的优化选项，如果想加上就把OmitStackTraceInFastThrow前面的“-”号改为“+”即可。