昨天有朋友咨詢了個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、硬件兼容、內核問題等。

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