服務(wù)器應(yīng)用程序被莫名其妙被K，該怎么辦？
發(fā)布時(shí)間：2020-01-09 點(diǎn)擊數(shù)：142
在過(guò)去的三個(gè)月中，由于各種原因，該公司的單個(gè)應(yīng)用程序服務(wù)器（java）莫名其妙地被K，檢查起來(lái)更加痛苦。是什么導(dǎo)致JAVA進(jìn)程被終止？如何解決問(wèn)題？在此處進(jìn)行總結(jié)并與您分享：
是什么導(dǎo)致JAVA進(jìn)程被終止？
Java應(yīng)用程序問(wèn)題：OOM導(dǎo)致進(jìn)程崩潰
JVM本身故障：JVM或JDK自身的錯(cuò)誤導(dǎo)致進(jìn)程崩潰
OMN-Killer按操作系統(tǒng)
如何解決問(wèn)題？
1. Java應(yīng)用程序問(wèn)題：OOM導(dǎo)致進(jìn)程崩潰
這種情況主要取決于R＆D代碼的質(zhì)量。我遇到過(guò)大約2次。在正常情況下，發(fā)生OOM異常時(shí)，JVM的GC將被回收，它不會(huì)直接導(dǎo)致JVM進(jìn)程退出。如果存在出口，則可能是內(nèi)存泄漏，結(jié)果是內(nèi)存使用量越來(lái)越大。 。 。 。但是，此JVM的OOM引起的異常非常好。故障排除步驟如下：
步驟1：查看JVM參數(shù)-XX：+ HeapDumpOnOutOfMemoryError和-XX：HeapDumpPath = * / java.hprof
步驟2：檢查轉(zhuǎn)儲(chǔ)文件是否根據(jù)HeapDumpPath指定的路徑生成。
步驟3：如果有轉(zhuǎn)儲(chǔ)文件，請(qǐng)使用可視工具（例如VisualVM）進(jìn)行分析。
2. JVM自身故障：JVM或JDK自身的錯(cuò)誤導(dǎo)致進(jìn)程崩潰
因?yàn)镴DK本身是由錯(cuò)誤引起的，所以會(huì)遇到這種情況。當(dāng)JVM中發(fā)生致命錯(cuò)誤時(shí)，將生成諸如hs_err_pid_xxx.log之類的文件。該文件包含導(dǎo)致jvm崩潰的重要信息。通過(guò)分析文件以定位崩潰的根本原因，可以改進(jìn)它以確保系統(tǒng)穩(wěn)定性。發(fā)生崩潰時(shí)，默認(rèn)情況下該文件將生成到工作目錄中。但是，可以通過(guò)jvm參數(shù)-XX：ErrorFile指定生成的路徑，例如：
-XX：ErrorFile = / var / log / hs_err_pid.log
根據(jù)錯(cuò)誤消息，您可以轉(zhuǎn)到Java BUG數(shù)據(jù)庫(kù)庫(kù)以找到相應(yīng)的BUG：
Https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8134389
OMN-Killer按操作系統(tǒng)
也曾經(jīng)遇到過(guò)這種情況。 Linux內(nèi)核具有一種稱為OOM殺手（Out-Of-Memory Killer）的機(jī)制。此機(jī)制監(jiān)視使用過(guò)多內(nèi)存的進(jìn)程，尤其是那些瞬間消耗大量?jī)?nèi)存的進(jìn)程。為了防止內(nèi)存耗盡，內(nèi)核將終止進(jìn)程。算了吧。您可以轉(zhuǎn)到/ var / log / messages并打開系統(tǒng)錯(cuò)誤日志。執(zhí)行以下命令：
是什么導(dǎo)致JAVA進(jìn)程被終止？
當(dāng)然，您也可以轉(zhuǎn)到內(nèi)核日志進(jìn)行查詢。有時(shí)，在Linux系統(tǒng)或系統(tǒng)上運(yùn)行的Java或其他進(jìn)程可能會(huì)有一些無(wú)法解釋的問(wèn)題，例如突然掛斷（例如突然重啟）。我們?cè)谲浖险也坏絾?wèn)題。在這一點(diǎn)上，我們應(yīng)該懷疑硬件或內(nèi)核問(wèn)題。此時(shí)，我們可以執(zhí)行dmesg | grep java命令查看：
是什么導(dǎo)致JAVA進(jìn)程被終止？
完全有可能看到內(nèi)核對(duì)進(jìn)程做了正確的事情。
總結(jié)一下
是什么導(dǎo)致JAVA進(jìn)程被終止？
Java應(yīng)用程序問(wèn)題：OOM導(dǎo)致進(jìn)程崩潰
JVM本身故障：JVM或JDK自身的錯(cuò)誤導(dǎo)致進(jìn)程崩潰
OMN-Killer按操作系統(tǒng)
如何解決問(wèn)題？
1. Java應(yīng)用程序問(wèn)題：OOM導(dǎo)致進(jìn)程崩潰
這種情況主要取決于R＆D代碼的質(zhì)量。我遇到過(guò)大約2次。在正常情況下，發(fā)生OOM異常時(shí)，JVM的GC將被回收，它不會(huì)直接導(dǎo)致JVM進(jìn)程退出。如果存在出口，則可能是內(nèi)存泄漏，結(jié)果是內(nèi)存使用量越來(lái)越大。 。 。 。但是，此JVM的OOM引起的異常非常好。故障排除步驟如下：
步驟1：查看JVM參數(shù)-XX：+ HeapDumpOnOutOfMemoryError和-XX：HeapDumpPath = * / java.hprof
步驟2：檢查轉(zhuǎn)儲(chǔ)文件是否根據(jù)HeapDumpPath指定的路徑生成。
步驟3：如果有轉(zhuǎn)儲(chǔ)文件，請(qǐng)使用可視工具（例如VisualVM）進(jìn)行分析。
2. JVM自身故障：JVM或JDK自身的錯(cuò)誤導(dǎo)致進(jìn)程崩潰
因?yàn)镴DK本身是由錯(cuò)誤引起的，所以會(huì)遇到這種情況。當(dāng)JVM中發(fā)生致命錯(cuò)誤時(shí)，將生成諸如hs_err_pid_xxx.log之類的文件。該文件包含導(dǎo)致jvm崩潰的重要信息。通過(guò)分析文件以定位崩潰的根本原因，可以改進(jìn)它以確保系統(tǒng)穩(wěn)定性。發(fā)生崩潰時(shí)，默認(rèn)情況下該文件將生成到工作目錄中。但是，可以通過(guò)jvm參數(shù)-XX：ErrorFile指定生成的路徑，例如：
-XX：ErrorFile = / var / log / hs_err_pid.log
根據(jù)錯(cuò)誤消息，您可以轉(zhuǎn)到Java BUG數(shù)據(jù)庫(kù)庫(kù)以找到相應(yīng)的BUG：
Https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8134389
OMN-Killer按操作系統(tǒng)
也曾經(jīng)遇到過(guò)這種情況。 Linux內(nèi)核具有一種稱為OOM殺手（Out-Of-Memory Killer）的機(jī)制。此機(jī)制監(jiān)視使用過(guò)多內(nèi)存的進(jìn)程，尤其是那些瞬間消耗大量?jī)?nèi)存的進(jìn)程。為了防止內(nèi)存耗盡，內(nèi)核將終止進(jìn)程。算了吧。您可以轉(zhuǎn)到/ var / log / messages并打開系統(tǒng)錯(cuò)誤日志。執(zhí)行以下命令：
是什么導(dǎo)致JAVA進(jìn)程被終止？
當(dāng)然，您也可以轉(zhuǎn)到內(nèi)核日志進(jìn)行查詢。有時(shí)，在Linux系統(tǒng)或系統(tǒng)上運(yùn)行的Java或其他進(jìn)程可能會(huì)有一些無(wú)法解釋的問(wèn)題，例如突然掛斷（例如突然重啟）。我們?cè)谲浖险也坏絾?wèn)題。在這一點(diǎn)上，我們應(yīng)該懷疑硬件或內(nèi)核問(wèn)題。此時(shí)，我們可以執(zhí)行dmesg | grep java命令查看：
是什么導(dǎo)致JAVA進(jìn)程被終止？
完全有可能看到內(nèi)核對(duì)進(jìn)程做了正確的事情。
總結(jié)一下
上述異常的故障排除順序通常是：Java應(yīng)用程序問(wèn)題-> JVM本身故障->操作系統(tǒng)的OSM-Killer。如果有其他疑問(wèn)可以咨詢?cè)凭W(wǎng)時(shí)代客服了解，云網(wǎng)時(shí)代專業(yè)提供深圳服務(wù)器租用，深圳服務(wù)器托管，深圳主機(jī)租用，云服務(wù)器租用等服務(wù)。