在客戶(hù)一臺(tái)機(jī)器上出現(xiàn)JVM掛掉的問(wèn)題，大概是一個(gè)月就會(huì)發(fā)生一次。在JVM自動(dòng)生成的hs_err文件，看到以下內(nèi)容.

# A fatal error has been detected by the java Runtime Environment:##  EXCEPTION_access_VIOLATION (0xc0000005) at pc=0x000000226b53ea00, pid=3880, tid=3182## JRE version: Java(TM) SE Runtime Environment (8.0_72-b15) (build 1.8.0_72-b15)# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.72-b15 mixed mode windows-amd64 comPRessed oops)# Problematic frame:# V  [jvm.dll+0xaea10]## Core dump written. Default location: D:/hs_err_pid3880.mdmp## If you would like to submit a bug report, please visit:#   http://bugreport.java.com/bugreport/crash.jsp
從hs_err文件中可以看到，好像是在執(zhí)行垃圾收集的時(shí)候報(bào)錯(cuò)的，可能是JVM本身的問(wèn)題。在網(wǎng)上查找了好久，找到了JDK-8149428(https://bugs.openjdk.java.net/browse/JDK-8149428)，由些懷疑是JVM的bug.有同事給Oracle的java研發(fā)人員發(fā)郵件，對(duì)方回復(fù)說(shuō)是java的bug，但由于不能重現(xiàn)，也沒(méi)什么好的解決方法，建議我們加內(nèi)存。加內(nèi)存我們嘗試過(guò)，可客戶(hù)不同意，還堅(jiān)持要我們解決掉這個(gè)問(wèn)題。涉及到JVM底層的bug，直接解決可不容易。經(jīng)過(guò)多次糾結(jié)的討論、溝通，由于當(dāng)前使用的是G1垃圾收集，決定嘗試不使用G1，退回到以前的CMS垃圾收集。客戶(hù)使用CMS之后，一個(gè)多月沒(méi)出現(xiàn)問(wèn)題，終于得到圓滿(mǎn)解決。團(tuán)隊(duì)的力量就是強(qiáng)大。不過(guò)在客戶(hù)環(huán)境上，什么奇怪的問(wèn)題都有，這個(gè)問(wèn)題也只是發(fā)生在這一個(gè)客戶(hù)上面。