解析Java橫死之謎,氣定神閒看花開花落

本文轉載自微信公眾號「小姐姐味道  」，作者小姐姐養的狗 。轉載本文請聯繫小姐姐味道公眾號。

Java進程突然不見了，日誌裡並沒有任何它們的信息，它們就那麼憑空蒸發了。日誌、OOM的一些配置參數，根本就不頂用。

不要驚慌。進程沒有靈魂。一個restart，會讓這些程序活蹦亂跳again。

問題是那些restart也無法解決的問題，還有默默在背後運作的墨菲定律。

是誰殺死了心愛的Java進程?

不要太絕情，在死之前，起碼要讓進程發表一點遺言吧。本小篇將分析幾種常見的Java進程消失之謎，讓你氣定神閒看花開花落。

它們有可能：

• 被作業系統審判了
• 執行了上帝函數，被隊友埋坑了
• 使用了錯誤的啟動方式
• 日誌系統配置錯誤

1. 被作業系統審判了

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

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

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

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

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

1. dmesg -T 

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

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

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

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

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

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

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

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

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

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

2. 執行了上帝函數

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

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

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

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

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

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

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

1. import java.security.Permission; 
2.  
3. public class S { 
4.     private static class ExitTrappedException extends SecurityException { 
5.     } 
6.     private static void forbidSystemExitCall() { 
7.         final SecurityManager securityManager = new SecurityManager() { 
8.             public void checkPermission(Permission permission) { 
9.                 if (permission.getName().startsWith("exitVM")) { 
10.                     throw new ExitTrappedException(); 
11.                 } 
12.             } 
13.         }; 
14.         System.setSecurityManager(securityManager); 
15.     } 
16.     private static void enableSystemExitCall() { 
17.         System.setSecurityManager(null); 
18.     } 
19.     public static void main(String[] args) { 
20.         forbidSystemExitCall(); 
21.         try { 
22.             System.exit(0); 
23.         }catch (Exception ex){ 
24.             ex.printStackTrace(); 
25.         } 
26.         System.out.println("謝謝xjjjdog, 我依然能夠執行"); 
27.     } 
28. } 

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

3. 錯誤的啟動方式

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

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

1. java com.cn.AA & 

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

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

1. nohup java com.cn.AA & 

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

4.日誌配置錯誤

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

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

使用下面的命令，可以將依賴樹轉移到log文件裡進行分析。

1. mvn dependency:tree > dep.log 

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

1. public static void main(String[] args) { 
2.   try { 
3.    SpringApplication.run(LinkpowerDtulockApplication.class, args); 
4.   } catch (Exception e) { 
5.    System.out.println(e); 
6.   } 
7. } 

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

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

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

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

作者簡介：小姐姐味道 (xjjdog)，一個不允許程式設計師走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高並發世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。

【編輯推薦】

【責任編輯：

武曉燕

TEL：[phone]】

點讚 0