引言

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

這個問題也是面試中經(jīng)常出現(xiàn)的，如下圖所示

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

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

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

Linux 內(nèi)核有個機制叫OOM killer（Out-Of-Memory killer），該機制會監(jiān)控那些占用內(nèi)存過大，尤其是瞬間很快消耗大量內(nèi)存的進程，為了防止內(nèi)存耗盡而內(nèi)核會把該進程殺掉。

因此，你發(fā)現(xiàn)java進程突然沒了，首先要懷疑是不是被linux的OOM killer給干掉了！

你可以去下面這個文件里翻系統(tǒng)報錯日志:/var/log/messages

你執(zhí)行命令

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

去日志里進行查詢。

當然，你也可以去內(nèi)核日志里頭查詢。有時Linux系統(tǒng)或者系統(tǒng)上運行的java或者其它進程，會發(fā)生一些莫名其妙的問題，比如突然掛掉了，比如突然重啟等等。在軟件上找不到問題所在，此時我們應(yīng)該懷疑硬件或者內(nèi)核的問題，此時我們就可以使用 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

完全是可以看到內(nèi)核對進程做對操作。

JVM自身故障

當JVM發(fā)生致命錯誤導(dǎo)致崩潰時，會生成一個hs_err_pid_xxx.log這樣的文件，該文件包含了導(dǎo)致 JVM crash 的重要信息，我們可以通過分析該文件定位到導(dǎo)致 JVM Crash 的原因，從而修復(fù)保證系統(tǒng)穩(wěn)定。
默認情況下，該文件是生成在工作目錄下的，當然也可以通過 JVM 參數(shù)指定生成路徑：

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

這個文件的內(nèi)容他主要有如下內(nèi)容

• 日志頭文件
• 導(dǎo)致 crash 的線程信息
• 所有線程信息
• 安全點和鎖信息
• 堆信息
• 本地代碼緩存
• 編譯事件
• gc 相關(guān)記錄
• jvm 內(nèi)存映射
• jvm 啟動參數(shù)
• 服務(wù)器信息

拿到這個文件后，不用說了，慢慢啃吧。說到這里，我要摸著良心說。這個文件巨復(fù)雜，如果要會讀這個文件，請下點功夫。

JVM的OOM

坦白說，我很少遇到因為JVM的OOM，導(dǎo)致java進程退出的情況。

因為，一般情況下，出現(xiàn)OOM異常，JVM的GC會進行回收，是不會導(dǎo)致JVM進程退出的。要真說唯一導(dǎo)致退出的情況，那就是內(nèi)存泄漏，由于內(nèi)存占用越來越大，結(jié)果。。。。

不過這種JVM的OOM導(dǎo)致的異常，很好排查。

因為，你注意兩個個參數(shù)

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

然后去找dump快照文件，接下來借助VisualVM這種可視化工具分析就行。很容易定位問題。

總結(jié)

綜上所述，正確回答是。先翻dump文件，dump如果沒有，翻h(huán)s_err_pid.log日志。如果還沒有，翻內(nèi)核日志。
如果上面還沒有，請聯(lián)系煙哥解決。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論