背景
用戶：貨都到了，購物車里怎么還有剛買的東西，what?
產品：有用戶反映，提單完成了，怎么沒清購物車，研發趕緊看看是不是有bug啊？
研發：恩，我看看，！@#￥%……&*（）一頓狂查，搜嘎，當時在上線，重啟應用，異步任務丟了……
產品：能不能行，上線你就丟任務，丟不丟人啊！
研發：…………
上線!重啟!你還在為丟失任務而煩惱么？看這里看這里，從此不再丟任務，JVM可以安全退出的
在交易流程中，為了提升服務的性能，我們做了一些異步化的優化，比如更新用戶最近使用的收貨地址、提單完成后通過MQ去發送各種通知類消息、清理用戶的購物車等等這些操作，異步化加快了應用的響應速度同時也帶來一個隱患，如何保障異步操作的執行？這個場景主要發生在應用重啟時，對於通過線程或線程池進行的異步化，JVM重啟時，后台執行的異步操作可能尚未完成。這時，需要通過JVM安全關閉來保證異步操作進行完成后，JVM再執行關閉。
更廣泛的說，在Linux上很多應用通常會通過kill -9 pid的方式強制將進程殺掉，這種方式簡單高效，因此很多應用的停止腳本經常會選擇使用kill -9 pid的方式。強制進程退出,會帶來一些副作用，對應用程序而言其效果等同於突然掉電，可能會導致如下一些問題：
- 緩存中的數據尚未持久化到磁盤中，導致數據丟失；
- 正在進行文件的write操作，沒有更新完成，突然退出，導致文件損壞；
- 線程池的任務隊列中尚有接收到的任務還沒來得及處理，導致任務丟失；
- 數據庫操作已經完成，例如賬戶余額更新，准備返回應答消息給客戶端時，消息尚在通信線程的發送隊列中排隊等待發送，進程強制退出導致應答消息沒有返回給客戶端，客戶端發起超時重試，會帶來重復更新問題；
- 其它問題等…
這些問題都有可能對我們的業務產生影響，造成不必要的損失，為了避免這些問題，我們需要在JVM關閉時做些掃尾的工作，為此JVM提供了關閉鈎子（shutdown hooks）來做這些事情。本文探討了利用關閉鈎子的相關內容。
JVM 關閉
首先，我們了解下哪些情況會導致JVM關閉，如下圖
對於強制關閉的幾種情況，系統關機，操作系統會通知JVM進程關閉並等待，一旦等待超時，系統會強制中止JVM進程；kill -9、Runtime.halt()、斷電、系統crash這些種方式會直接無商量中止JVM進程，JVM完全沒有執行掃尾工作的機會。因此對用應用程序而言，我們強烈不建議使用kill -9 這種暴力方式退出。
而對於正常關閉、異常關閉的幾種情況，JVM關閉前，都會調用已注冊的shutdown hooks，基於這種機制，我們可以將掃尾的工作放在shutdown hooks中，進而使我們的應用程序安全的退出。基於平台通用性的考慮，我們更推薦應用程序使用System.exit(0)這種方式退出JVM。
JVM 與 shutdown hooks 交互流程如下圖所示，可以對照源碼進一步的學習shutdown hooks工作原理。
Jvm安全退出
對於tomcat類Web應用，我們可以直接通過Runtime.addShutdownHook(Thread hook)注冊自定義鈎子，在鈎子中實現資源的清理；而對於worker類應用，我們可以采用如下的方式安全的退出應用。
基於信號的進程通知機制
信號是在軟件層次上對中斷機制的一種模擬，在原理上，一個進程收到一個信號與處理器收到一個中斷請求可以說是一樣的。通俗來講，信號就是進程間的一種異步通信機制。信號具有平台相關性，Linux平台支持的一些終止進程信號如下所示：
| 信號名稱 | 用途 |
|---|---|
| SIGKILL | 終止進程，強制殺死進程 |
| SIGTERM | 終止進程，軟件終止信號 |
| SIGTSTP | 停止進程，終端來的停止信號 |
| SIGPROF | 終止進程，統計分布圖用計時器到時 |
| SIGUSR1 | 終止進程，用戶定義信號1 |
| SIGUSR2 | 終止進程，用戶定義信號2 |
| SIGINT | 終止進程，中斷進程 |
| SIGQUIT | 建立CORE文件終止進程，並且生成core文件 |
Windows平台存在一些差異，它的一些信號舉例如下所示：
| 信號名稱 | 用途 |
|---|---|
| SIGINT | Ctrl+C中斷 |
| SIGTERM | kill發出的軟件終止 |
| SIGBREAK | Ctrl+Break中斷 |
信號選擇：為了不干擾正常信號的運作，又能模擬Java異步通知，在Linux上我們需要先選定一種特殊的信號。通過查看信號列表上的描述，發現 SIGUSR1 和 SIGUSR2 是允許用戶自定義的信號,我們可以選擇SIGUSR2，在Windows上我們可以選擇SIGINT。
通過這種信號機制，對應用程序JVM發送特定信號,JVM可以感知並處理該信號，進而可以接受程序退出指令。
安全退出實現
首先看下通用的JVM安全退出的流程圖：
第一步，應用進程啟動的時候，初始化Signal實例，它的代碼示例如下：
1 Signal sig = new Signal(getOSSignalType());
其中Signal構造函數的參數為String字符串，也就上文介紹的信號量名稱。
第二步，根據操作系統的名稱來獲取對應的信號名稱，代碼如下：
1 private String getOSSignalType() 2 { 3 return System.getProperties().getProperty("os.name"). 4 toLowerCase().startsWith("win") ? "INT" : "USR2"; 5 }
判斷是否是windows操作系統，如果是則選擇SIGINT，接收Ctrl+C中斷的指令；否則選擇USR2信號，接收SIGUSR2（等價於kill -12 pid）指令。
第三步，將實例化之后的SignalHandler注冊到JVM的Signal，一旦JVM進程接收到kill -12 或者 Ctrl+C則回調handle接口，代碼示例如下：
1 Signal.handle(sig, shutdownHandler);
其中shutdownHandler實現了SignalHandler接口的handle(Signal sgin)方法，代碼示例如下：
1 public class ShutdownHandler implements SignalHandler { 2 /** 3 * 處理信號 4 * 5 * @param signal 信號 6 */ 7 public void handle(Signal signal) { 8 } 9 }
第四步，在接收到信號回調的handle接口中，初始化JVM的ShutdownHook線程，並將其注冊到Runtime中，示例代碼如下：
1 private void registerShutdownHook() 2 { 3 Thread t = new Thread(new ShutdownHook(), "ShutdownHook-Thread"); 4 Runtime.getRuntime().addShutdownHook(t); 5 }
第五步，接收到進程退出信號后，在回調的handle接口中執行虛擬機的退出操作，示例代碼如下：
1 Runtime.getRuntime().exit(0);
JVM退出時，底層會自動檢測用戶是否注冊了ShutdownHook任務，如果有，則會自動執行注冊鈎子的Run方法，應用只需要在ShutdownHook中執行掃尾工作即可，示例代碼如下：
1 class ShutdownHook implements Runnable 2 { 3 @Override 4 public void run() { 5 System.out.println("ShutdownHook execute start..."); 6 try { 7 TimeUnit.SECONDS.sleep(10);//模擬應用進程退出前的處理操作 8 } catch (InterruptedException e) { 9 e.printStackTrace(); 10 } 11 System.out.println("ShutdownHook execute end..."); 12 } 13 }
通過以上的幾個步驟，我們可以輕松實現JVM的安全退出，另外，通常安全退出需要有超時控制機制，例如30S，如果到達超時時間仍然沒有完成退出，則由停機腳本直接調用kill -9強制退出。
使用關閉鈎子的注意事項
-
關閉鈎子本質上是一個線程（也稱為Hook線程），對於一個JVM中注冊的多個關閉鈎子它們將會並發執行，所以JVM並不保證它們的執行順序；由於是並發執行的，那么很可能因為代碼不當導致出現競態條件或死鎖等問題，為了避免該問題，強烈建議在一個鈎子中執行一系列操作。
-
Hook線程會延遲JVM的關閉時間，這就要求在編寫鈎子過程中必須要盡可能的減少Hook線程的執行時間，避免hook線程中出現耗時的計算、等待用戶I/O等等操作。
- 關閉鈎子執行過程中可能被強制打斷,比如在操作系統關機時，操作系統會等待進程停止，等待超時，進程仍未停止，操作系統會強制的殺死該進程，在這類情況下，關閉鈎子在執行過程中被強制中止。
- 在關閉鈎子中，不能執行注冊、移除鈎子的操作，JVM將關閉鈎子序列初始化完畢后，不允許再次添加或者移除已經存在的鈎子，否則JVM拋出 IllegalStateException。
- 不能在鈎子調用System.exit()，否則卡住JVM的關閉過程，但是可以調用Runtime.halt()。
- Hook線程中同樣會拋出異常，對於未捕捉的異常，線程的默認異常處理器處理該異常，不會影響其他hook線程以及JVM正常退出。
總結
為了保障應用重啟過程中異步操作的執行，避免強制退出JVM可能產生的各種問題，我們可以采用關閉鈎子、自定義信號的方式，主動的通知JVM退出，並在JVM關閉前，執行應用程序的一些掃尾工作，進一步保證應用程序可以安全的退出。