当垃圾收集期间JVM崩溃(段错误)时,如何找出收集的内容？

Question

我在应用程序的大致相同的阶段在我的JVM中获得了段错误,但崩溃报告中的堆栈跟踪不同.但是,它似乎总是在GC期间发生.

由于崩溃发生在我尝试的所有三个JVM(OpenJDK 6,Oracle 1.6.0_25和1.7.0)以及每个两个GC(并行收集器和CMS),它发生在应用程序的同一区域,我想,如果我可以找到GC试图收集的内容,我可能会在我的代码中发现导致此崩溃的一些特性.

• 是否存在众所周知的GC编码实践？
• 有哪些方法可用于诊断此问题？
• 我可以对我的应用程序中触发此问题的位置进行任何有根据的猜测吗？
• 我可以使用什么(GC调整)参数来缩小问题范围？
• 有没有办法在堆转储中发现(可能)有问题的数据？

Answer 1

如果您有错误处理内存的JNI库,则会发生这种情况.问题没有立即显示.但是,执行GC时,它会扫描所有内存,跳过损坏的引用并杀死JVM.即自上次完整GC以来的任何时候都可能发生腐败.

Answer 2

• seg 错误在转储开始时有特定的错误代码 http://en.wikipedia.org/wiki/Segmentation_fault

• 您可以使用 Thread.dumpStackTrace 来查看该应用程序中发生的情况如果您确切知道应用程序在某个操作或事件之后冻结或将冻结的位置，您可以按 CTRL + 中断窗口或 CTRL + \ 来获取线程转储并看看发生了什么事。

• 您可以注释掉代码的某些部分来找出哪个循环、对象、缓冲区或字符串花费的时间太长，而不是模糊地猜测

• 根据您的情况，您可以考虑一些特定的工具。