JVM服務進程掛掉問題定位查詢思路

 

昨天有朋友諮詢了個RegionServer宕機找不到日誌沒法定位緣由的問題，乾脆就係統整理下JVM服務宕機的可能緣由，方便按照思路去找真正的宕機緣由。

1. abort()/halt()/exit()

有些服務會採用lei it crash的思想，在一些超時較久、資源不足的場景下可能會採起直接abort（像部分C服務也會對一些錯誤的參數直接abort產生core），尤爲在HBase RegionServer和Phoenix 實現的coprocessor裏有好幾處這樣的代碼。一般魯棒性高的服務abort後也會有對應的主從、多活、拉起等措施保證用戶端影響最小。

在實現的好的代碼中，全部退出都應當是有日誌的。所以首先看本身的服務日誌有沒有相關退出信息。這裏需注意，Java用通用的log4j可能還比較好；部分C++的logger配置很差的話，爲了性能，flush落盤頻率較低，偶爾會有服務退出了，日誌沒刷完的狀況。

2. 非人爲代碼的JVM 虛擬機退出
一般有幾種狀況：
2.1.  JVM自己問題，最多見的就是各種OOM。這個調vm配置、調GC優化就行了。
2.2. JNI退出。若是調用了一些第三方JNI，有時有可能會出現JNI裏的C/C++代碼core了致使vm崩潰。此時通常會打出 dump日誌（強烈建議jvm啓動時加上dump參數指定dump日誌位置），dump日誌裏會有core的緣由，c++的stacktrace，崩潰時的一些內存信息等信息。若是開啓了core的機器(ulimit -c 設置)，還會見到.core文件的產生，可用於gdb跟蹤。
2.3. OS內存不足kill進程。這種是看起來悄無聲息地結束的，沒有dump日誌和core。此時須要看下os級別的日誌 /var/log/message，翻到宕機時間點，一般能看到OOM killed的信息。

3. 服務器關機/重啓
此時和你的服務不必定有什麼關係了。需聯繫運維先查清楚服務器關機的緣由，一般是人爲或定時reboot、硬件兼容、內核問題等。