【发布时间】：2011-11-07 05:10:26
【问题描述】：
我的 Java 应用程序已经开始定期崩溃，出现 SIGSEGV 和堆栈数据转储以及文本文件中的大量信息。
我在 gdb 中调试了 C 程序，并从我的 IDE 中调试了 Java 代码。我不确定如何在正在运行的 Java 程序中处理类似 C 的崩溃。
我假设我不是在这里查看 JVM 错误。其他 Java 程序运行良好，Sun 的 JVM 可能比我的代码更稳定。但是，我不知道我怎么会导致 Java 代码出现段错误。肯定有足够的可用内存，当我上次检查分析器时，堆使用率约为 50%，偶尔峰值约为 80%。我可以调查任何启动参数吗？处理此类错误时，什么是好的清单？
虽然我目前还不能可靠地重现该事件，但它似乎也不是完全随机发生的，因此测试并非完全不可能。
预计到达时间：一些血腥细节
（我正在寻找一种通用方法，因为实际问题可能非常具体。不过，我已经收集了一些信息，这可能具有一定的价值。）
不久前，我在升级 CI 服务器后遇到了类似的问题（有关详细信息，请参阅 here），但这次修复（设置 -XX:MaxPermSize）并没有帮助。
进一步调查显示，在崩溃日志文件中，标记为“当前线程”的线程从来都不是我的，而是一个名为“VMThread”或一个名为“GCTaskThread”的线程——如果是后者，则另外标记带有注释“（退出）”，如果是前者，则 GCTaskThread 不在列表中。这让我认为问题可能在 GC 操作结束时出现。
【问题讨论】：
-
你能得到堆栈跟踪吗？是SEGV在同一个地方吗？我们可以提供更多信息吗？
-
您的应用程序中有本地代码吗？如果 JVM 允许任何字节码集合（无论该字节码有多么错误）来引发段错误，那么 ipso facto 您正在查看 JVM（或 JRE）错误。
-
@Ed - 我有很多堆栈跟踪，但它是一堵巨大的文字墙。发布什么部分最有用？我主要是在寻找解决此类问题的一般方法，因此我很犹豫在这里转储大量非常具体的信息。
-
@Henning - 也许吧。我有静态编织的类（eclipselink ORM）。事实上，我在介绍它们之后就开始看到问题了（在我进行动态编织之前，结果证明它不起作用）。然而，没有编织类，我有一个完全不同的问题集，很可能掩盖了段错误，所以我不能在这里假设因果关系。
-
@Henning - 我还向
-Xbootclasspath添加了探查器类，但我并不真正了解探查器的工作原理以及引导类路径到底是什么。此外，如果重要的话，我正在调试模式下运行（使用-Xdebug -Xrunjdwp）。