问题描述:生产环境抛异常,但却没有将堆栈信息输出到日志,可以确定的是日志输出时用的是log.error("xx发生错误", e)
问题分析:它跟JDK5的一个新特性有关,对于一些频繁抛出的异常,JDK为了性能会做一个优化,即JIT重新编译后会抛出没有堆栈的异常
而在使用-server模式时,该优化选项是开启的,因此在频繁抛出某个异常一段时间后,该优化开始起作用,即只抛出没有堆栈的异常信息
问题解决:由于该优化是在JIT重新编译后才起作用,因此起初抛出的异常还是有堆栈的,所以可以查看较旧的日志,寻找完整的堆栈信息
另一个解决办法是暂时禁用该优化,即强制要求每次都要抛出有堆栈的异常,幸好JDK提供了通过配置JVM参数的方式来关闭该优化
即-XX:-OmitStackTraceInFastThrow,便可禁用该优化了(注意选项中的减号,加号则表示启用)
官方说明: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.
问题分析:它跟JDK5的一个新特性有关,对于一些频繁抛出的异常,JDK为了性能会做一个优化,即JIT重新编译后会抛出没有堆栈的异常
而在使用-server模式时,该优化选项是开启的,因此在频繁抛出某个异常一段时间后,该优化开始起作用,即只抛出没有堆栈的异常信息
问题解决:由于该优化是在JIT重新编译后才起作用,因此起初抛出的异常还是有堆栈的,所以可以查看较旧的日志,寻找完整的堆栈信息
另一个解决办法是暂时禁用该优化,即强制要求每次都要抛出有堆栈的异常,幸好JDK提供了通过配置JVM参数的方式来关闭该优化
即-XX:-OmitStackTraceInFastThrow,便可禁用该优化了(注意选项中的减号,加号则表示启用)
官方说明: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.
解决生产环境异常抛出无堆栈信息的问题
本文分析了在生产环境中遇到的异常抛出无堆栈信息的情况,指出这与JDK5的一项性能优化特性有关。当使用-server模式时,此优化导致频繁抛出的异常仅包含无堆栈的异常信息。文章提供了两种解决方案:通过查看较旧日志寻找完整堆栈信息,或使用JVM参数强制每次抛出异常时都包含堆栈信息。

被折叠的 条评论
为什么被折叠?



