我已經(jīng)對(duì)這個(gè)主題進(jìn)行了很多搜索。但沒(méi)有具體的解決方案/指南。從文檔中，在某些情況下，某些虛擬機(jī)可能會(huì)從堆棧跟蹤中省略一個(gè)或多個(gè)堆棧幀。在極端情況下，沒(méi)有與此 throwable 相關(guān)的堆棧跟蹤信息的虛擬機(jī)可以從此方法返回零長(zhǎng)度數(shù)組。有人可以闡明這可能/將會(huì)發(fā)生的條件嗎？我知道如果一遍又一遍地生成相同的堆棧跟蹤，就會(huì)發(fā)生這種情況（計(jì)數(shù)上沒(méi)有硬性規(guī)則，據(jù)我所知-否則請(qǐng)糾正我）。但這難道不應(yīng)該有一個(gè)明確的行為嗎？另外，根據(jù)這一點(diǎn)，通過(guò)-XX:-OmitStackTraceInFastThrow將確保我的StackTrace不會(huì)丟失。在生產(chǎn)機(jī)器中這樣做不是明智之舉嗎？
1 回答
千巷貓影
TA貢獻(xiàn)1829條經(jīng)驗(yàn) 獲得超7個(gè)贊
OmitStackTraceInFastThrow是C2 編譯代碼中的優(yōu)化，可拋出某些隱式異常，而無(wú)需堆棧跟蹤。該優(yōu)化僅適用于隱式異常，即 JVM 本身引發(fā)的異常，而不是用戶(hù)代碼引發(fā)的異常。這些隱式異常是：
空指針異常
算術(shù)異常
ArrayIndexOutOfBoundsException
數(shù)組存儲(chǔ)異常
類(lèi)轉(zhuǎn)換異常
僅當(dāng) JVM 知道該特定位置較早發(fā)生異常時(shí)，才會(huì)忽略堆棧跟蹤。
因此，在 HotSpot JVM 中，如果滿足以下所有條件，則異常不會(huì)有堆棧跟蹤： 1）拋出方法是熱的，即由 C2 編譯的； 2）它是一個(gè)隱式異常，例如由 拋出的 NPE obj.method()，但不是由 拋出的throw new NullPointerException()； 3）至少第二次拋出異常。
優(yōu)化的目的是消除在快速路徑上重復(fù)拋出隱式異常時(shí)（可以說(shuō)很少見(jiàn)）情況對(duì)性能的影響。在我看來(lái)，這不是正常情況。異常，尤其是隱式異常，通常表示需要修復(fù)的錯(cuò)誤情況。從這個(gè)意義上說(shuō)，禁用 是可以的-XX:-OmitStackTraceInFastThrow。例如，在我們的生產(chǎn)環(huán)境中，我們總是禁用它，它節(jié)省了我們很多調(diào)試時(shí)間。不過(guò)，我承認(rèn)，如果存在這樣的優(yōu)化，那么在某些情況下它有助于解決性能問(wèn)題。
TL;DR添加-XX:-OmitStackTraceInFastThrow選項(xiàng)確實(shí)是一個(gè)好主意，除非應(yīng)用程序中的熱路徑上存在許多隱式異常。
添加回答
舉報(bào)
0/150
提交
取消