jdk6 有问题的框架：# J java.util.LinkedHashMap.addEntry(ILjava/lang/Object;Ljava/lang/Object;I)V答案

【问题标题】：jdk6 Problematic frame: # J java.util.LinkedHashMap.addEntry(ILjava/lang/Object;Ljava/lang/Object;I)Vjdk6 有问题的框架：# J java.util.LinkedHashMap.addEntry(ILjava/lang/Object;Ljava/lang/Object;I)V
【发布时间】：2012-10-21 11:46:59
【问题描述】：

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

# 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 代码。

我们的虚拟机参数是-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。

【问题讨论】：

标签： java jvm-crash

【解决方案1】：

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

怎么办？

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

在您的情况下，报告完全不同的事实将使问题更难追查。 听起来您可能遇到了一些“随机”破坏堆对象的问题。

不过，我确实在 Oracle 崩溃现场报告了很多这样的情况......

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

【讨论】：

应用中没有自定义的原生 jni 代码。感谢您的链接；很难调试生产应用程序，因为它可能会在白天随机崩溃，然后应该立即重新启动。窗户有类似的东西吗？我可以在那里很容易地崩溃；）

【解决方案2】：

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

【讨论】：

它发生在 Windows 7 64 位（更频繁/更敏感）和 Linux 64 位服务器上。我不怀疑硬件内存问题，因为除了 java 之外没有其他任何东西会崩溃。
与流程负载或正在执行的工作类型有任何关联吗？与特定的 JIT 活动有任何关联吗？（我见过只有在特定方法之前编译后才发生的崩溃）。您是否尝试过不同的 GC 算法？
我们的vm参数是-server -Xss4096k -Xms32255M -Xmx32255M -Xnoclassgc -XX:+UseNUMA -XX:MaxPermSize=512m -XX:+UseGCOverheadLimit -verbose:gc -Xmaxf1 -XX:+U seCompressedOops -XX:+DisableExplicitGC -XX:+AggressiveOpts -XX:+ScavengeBeforeF ullGC -XX:CMSFullGCsBeforeCompaction=10 -XX:CMSInitiatingOccupancyFraction=70 -X X:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrement alPacing -XX:+CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled -XX:GCTimeRatio=19 -XX:+UseAdaptiveSizePolicy -XX:MaxGCPauseMillis=500 -Xloggc:gc.log
如何监控“特定的 JIT 活动”？我想这可能与 GC 有关，但我们似乎需要它们来处理垃圾，所以此时非常小心地尝试其他算法；）
JIT 活动可以使用-XX:+PrintCompilation 或LogCompilation 来查看，前者不提供时间戳，因此您需要编写一些内容来查看它，以便知道它何时在做某事

【解决方案3】：

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

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

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

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

【讨论】：

【解决方案4】：

升级到 jdk7 Java(TM) SE Runtime Environment (build 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

【讨论】：