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