服務(wù)器應(yīng)用程序無(wú)緣無(wú)故被kill掉，應(yīng)該怎么辦？

近3個(gè)月至今，企業(yè)的某些網(wǎng)站服務(wù)器（java）莫名其妙的發(fā)生被kill掉狀況，緣故各不相同，清查下去也非常難受。那什么緣故會(huì)造成JAVA過(guò)程被kill呢？該如何去排查問(wèn)題呢？在這兒做一個(gè)匯總，跟大家分享下：

什么緣故可能會(huì)致使JAVA過(guò)程被kill呢？

Java程序的難題：產(chǎn)生OOM造成過(guò)程Crash

JVM本身常見(jiàn)故障：JVM或JDK本身的Bug造成過(guò)程Crash

被電腦操作系統(tǒng)OOM-Killer

該如何去排查問(wèn)題呢？

1.Java程序的難題：產(chǎn)生OOM造成過(guò)程Crash

這樣的事情關(guān)鍵在于產(chǎn)品研發(fā)編碼品質(zhì)，我碰到過(guò)的大約有2次。一般情況下，發(fā)生OOM出現(xiàn)異常，JVM的GC會(huì)開(kāi)展回收利用，是不會(huì)立即造成JVM過(guò)程撤出的。假如發(fā)生撤出的狀況，那便是內(nèi)存泄漏，因?yàn)閮?nèi)存占用越來(lái)越大，結(jié)論。。。。但是這類JVM的OOM造成的非常，非常好清查。清查流程如下所示：

Step1:查詢JVM主要參數(shù)-XX: HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath=*/java.hprof

Step2:依據(jù)HeapDumpPath特定的途徑查詢是不是造成dump文件；

Step3:若存有dump文件，應(yīng)用VisualVM這類數(shù)據(jù)分析工具剖析就可以了等專用工具剖析就可以；

2.JVM本身常見(jiàn)故障：JVM或JDK本身的Bug造成過(guò)程Crash

這樣的事情碰到一次，是由于JDK本身BUG造成的。當(dāng)JVM發(fā)生致命錯(cuò)誤時(shí)，會(huì)形成一個(gè)hs_err_pid_xxx.log這種文檔，該文件包含了造成jvmcrash的重要信息，能通過(guò)剖析該文檔精準(zhǔn)定位到造成crash的根本原因，進(jìn)而改進(jìn)以保證系統(tǒng)平穩(wěn)。當(dāng)發(fā)生crash時(shí)，該文檔默認(rèn)設(shè)置會(huì)形成到工作中目錄下，但是能通過(guò)jvm主要參數(shù)-XX:ErrorFile特定形成途徑，eg:

-XX:ErrorFile=/var/log/hs_err_pid.log

然依據(jù)錯(cuò)誤報(bào)告，能夠進(jìn)到JavaBUGdataBase庫(kù)文件去搜索相匹配的BUG：

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8134389

被電腦操作系統(tǒng)OOM-Killer

這樣的事情也遇到過(guò)一次。Linux核心有一個(gè)體制叫OOMkiller（Out-Of-Memorykiller），該制度會(huì)監(jiān)管這些占用內(nèi)存太大，特別是一瞬間迅速損耗很多運(yùn)行內(nèi)存的過(guò)程，為了避免運(yùn)行內(nèi)存耗光而核心能把該過(guò)程殺死?？梢匀?var/log/messages里翻系統(tǒng)報(bào)錯(cuò)日志，實(shí)行如下所示指令:

自然，你也可以去核心日志里面查看。有時(shí)候Linux系統(tǒng)或是系統(tǒng)軟件上運(yùn)作的java或是其他過(guò)程，會(huì)產(chǎn)生一些莫名其妙的難題，例如忽然掛掉了，例如忽然重新啟動(dòng)這些。在軟件上找不著問(wèn)題所在，這時(shí)我們應(yīng)該猜疑硬件配置或是核心的難題，此時(shí)此刻人們就能夠?qū)嵭衐mesg|grepjava指令來(lái)查詢：

徹底是能夠看見(jiàn)核心對(duì)過(guò)程做對(duì)實(shí)際操作。

匯總

對(duì)之上出現(xiàn)異常發(fā)生清查的排查次序一般是：Java程序的難題->JVM本身常見(jiàn)故障->被電腦操作系統(tǒng)OOM-Killer。若有疑惑詳情請(qǐng)騰佑科技客服熱線400-996-8756。