文章字數 1.3k 左右，閱讀時長 5 分鐘
首先，這是一個 悲傷的故事，涉及到JVM 底層優化的知識點。想到第一次碰到這種問題時的懵逼，應了句老話：書到用時方恨少！
負責的消息中臺在 晚上八點左右，運維羣裏反饋大量用戶接收不到短信消息。登陸 Kibana 查找對應的 Error 日誌，發現出現了 大量的下標越界異常
當時更...，線上問題得到了修復。但是，出現問題可不得找到問題的產出原因，不然下次有可能還會出現
因爲在 ELK 上進行 日誌分析不太方便，難以根據對應異常進行不同緯度上的統計分析，所以聯繫運維同學將故障產生當天的 Info、Error 日誌 拉下來進行線下分析
經過日誌分析得知，異常的產出有兩種，一種是有堆棧信息，比如：
java.lang.ArrayIndexOutOfBoundsException: -1
... 省略堆棧信息
另外一種，就比較詭異，只有異常，沒有對應的堆棧信息
java.lang.ArrayIndexOutOfBoundsException: null
第一種問題比較好定位，根據 異常堆棧信息，定位到了具體代碼，直接進行了修復，難就難在第二種
其實這兩個是一個異常，往後看小夥伴就明白了。後面做的所有事情，都是爲了搞清楚兩件事情
- 爲什麼異常 message 會輸出 null
- 爲什麼堆棧信息沒有輸出打印
JVM Fast Throw
什麼是 Fast Throw？
大白話一點來說，就是：當一些異常類型（空指針、下標越界、算術運算等...）在代碼裏的固定位置被拋出多次，虛擬機（HotSpot VM）會直接 拋出一個事先分配好、類型匹配的異常對象。此異常對象的 message 和 stack trace 都爲空
看到這裏相信讀者朋友已經明白了爲什麼同一種異常，打印出來的日誌卻是不一樣內容 了吧。就是因爲某一個異常在同一個地方多次被拋出，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 的發佈文檔介紹中描述了此情況，出現這種優化方案的原因是 爲了提高性能。當同一種異常在相同的位置被拋出多次，編譯器就會重新編譯此方法。重編譯後，編譯器可能會 使用不提供堆棧跟蹤的預分配異常 來選擇更快的策略
如果想要關閉這種預分配異常的機制，可以使用 -XX:-OmitStackTraceInFastThrow。感興趣的讀者朋友可以看一下發布說明：https://sourl.cn/PMzVkC
另外通過 JVM 的源碼得知，Fast Throw 機制目前支持五種異常情況，截圖如下
模擬 Fast Throw
上面說的都是理論部分，這個章節使用代碼來實戰下
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 的環境中，通過運行程序結果可以看出來，Fast Throw 在 Java 8 中依然生效
如果沒有特別情況，最好不要關閉此特性。因爲如果併發量大的接口，因爲程序的 BUG 導致大量的請求在同一代碼處拋出異常，Fast Throw 機制可以節省很多性能損耗。通過單線程跑測試 Demo 得知，異常調用情況越多，性能差別越大
| 開啓 Fast Throw | 關閉 Fast Throw | |
|---|---|---|
| 10w | 1004ms | 3547ms |
| 100 w | 6193ms | 30928ms |
| 500w | 37492ms | ... |
如果線上環境觸發了 Fast Throw 機制，可以通過 向前追溯相同位置、相同異常的日誌 來定位問題的產出原因
結言
千言萬語匯成一句話就是，重構有風險，上線需謹慎
針對公共功能的重構，需要包含全量的測試用例，要將可能會出現的問題產出背景考慮到 極致，亦或者和身邊同事說明需求背景，大家一起想下，可以極大程度避免極端問題的產出
必要的壓力測試 是很重要的，這一點可以很好的將 流量大才能顯現的問題 提前暴露出來
故障的產生帶來的意義，有好有壞，壞的點大家都懂得；好的點自然是 積累了線上問題故障排查的經驗，這樣的話，後面公司妹子再遇到相同的問題，大喊一聲：妹子，放開那 BUG，讓我來！