如何解決Java進程不見了的問題

本篇內(nèi)容介紹了“如何解決Java進程不見了的問題”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

1. 被操作系統(tǒng)審判了

以下問題已經(jīng)不止一個小伙伴遇到了：我的java進程沒了，什么都沒留下，直接蒸發(fā)不見了。

why?是因為太多情，對象太多了么?

這是趣味性和技巧性非常突出的一個問題。

執(zhí)行dmesg命令，大概率會看到你的進程崩潰信息躺尸在那里。

為了能看到發(fā)生的時間，我們習(xí)慣性加上參數(shù)T

dmesg -T

明顯是操作系統(tǒng)看你的進程不順眼，給Kill了。

這個現(xiàn)象，和Linux的內(nèi)存管理有關(guān)。

由于Linux系統(tǒng)采用的是虛擬內(nèi)存分配方式，JVM的代碼，庫，堆和棧的使用都會消耗內(nèi)存，但是申請出來的內(nèi)存，只要沒真正access過，是不算的，因為沒有真正為之分配物理頁面。

隨著使用內(nèi)存越用越多。第一層防護墻就是SWAP;當(dāng)SWAP也用的差不多了，會嘗試釋放cache;當(dāng)這兩者資源都耗盡，殺手就出現(xiàn)了。oom  killer會在系統(tǒng)內(nèi)存耗盡的情況下跳出來，選擇性的干掉一些進程以求釋放一點內(nèi)存。

所以這時候我們的Java進程，是操作系統(tǒng)“主動”終結(jié)的，JVM連發(fā)表遺言的機會都沒有。這個信息，只能在操作系統(tǒng)日志里找。

要解決這種問題，首先不能太貪婪。比如一共8GB的機器，你把整整7.5GB分配給了JVM。當(dāng)操作系統(tǒng)內(nèi)存不足，你的JVM就可能成為oom-killer的獵物。

不過，通過下面的命令，可以讓進程避免被審判。

echo -17 > /proc/[PID]/oom_adj

這是因為，oom_adj文件，就是進程被oom killer殺掉的權(quán)重，一般介于 [-17,15]之間。越高的權(quán)重，意味著更可能被oom  killer選中。

一旦你這么做，你的Java進程就是特權(quán)階層了，可以無視規(guī)則。

2. 執(zhí)行了上帝函數(shù)

xjjdog對這個函數(shù)的評價是：比你起認(rèn)識它，還不如你不認(rèn)識它。

這位函數(shù)你不要瞅我。說的就是你，System.exit。

這個函數(shù)危險得很，它將強制終止我們的應(yīng)用，而且什么都不會留下。你應(yīng)該掃描你的代碼，確保這樣的邏輯不會存在。

相信我，你并沒有需要用程序判斷來立即結(jié)束進程的需求，業(yè)務(wù)系統(tǒng)尤其沒有。如果有，那大概率是不合理的。除非你把Java當(dāng)腳本用了。

這個函數(shù)，是一個非常高級的埋坑技能，尤其是在Android之類的應(yīng)用中。應(yīng)用程序崩潰，你將什么原因都分析不到，哪怕你做了ShutdownHook。

使用exit函數(shù)，一定要心存善意。

當(dāng)然我們并不是對此束手無策。下面這段代碼，就可以阻止exit的執(zhí)行，霸道非凡。上帝的那只手，也給掰回去。

import java.security.Permission;  public class S {     private static class ExitTrappedException extends SecurityException {     }     private static void forbidSystemExitCall() {         final SecurityManager securityManager = new SecurityManager() {             public void checkPermission(Permission permission) {                 if (permission.getName().startsWith("exitVM")) {                     throw new ExitTrappedException();                 }             }         };         System.setSecurityManager(securityManager);     }     private static void enableSystemExitCall() {         System.setSecurityManager(null);     }     public static void main(String[] args) {         forbidSystemExitCall();         try {             System.exit(0);         }catch (Exception ex){             ex.printStackTrace();         }         System.out.println("謝謝xjjjdog, 我依然能夠執(zhí)行");     } }

如果你用盡千方百計，都找不到異常終止的原因，試試掛上這段代碼吧。有可能是救命的哦。

3. 錯誤的啟動方式

再聊一種最初級最常見還經(jīng)常發(fā)生的一種情況，會造成應(yīng)用程序的意外死亡：那就是對Java程序錯誤的啟動方式。

很多同學(xué)對Linux不是很熟悉，使用XShell登陸之后，調(diào)用下面的命令進行啟動。

java com.cn.AA &

這位同學(xué)還算有點意識，在最后使用了&號，以期望進程在后臺運行。但可惜的是，很多情況下，隨著XShell  Tab頁的關(guān)閉，或者等待超時，后面的Java進程就隨著一塊停止了，很讓人困惑。

正確的啟動方式，就是使用nohup關(guān)鍵字，或者阻塞在其他更加長命的進程里(比如docker)。

nohup java com.cn.AA &

所以，當(dāng)你登錄上終端tty的時候，一定要鬧明白當(dāng)前執(zhí)行的父進程是誰。你可能是所有接下來要運行的所有進程的祖先哦。

4.日志配置錯誤

如果上面的原因都不是，那大概率是你的項目里面日志框架的配置錯誤了。Java中的日志框架繁多，配置方式多樣，一不小心，就會踩坑。即使你用的是SpringBoot，也會因為依賴包的問題，造成啟動問題。

日志配置錯誤+異常情況，當(dāng)然是什么都不會留下。

使用下面的命令，可以將依賴樹轉(zhuǎn)移到log文件里進行分析。

mvn dependency:tree > dep.log

如果是SpringBoot項目，是可以給main類加點代碼的。

public static void main(String[] args) {   try {    SpringApplication.run(LinkpowerDtulockApplication.class, args);   } catch (Exception e) {    System.out.println(e);   } }

這樣有什么異常情況，就可以早點發(fā)現(xiàn)。

End另外，還有一些千奇百怪的原因。比如磁盤滿了，句柄不夠了，這些情況都很隱蔽，需要你精確把控系統(tǒng)的細節(jié)。

進程這種靜悄悄的死亡方式，通常會給我們的問題排查帶來更多的困難。

通常，我們在關(guān)閉服務(wù)的時候，會使用“kill -15”，而不是“kill  -9”，以便讓服務(wù)在臨死之前喘口氣。但并不總是有效，因為程序壓根就沒有機會發(fā)表遺言，有更高級別的存在阻止了它。Java進程橫死，我們只能尋找其他手段。

“如何解決Java進程不見了的問題”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！