4

有没有办法解决这种错误报告：

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fc955e66998, pid=25851, tid=140467030525696
#
# JRE version: 6.0_37-b06
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.12-b01 mixed mode linux-amd64 compressed     oops)
# Problematic frame:
# J  java.util.LinkedHashMap.addEntry(ILjava/lang/Object;Ljava/lang/Object;I)V

?

崩溃发生得相当频繁（在 Web 服务器生产中每天 1-2 次），几乎总是有不同的问题框架报告。

以下是一些错误报告的示例：

# J  java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.addConditionWaiter()Ljava/util/concurrent/locks/AbstractQueuedSynchronizer$Node;
# J  java.util.LinkedHashMap.addEntry(ILjava/lang/Object;Ljava/lang/Object;I)V
# C  [libc.so.6+0x6bb34]
# C  [libgobject-2.0.so.0+0x2346f]  g_type_check_instance_is_a+0x43
# C  [libgobject-2.0.so.0+0x2346f]  g_type_check_instance_is_a+0x43
# V  [libjvm.so+0x4d3360]
# V  [libjvm.so+0x32d166]  CardTableRS::write_ref_field_gc_par(void*, oopDesc*)+0x26
# V  [libjvm.so+0x7a33e2]  ContiguousSpace::prepare_for_compaction(CompactPoint*)+0x242
# V  [libjvm.so+0x4d3360]
# V  [libjvm.so+0x76943b]  ReferenceProcessor::balance_queues(DiscoveredList*)+0x32b
# V  [libjvm.so+0x4d3360]
# V  [libjvm.so+0x32d166]  CardTableRS::write_ref_field_gc_par(void*, oopDesc*)+0x26
# V  [libjvm.so+0x4d3360]
# V  [libjvm.so+0x4d3360]
# V  [libjvm.so+0x76943b]  ReferenceProcessor::balance_queues(DiscoveredList*)+0x32b

似乎触发崩溃的唯一事情是大约 30gb 的高内存使用量，尽管情况并非总是如此（在 gc 日志显示内存使用量低的瞬间有一些崩溃）。在模式下运行时不会发生崩溃-Xint，但该模式太慢以至于无法选择。

似乎很难制作任何简单的“可重现代码”来重现复杂应用程序的生产环境中发生的错误。

该怎么办？不过，我确实在 Oracle 崩溃现场报告了其中的一堆……

我不怀疑硬件内存问题，因为除了 java 之外没有其他任何东西会崩溃。并且应用程序中没有自定义的原生 jni 代码。

我们的 vm 参数是-server -Xss4096k -Xms32255M -Xmx32255M -Xnoclassgc -XX:+UseNUMA -XX:MaxPermSize=512m -XX:+UseGCOverheadLimit -verbose:gc -Xmaxf1 -XX:+UseCompressedOops -XX:+DisableExplicitGC -XX:+AggressiveOpts -XX:+ScavengeBeforeFullGC -XX:CMSFullGCsBeforeCompaction=10 -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled -XX:GCTimeRatio=19 -XX:+UseAdaptiveSizePolicy -XX:MaxGCPauseMillis=500 -Xloggc:gc.log.

4

4 回答 4

0

虽然崩溃可能是由 JVM 错误引起的，但更有可能是由您编写的某些 JNI / JNA 本机代码引起的，或者是您正在使用的某些 3rd-party 库的一部分。

该怎么办？

这是一篇关于如何开始调试故障转储的博客：http ://www.javacodegeeks.com/2012/01/debugging-jvm.html

在您的情况下，报告都不同的事实将使问题更难追踪。听起来您可能对“随机”破坏堆对象有问题。

不过，我确实在 Oracle 崩溃现场报告了其中的一堆……

除非您有支持合同，否则 Oracle 不太可能回复您并提供解决方案。

于 2012-10-21T12:05:19.417 回答
0

如果崩溃频繁出现显然是随机原因，那么我会考虑可能的硬件问题（例如不可靠的 RAM）。我倾向于在服务器上运行完整的硬件诊断程序，看看是否会引发任何问题。

于 2012-10-21T12:23:12.733 回答
0

我在网上找到了这篇文章 ` 如果将 Java™ 虚拟机 (JVM) AggressiveOpts 选项与包含 Enterprise JavaBeans (EJB) 文件的 Java Platform Enterprise Edition (Java EE) 应用程序一起使用，JVM 可能会崩溃。要解决此问题，请使用以下参数禁用 DoEscapeAnalysis 优化：

-XX:+AggressiveOpts -XX:-DoEscapeAnalysis`:

http://www-01.ibm.com/support/docview.wss?uid=swg21422605

奇怪的是，这-XX:-CMSIncrementalMode使得系统非常不稳定，我不得不启用这个选项。

于 2012-10-24T04:08:32.543 回答
0

升级到 jdk7 Java(TM) SE 运行时环境（内部版本 1.7.0_09-b05），此后没有任何问题；以下 vmargs：

-server -Xss4096k -XX:MaxPermSize=512m -Xms32255M -Xmx32255M -Xnoclassgc -XX:+UseNUMA -XX:+UseBiasedLocking -XX:+UseFastAccessorMethods -XX:ReservedCodeCacheSize=48m -XX:+UseStringCache -XX:+HeapDumpOnOutOfMemoryError -XX:+UseGCOverheadLimit -Duser.timezone=EET -Xmaxf1 -XX:+UseCompressedOops -XX:+DisableExplicitGC -XX:+AggressiveOpts -XX:CMSInitiatingOccupancyFraction=70 -XX:+ParallelRefProcEnabled -XX:+UseAdaptiveSizePolicy -XX:MaxGCPauseMillis=100 -XX:+UseG1GC -XX:GCPauseIntervalMillis=3000 -XX:+PrintGCDetails -XX:+PrintHeapAtGC -Xloggc:gc.log
于 2012-12-05T13:12:03.323 回答