[[394549]]

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

負(fù)責(zé)的消息中臺(tái)在 晚上八點(diǎn)左右，運(yùn)維群里反饋大量用戶接收不到短信消息。登陸 Kibana 查找對(duì)應(yīng)的 Error 日志，發(fā)現(xiàn)出現(xiàn)了 大量的下標(biāo)越界異常

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

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

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

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

另外一種，就比較詭異，只有異常，沒有對(duì)應(yīng)的堆棧信息

java.lang.ArrayIndexOutOfBoundsException: null 

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

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

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

JVM Fast Throw

什么是 Fast Throw?

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

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

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)化方案的原因是 為了提高性能。當(dāng)同一種異常在相同的位置被拋出多次，編譯器就會(huì)重新編譯此方法。重編譯后，編譯器可能會(huì) 使用不提供堆棧跟蹤的預(yù)分配異常 來選擇更快的策略

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

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

模擬 Fast Throw

上面說的都是理論部分，這個(gè)章節(jié)使用代碼來實(shí)戰(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("報(bào)錯(cuò)異常 :: %s, 堆棧長(zhǎng)度 :: %s", ex, length)); 
    } 
} 

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

如果沒有特別情況，最好不要關(guān)閉此特性。因?yàn)槿绻l(fā)量大的接口，因?yàn)槌绦虻?BUG 導(dǎo)致大量的請(qǐng)求在同一代碼處拋出異常，F(xiàn)ast Throw 機(jī)制可以節(jié)省很多性能損耗。通過單線程跑測(cè)試 Demo 得知，異常調(diào)用情況越多，性能差別越大

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

結(jié)言

千言萬語匯成一句話就是，重構(gòu)有風(fēng)險(xiǎn)，上線需謹(jǐn)慎

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

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

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