引言

值此七夕佳節，煙哥放棄了無數妹紙的邀約，坐在電腦面前碼字，就是為了給讀者帶來新的知識，這是一件偉大的事業！
好吧，實際情況是沒人約。為了化解尷尬，我決定賣力寫文章，嗯，一定是我過於屌絲！
好了，開始說重點。今天講的這個問題

JVM程序消失可能有哪些原因？

這個問題也是面試中經常出現的，如下圖所示

ps:由於兩年多沒寫crud了，所以忘記mybatis怎麼用了，所以上面那個問題，我選擇了無視。

那我們就開一篇文章說一下這個問題，其實很easy的，無外乎三種情況。

• linux的OOM killer殺死
• JVM自身故障
• jvm的OOM導致程序退出(很罕見，我至今沒遇見過)

引言

linux的OOM killer

Linux 核心有個機制叫OOM killer（Out-Of-Memory killer），該機制會監控那些佔用記憶體過大，尤其是瞬間很快消耗大量記憶體的程序，為了防止記憶體耗盡而核心會把該程序殺掉。
因此，你發現java程序突然沒了，首先要懷疑是不是被linux的OOM killer給幹掉了！
你可以去下面這個檔案裡翻

• 系統報錯日誌:/var/log/messages

你執行命令

egrep -i 'killed process' /var/log/messages

去日誌裡進行查詢。
當然，你也可以去核心日誌裡頭查詢。有時Linux系統或者系統上執行的java或者其它程序，會發生一些莫名其妙的問題，比如突然掛掉了，比如突然重啟等等。在軟體上找不到問題所在，此時我們應該懷疑硬體或者核心的問題，此時我們就可以使用 dmesg來檢視：

dmesg | grep java

輸出如下

[5673702.665338] Out of memory: Kill process 29953 (java) score 431 or sacrifice child
[5673702.665338] Killed process 29953, UID 500, (java) total-vm:9805316kB, anon-rss:2344496kB, file-rss:128kB

完全是可以看到核心對程序做對操作。

JVM自身故障

當JVM發生致命錯誤導致崩潰時，會生成一個hs_err_pid_xxx.log這樣的檔案，該檔案包含了導致 JVM crash 的重要資訊，我們可以通過分析該檔案定位到導致 JVM Crash 的原因，從而修復保證系統穩定。

-XX:ErrorFile=/var/log/hs_err_pid<pid>.log

這個檔案的內容他主要有如下內容

• 日誌標頭檔案
• 導致 crash 的執行緒資訊
• 所有執行緒資訊
• 安全點和鎖資訊
• 堆資訊
• 原生代碼快取
• 編譯事件
• gc 相關記錄
• jvm 記憶體對映
• jvm 啟動引數
• 伺服器資訊

拿到這個檔案後，不用說了，慢慢啃吧。說到這裡，我要摸著良心說。這個檔案巨複雜，如果要會讀這個檔案，請下點功夫。

JVM的OOM

坦白說，我很少遇到因為JVM的OOM，導致java程序退出的情況。
因為，一般情況下，出現OOM異常，JVM的GC會進行回收，是不會導致JVM程序退出的。要真說唯一導致退出的情況，那就是記憶體洩漏，由於記憶體佔用越來越大，結果。。。。
不過這種JVM的OOM導致的異常，很好排查。
因為，你注意兩個個引數

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=*/java.hprof；

然後去找dump快照檔案，接下來藉助VisualVM這種視覺化工具分析就行。很容易定位問題。

總結

綜上所述，正確回答是。先翻dump檔案，dump如果沒有，翻hs_err_pid.log日誌。如果還沒有，翻核心日誌。
如果上面還沒有，請聯絡煙哥解決