新聞中心
線上問(wèn)題復(fù)盤(pán),JVM Fast Throw 的故事
作者:龍臺(tái) 2021-04-21 07:37:19
云計(jì)算
虛擬化 首先,這是一個(gè) 悲傷的故事,涉及到JVM 底層優(yōu)化的知識(shí)點(diǎn)。想到第一次碰到這種問(wèn)題時(shí)的懵逼,應(yīng)了句老話:書(shū)到用時(shí)方恨少!

創(chuàng)新互聯(lián)擁有10多年成都網(wǎng)站建設(shè)工作經(jīng)驗(yàn),為各大企業(yè)提供網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站制作服務(wù),對(duì)于網(wǎng)頁(yè)設(shè)計(jì)、PC網(wǎng)站建設(shè)(電腦版網(wǎng)站建設(shè))、App定制開(kāi)發(fā)、wap網(wǎng)站建設(shè)(手機(jī)版網(wǎng)站建設(shè))、程序開(kāi)發(fā)、網(wǎng)站優(yōu)化(SEO優(yōu)化)、微網(wǎng)站、申請(qǐng)域名等,憑借多年來(lái)在互聯(lián)網(wǎng)的打拼,我們?cè)诨ヂ?lián)網(wǎng)網(wǎng)站建設(shè)行業(yè)積累了很多網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、網(wǎng)絡(luò)營(yíng)銷經(jīng)驗(yàn),集策劃、開(kāi)發(fā)、設(shè)計(jì)、營(yíng)銷、管理等網(wǎng)站化運(yùn)作于一體,具備承接各種規(guī)模類型的網(wǎng)站建設(shè)項(xiàng)目的能力。
首先,這是一個(gè) 悲傷的故事,涉及到JVM 底層優(yōu)化的知識(shí)點(diǎn)。想到第一次碰到這種問(wèn)題時(shí)的懵逼,應(yīng)了句老話:書(shū)到用時(shí)方恨少!
負(fù)責(zé)的消息中臺(tái)在 晚上八點(diǎn)左右,運(yùn)維群里反饋大量用戶接收不到短信消息。登陸 Kibana 查找對(duì)應(yīng)的 Error 日志,發(fā)現(xiàn)出現(xiàn)了 大量的下標(biāo)越界異常
當(dāng)時(shí)更...,線上問(wèn)題得到了修復(fù)。但是,出現(xiàn)問(wèn)題可不得找到問(wè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 日志 拉下來(lái)進(jìn)行線下分析
經(jīng)過(guò)日志分析得知,異常的產(chǎn)出有兩種,一種是有堆棧信息,比如:
- java.lang.ArrayIndexOutOfBoundsException: -1
- ... 省略堆棧信息
另外一種,就比較詭異,只有異常,沒(méi)有對(duì)應(yīng)的堆棧信息
- java.lang.ArrayIndexOutOfBoundsException: null
第一種問(wèn)題比較好定位,根據(jù) 異常堆棧信息,定位到了具體代碼,直接進(jìn)行了修復(fù),難就難在第二種
其實(shí)這兩個(gè)是一個(gè)異常,往后看小伙伴就明白了。后面做的所有事情,都是為了搞清楚兩件事情
- 為什么異常 message 會(huì)輸出 null
- 為什么堆棧信息沒(méi)有輸出打印
JVM Fast Throw
什么是 Fast Throw?
大白話一點(diǎn)來(lái)說(shuō),就是:當(dāng)一些異常類型(空指針、下標(biāo)越界、算術(shù)運(yùn)算等...)在代碼里的固定位置被拋出多次,虛擬機(jī)(HotSpot VM)會(huì)直接 拋出一個(gè)事先分配好、類型匹配的異常對(duì)象。此異常對(duì)象的 message 和 stack trace 都為空
看到這里相信讀者朋友已經(jīng)明白了為什么同一種異常,打印出來(lái)的日志卻是不一樣內(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ù)分配異常 來(lái)選擇更快的策略
如果想要關(guān)閉這種預(yù)分配異常的機(jī)制,可以使用 -XX:-OmitStackTraceInFastThrow。感興趣的讀者朋友可以看一下發(fā)布說(shuō)明:https://sourl.cn/PMzVkC
另外通過(guò) JVM 的源碼得知,F(xiàn)ast Throw 機(jī)制目前支持五種異常情況,截圖如下
模擬 Fast Throw
上面說(shuō)的都是理論部分,這個(gè)章節(jié)使用代碼來(lái)實(shí)戰(zhàn)下
- List
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)境中,通過(guò)運(yùn)行程序結(jié)果可以看出來(lái),F(xiàn)ast Throw 在 Java 8 中依然生效
如果沒(méi)有特別情況,最好不要關(guān)閉此特性。因?yàn)槿绻l(fā)量大的接口,因?yàn)槌绦虻?BUG 導(dǎo)致大量的請(qǐng)求在同一代碼處拋出異常,F(xiàn)ast Throw 機(jī)制可以節(jié)省很多性能損耗。通過(guò)單線程跑測(cè)試 Demo 得知,異常調(diào)用情況越多,性能差別越大
| 開(kāi)啟 Fast Throw | 關(guān)閉 Fast Throw | |
|---|---|---|
| 10w | 1004ms | 3547ms |
| 100 w | 6193ms | 30928ms |
| 500w | 37492ms | ... |
如果線上環(huán)境觸發(fā)了 Fast Throw 機(jī)制,可以通過(guò) 向前追溯相同位置、相同異常的日志 來(lái)定位問(wèn)題的產(chǎn)出原因
結(jié)言
千言萬(wàn)語(yǔ)匯成一句話就是,重構(gòu)有風(fēng)險(xiǎn),上線需謹(jǐn)慎
針對(duì)公共功能的重構(gòu),需要包含全量的測(cè)試用例,要將問(wèn)題的產(chǎn)出背景考慮到 極致,亦或者和身邊同事說(shuō)明需求背景,大家一起想下,可以極大程度避免極端問(wèn)題的產(chǎn)出
必要的壓力測(cè)試 是很重要的,這一點(diǎn)可以很好的將 流量大才能顯現(xiàn)的問(wèn)題 提前暴露出來(lái)
故障的產(chǎn)生帶來(lái)的意義,有好有壞,壞的點(diǎn)大家都懂得;好的點(diǎn)自然是 積累了線上問(wèn)題故障排查的經(jīng)驗(yàn),這樣的話,后面公司妹子再遇到相同的問(wèn)題,大喊一聲:妹子,放開(kāi)那 BUG,讓我來(lái)!
文章題目:線上問(wèn)題復(fù)盤(pán),JVMFastThrow的故事
網(wǎng)站路徑:http://www.dlmjj.cn/article/coiiseo.html


咨詢
建站咨詢
