[[358408]]

本文轉載自微信公眾號「小姐姐味道  」，作者小姐姐養(yǎng)的狗 。轉載本文請聯(lián)系小姐姐味道公眾號。

Java進程突然不見了，日志里并沒有任何它們的信息，它們就那么憑空蒸發(fā)了。日志、OOM的一些配置參數(shù)，根本就不頂用。

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

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

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

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

它們有可能：

• 被操作系統(tǒng)審判了
• 執(zhí)行了上帝函數(shù)，被隊友埋坑了
• 使用了錯誤的啟動方式
• 日志系統(tǒng)配置錯誤

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

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

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

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

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

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

dmesg -T 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當然我們并不是對此束手無策。下面這段代碼，就可以阻止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ā)生的一種情況，會造成應用程序的意外死亡：那就是對Java程序錯誤的啟動方式。

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

java com.cn.AA & 

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

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

nohup java com.cn.AA & 

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

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); 
  } 
} 

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

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

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

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

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