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