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

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

1. 被操作系統審判了

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

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

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

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

為了能看到發生的時間，我們習慣性加上參數T

dmesg -T

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

這個現象，和Linux的內存管理有關。

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

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

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

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

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

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

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

一旦你這么做，你的Java進程就是特權階層了，可以無視規則。

2. 執行了上帝函數

xjjdog對這個函數的評價是：比你起認識它，還不如你不認識它。

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

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

相信我，你并沒有需要用程序判斷來立即結束進程的需求，業務系統尤其沒有。如果有，那大概率是不合理的。除非你把Java當腳本用了。

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

使用exit函數，一定要心存善意。

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

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, 我依然能夠執行");     } }

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

3. 錯誤的啟動方式

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

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

java com.cn.AA &

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

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

nohup java com.cn.AA &

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

4.日志配置錯誤

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

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

使用下面的命令，可以將依賴樹轉移到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);   } }

這樣有什么異常情況，就可以早點發現。

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

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

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

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