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