場景：我這邊從Hbase跑一億多的全量數(shù)據(jù)錄入Elasticsearch中，跑了四個多小時，程序突然掛掉了，然后我就納悶了，為啥突然掛掉了？？？

思路1:是不是Java 進程拋出OOM異常？
分析程序日志沒有任何異常，如果出現(xiàn)這種異常應(yīng)該會在日志中打印的啊，怎么沒有呢？

如果是java OOM異常會打印 Java heap space的

Exception in thread "pool-13-thread-25" java.lang.OutOfMemoryError: Java heap space Exception in thread "pool-13-thread-48" java.lang.OutOfMemoryError: Java heap space

后來我在JVM參數(shù)中添加了-XX:+UnlockExperimentalVMOptions和-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log看看垃圾回收情況以及如果出現(xiàn)OOM后生成java_pid30796.hprof文件然后利用Jprofile進行分析OOM異常根源，但是發(fā)現(xiàn)并沒有出現(xiàn)OOM異常，也沒有dump文件，因而可以確定并不是java OOM異常。

思路2:是不是linux保護機制強制殺死的進程？
其實一開始沒有看到程序OOM異常日志，就應(yīng)該想到是linux保護機制強行殺死的，搞的在上面饒了一大圈，浪費太多時間

然后百度，查看最近被linux kill掉的進程信息
執(zhí)行命令：dmesg | egrep -i -B100 'killed process'
輸出：

[20987454.255158] Out of memory: Kill process 24953 (java) score 805 or sacrifice child [20987454.255239] Killed process 24953 (java) total-vm:10973432kB, anon-rss:7284104kB, file-rss:0kB, shmem-rss:0kB

原因是Low memory耗盡。“內(nèi)核使用low memory來跟蹤所有的內(nèi)存分配，一旦low memory耗盡，就會查殺進程，以保持系統(tǒng)的正常運轉(zhuǎn)。說白了 OOM Killer 就是一層保護機制，用于避免 Linux 在內(nèi)存不足的時候不至于出太嚴重的問題，把無關(guān)緊要的進程殺掉

總結(jié)

以上是生活随笔為你收集整理的记录一次服务进程强行退出的问题排查过程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。