JDK6有問題的框架：＃Ĵjava.util.LinkedHashMap.addEntry（ILjava /郎/對象; Ljava /郎/對象;我）V

是否有解決這種錯誤報告的方式：JDK6有問題的框架：＃Ĵjava.util.LinkedHashMap.addEntry（ILjava /郎/對象; Ljava /郎/對象;我）V

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

來源

2012-10-21 Martin

升級到jdk7 Java™SE運行時環境（build 1.7.0_09-b05）並且從此沒有任何問題; follwing 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-05 13:12:03 Martin

雖然崩潰可能是由JVM錯誤引起的，但它更可能是由您編寫的一些JNI/JNA本機代碼引起的，或者是您所在的某些第三方庫的一部分使用。

怎麼辦？

下面是關於如何開始使用調試崩潰轉儲啓動該主題的博客：http://www.javacodegeeks.com/2012/01/debugging-jvm.html

在你的情況，事實的報告是不同將會使問題更加難以追查。它聽起來像像你可能有一個問題「隨機」腐蝕堆對象。

我也除非你有一個支持合同在甲骨文失事地點雖然報告這些一堆......

，甲骨文不可能有解決方案要回你。

來源

2012-10-21 12:05:19

應用程序中沒有自定義原生jni代碼。感謝您的鏈接;生產應用程序將很難調試，因爲它可能會在白天隨機崩潰，然後應立即重新啓動。有沒有類似的窗戶？我可以很容易地崩潰;） – Martin

如果崩潰頻繁出現明顯的隨機原因，那麼我會考慮可能的硬件問題（例如不友好的RAM）。我傾向於在服務器上運行一整套硬件診斷，看看是否會拋出任何東西。

來源

2012-10-21 12:23:12 Matt

它發生在Windows 7 64位（更頻繁/更敏感）和Linux 64位服務器上。我不懷疑硬件內存問題，因爲沒有其他任何事情崩潰，除了Java。 – Martin

與流程負載或正在執行的工作類型是否有任何關聯？與特定JIT活動的任何關聯？（我見過之前只有在編譯特定方法之後才發生崩潰）。你有沒有嘗試過不同的GC算法？ – Matt

我們的VM參數'-server -Xss4096k -Xms32255M -Xmx32255M -Xnoclassgc -XX：+ UseNUMA -XX：MaxPermSize參數=512米-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' – Martin

我在網上找到這篇文章如果您在包含Enterprise JavaBeans（EJB）文件的Java平臺企業版（Java EE）應用程序中使用Java™虛擬機（JVM）AggressiveOpts選項，則JVM可能會崩潰。要解決此問題，使用以下參數禁用DoEscapeAnalysis優化：

-XX：+ AggressiveOpts -XX：-DoEscapeAnalysis`：

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

奇怪的是，這-XX:-CMSIncrementalMode使系統非常不穩定，我必須啓用此選項。

來源

2012-10-24 04:08:32 Martin

JDK6有問題的框架：＃Ĵjava.util.LinkedHashMap.addEntry（ILjava /郎/對象; Ljava /郎/對象;我）V

回答

相關問題