jdk6存在问题:# J java.util.LinkedHashMap.addEntry(ILjava/lang/Object;Ljava/lang/Object;I)V

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个回答

0

已升级到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

0
我在网上找到了这篇文章:“如果您在Java™虚拟机(JVM)中使用AggressiveOpts选项,并且该Java企业版(Java EE)应用程序包含Enterprise JavaBeans(EJB)文件,则JVM可能会崩溃。为解决此问题,请使用以下参数禁用DoEscapeAnalysis优化:-XX:+AggressiveOpts -XX:-DoEscapeAnalysis。”

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

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


0

虽然崩溃可能是由JVM bug引起的,但更有可能是由您编写的JNI / JNA本地代码或您正在使用的某个第三方库的一部分引起的。

怎么办?

这里有一篇关于如何开始调试崩溃转储的博客:http://www.javacodegeeks.com/2012/01/debugging-jvm.html

在您的情况下,报告都不同会使问题更难以追踪。听起来您可能遇到了一些“随机”破坏堆对象的问题。

我确实在Oracle崩溃站点报告了一堆这些问题...

除非您有支持合同,否则Oracle不太可能会向您提供解决方案。


应用程序中没有自定义的本地JNI代码。感谢提供链接;在生产应用程序中进行调试可能会很困难,因为它可能会在一天内随机崩溃,需要立即重新启动。是否有类似于Windows的东西?我可以轻松地在那里使其崩溃 ;) - Martin

0
如果崩溃频繁且原因似乎随机,那么我会考虑可能存在硬件问题(例如有问题的内存)。我倾向于在服务器上运行全面的硬件诊断,看看是否能找出任何问题。

与进程负载或其所执行的工作类型有任何相关性吗?与特定的JIT活动有任何相关性吗?(我曾经看到过仅在编译特定方法之后才发生崩溃的情况)。您尝试使用不同的GC算法了吗? - Matt
我们的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 - Martin
它在win7上1个核心和Linux 4个核心上崩溃。您是否有参考资料表明不建议在多核上使用CMSIncrementalMode?我的最近的崩溃是`EXCEPTION_ACCESS_VIOLATION(0xc0000005),pc=0x000000006d8c3215,pid=57148,tid=61948 #

JRE版本:6.0_37-b06

Java VM:Java HotSpot(TM) 64-Bit Server VM(20.12-b01 mixed mode windows-amd64 compressed oops)

有问题的帧:

V [jvm.dll+0xc3215]`和hotspot编译日志看起来并不可疑。

- Martin
链接在我之前的评论中(“详细信息”链接),基本上增量模式是一种将CMS工作的特定阶段分散到时间上,以避免它长时间占用唯一的核心的方法。 - Matt
看起来你可能遇到了一个热点 bug,我建议你在 hotspot-gc-devhotspot-gc-use 邮件列表中发帖。同时(这只是猜测),你可以尝试调整一些参数以确定是否达到了某种限制(例如,将堆大小设置小于 26G 以更改 compressedoop addressing 的方式,减小堆栈大小)。 - Matt
显示剩余9条评论

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接