[[394549]]

首先，這是一個 悲傷的故事，涉及到JVM 底層優(yōu)化的知識點。想到第一次碰到這種問題時的懵逼，應了句老話：書到用時方恨少!

負責的消息中臺在 晚上八點左右，運維群里反饋大量用戶接收不到短信消息。登陸 Kibana 查找對應的 Error 日志，發(fā)現(xiàn)出現(xiàn)了 大量的下標越界異常

當時更...，線上問題得到了修復。但是，出現(xiàn)問題可不得找到問題的產(chǎn)出原因，不然下次有可能還會出現(xiàn)

因為在 ELK 上進行 日志分析不太方便，難以根據(jù)對應異常進行不同緯度上的統(tǒng)計分析，所以聯(lián)系運維同學將故障產(chǎn)生當天的 Info、Error 日志 拉下來進行線下分析

經(jīng)過日志分析得知，異常的產(chǎn)出有兩種，一種是有堆棧信息，比如：

java.lang.ArrayIndexOutOfBoundsException: -1 
... 省略堆棧信息 

另外一種，就比較詭異，只有異常，沒有對應的堆棧信息

java.lang.ArrayIndexOutOfBoundsException: null 

第一種問題比較好定位，根據(jù) 異常堆棧信息，定位到了具體代碼，直接進行了修復，難就難在第二種

其實這兩個是一個異常，往后看小伙伴就明白了。后面做的所有事情，都是為了搞清楚兩件事情

• 為什么異常 message 會輸出 null
• 為什么堆棧信息沒有輸出打印

JVM Fast Throw

什么是 Fast Throw?

大白話一點來說，就是：當一些異常類型(空指針、下標越界、算術(shù)運算等...)在代碼里的固定位置被拋出多次，虛擬機(HotSpot VM)會直接 拋出一個事先分配好、類型匹配的異常對象。此異常對象的 message 和 stack trace 都為空

看到這里相信讀者朋友已經(jīng)明白了為什么同一種異常，打印出來的日志卻是不一樣內(nèi)容 了吧。就是因為某一個異常在同一個地方多次被拋出，JVM 拋出一個預分配異常，那么 message、stack trace 相當于被吞掉了

The compiler in the server VM now provides correct stack backtraces for all "cold" built-in exceptions. For performance purposes, when such an exception is thrown a few times, the method may be recompiled. After recompilation, the compiler may choose a faster tactic using preallocated exceptions that do not provide a stack trace. To disable completely the use of preallocated exceptions, use this new flag: -XX:-OmitStackTraceInFastThrow.

JDK 1.5 的發(fā)布文檔介紹中描述了此情況，出現(xiàn)這種優(yōu)化方案的原因是 為了提高性能。當同一種異常在相同的位置被拋出多次，編譯器就會重新編譯此方法。重編譯后，編譯器可能會 使用不提供堆棧跟蹤的預分配異常 來選擇更快的策略

如果想要關(guān)閉這種預分配異常的機制，可以使用 -XX:-OmitStackTraceInFastThrow。感興趣的讀者朋友可以看一下發(fā)布說明：https://sourl.cn/PMzVkC

另外通過 JVM 的源碼得知，F(xiàn)ast Throw 機制目前支持五種異常情況，截圖如下

模擬 Fast Throw

上面說的都是理論部分，這個章節(jié)使用代碼來實戰(zhàn)下

List<String> list = new ArrayList(); 
for (int j = 0; j < 10000; j++) { 
    try { 
        list.get(-1); 
    } catch (Exception ex) { 
        int length = ex.getStackTrace().length; 
        System.out.println(String.format("報錯異常 :: %s, 堆棧長度 :: %s", ex, length)); 
    } 
} 

上面程序跑在了 Java8 的環(huán)境中，通過運行程序結(jié)果可以看出來，F(xiàn)ast Throw 在 Java 8 中依然生效

如果沒有特別情況，最好不要關(guān)閉此特性。因為如果并發(fā)量大的接口，因為程序的 BUG 導致大量的請求在同一代碼處拋出異常，F(xiàn)ast Throw 機制可以節(jié)省很多性能損耗。通過單線程跑測試 Demo 得知，異常調(diào)用情況越多，性能差別越大

如果線上環(huán)境觸發(fā)了 Fast Throw 機制，可以通過 向前追溯相同位置、相同異常的日志 來定位問題的產(chǎn)出原因

結(jié)言

千言萬語匯成一句話就是，重構(gòu)有風險，上線需謹慎

針對公共功能的重構(gòu)，需要包含全量的測試用例，要將問題的產(chǎn)出背景考慮到 極致，亦或者和身邊同事說明需求背景，大家一起想下，可以極大程度避免極端問題的產(chǎn)出

必要的壓力測試 是很重要的，這一點可以很好的將 流量大才能顯現(xiàn)的問題 提前暴露出來

故障的產(chǎn)生帶來的意義，有好有壞，壞的點大家都懂得;好的點自然是 積累了線上問題故障排查的經(jīng)驗，這樣的話，后面公司妹子再遇到相同的問題，大喊一聲：妹子，放開那 BUG，讓我來!