当 JVM 在垃圾收集期间崩溃（段错误）时，我如何才能找出正在收集的内容？答案

【问题标题】：When a JVM crashes (segfaults) during garbage collection, how can I find out what was being collected?当 JVM 在垃圾收集期间崩溃（段错误）时，我如何才能找出正在收集的内容？
【发布时间】：2011-12-27 04:00:09
【问题描述】：

我的 JVM 中大致在应用程序的同一阶段遇到了段错误，但在崩溃报告中具有不同的堆栈跟踪。然而，它似乎总是在 GC 期间发生。

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

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

【问题讨论】：

添加了 JNI 标签，因为正如 Peter Lawrey 已经指出的那样，它显然是某些 JNI 库中的一个错误。
我很想看看是什么导致了崩溃。
我已经设法在没有 jni 的情况下使 Sun jvm 崩溃。
无论如何，它是 Eclipselink。我只知道。它必须去。它已经来了很长时间。我会自己拿出来。
@Casey 当然可以，但是与一些损坏的 JNI 函数相比，JVM 实现中出现错误的可能性有多大？

标签： java garbage-collection jvm segmentation-fault java-native-interface

【解决方案1】：

我们也面临着类似的问题。我们看不到任何模式，而且非常随机，但发生在 GC 或 Full GC 上。对我们来说，事实证明这是 RAM 模块的问题。我们在 Ubuntu 服务器上使用 MemTest86+ 识别它。

【讨论】：

【解决方案2】：

我建议您同时获取线程转储和堆转储，您可以从命令行执行此操作，使用类似Visual VM 的工具
我认为作为 JVM 内存快照的堆转储将提供有关活动对象及其分配的信息。如果您使用 Visual VM 分析堆，它会提供有关堆上所有对象的详细报告
我建议你在你的应用程序中增加 GC 集合，以便使用 tagtraum 之类的工具来详细分析它们。
如果您可以附上可以提供大量信息的 JVM profiler，或者如果您对导致问题的工作流程有大致的了解，则只需单独对其进行分析

【讨论】：

【解决方案3】：

seg 错误在转储的开头有特定的错误代码 http://en.wikipedia.org/wiki/Segmentation_fault
您可以使用 Thread.dumpStackTrace 查看该应用程序中发生了什么如果您确切地知道您的应用程序在某个操作或事件之后冻结或将冻结的位置，您可以 CTRL + 中断窗口或 CTRL + \ 以获取线程转储并查看发生了什么。
您可以注释掉代码的某些部分，而不是模糊地猜测，以找出哪个循环或对象或缓冲区或字符串花费的时间太长
根据您的情况，您可以考虑一些特定的工具。

【讨论】：

【解决方案4】：

如果您的 JNI 库处理内存不正确，就会发生这种情况。问题不会立即显示。但是，当执行 GC 时，它会扫描所有内存，跳过损坏的引用并杀死 JVM。即自上次 Full GC 以来的任何时间都可能发生损坏。

【讨论】：

听起来很难调试。有什么我能做的吗？
那么，即使问题似乎发生在 GC 期间，但这并不能将其缩小到终结器中的错误？
@HannoFietz 好吧，有 Valgrind 和 Co，但问题是 Hotspot 代码本身是......好吧，它破坏了大多数（我会说全部，但谁知道）这些工具。不知道你是否可以让 valgrind 只检查你自己的代码。
@RaedWald 如果没有底层 JVM 中的错误，您将无法在纯 Java 代码中产生段错误（这是可能的，但不太可能）。 GC 必须查看（并遍历）所有指针，所以如果你将垃圾写入其中一个它会出错，这就是它的全部。
有没有办法识别堆转储中的问题数据？我可能能够制作一个可能包含它的东西。