| 
                                      3
                                 | 
| Chathuranga Chandrasekara · 技术社区 · 16 年前 | 
|   |      1 
                                  4
                             我发现很难相信当JVM崩溃时没有输出。首先,仔细研究一下运行脚本,看看是否只是忽略了输出。如果JVM由于未处理的异常而结束,它将把异常输出到我认为是stdout的。如果它崩溃很难(堆损坏等),它将输出一些东西到stderr。您的应用程序内日志记录很有用,但是您也应该将任何输出记录到stdout和stderr(您没有定义应用程序运行的平台,但这基本上适用于所有平台)。 除此之外,还有许多非标准选项可以通过它们来定义错误文件的位置等,请参见 Java HotSpot VM Options . | 
|   |      2 
                                  3
                             我会将您的应用程序日志调整到verboser级别,或者像前面所指出的那样调整JVM,但是如果您想要更多的选项,您可以尝试使用jvisualm来观察一些奇怪的东西(内存/线程/gc/jmx操作),最后,我会搜索 HSJEL 文件夹。 这些文件包含有关在硬盘崩溃时(内存冲突等)JVM状态的信息。 这里有一个例子:  | 
|   |      3 
                                  2
                             在崩溃之后,在崩溃过程中您没有日志,但是在实际崩溃之前您仍然拥有所有的日志。如果你的日志足够详细的话,这会给你很多信息。 在爪哇,你把两个阶段结合起来: 
 使用日志记录的功能,您应该能够一点一点地缩小您的焦点。注意,如果您的应用程序日志太少,您应该尽快开始添加更多的日志(当然是在适当的日志级别)。示例流程: 
 | 
|   |      4 
                                  2
                             | 
|   |      5 
                                  2
                             如果这个问题只发生在那个客户机上,询问他们是否在多台机器上运行应用程序。如果是的话,所有的问题都会发生吗? 如果问题只发生在一台机器上,我会怀疑硬件有问题,很可能是RAM。这可以用类似的工具来诊断 memtest . 我个人只看到了两个反复发生的JVM崩溃实例。在这两种情况下,问题都是RAM故障。 | 
|   |      6 
                                  2
                             一些有助于诊断内存问题的选项: 
   JVM选项
    
   阿尔索
    | 
|   |      7 
                                  1
                             如果您使用的是JNI(或任何使用JNI的库),那么很容易使JVM崩溃,这样就不会留下任何痕迹。据我所知,调试此类问题的唯一方法是使用调试器逐步调试本机内容。 | 
|   |      8 
                                  1
                             除了所有其他建议外,检查您的代码库是否有对System.Exit()的调用。 |