堆棧跟蹤 堆棧跟蹤

我們最近在博客中發(fā)表的一篇評(píng)論帶回了有關(guān)特定體驗(yàn)的一些回憶。 我希望我沒有經(jīng)歷過的那種經(jīng)歷。 在創(chuàng)建Plumbr之前很長一段時(shí)間，我正在調(diào)試一個(gè)應(yīng)用程序，該應(yīng)用程序每次在藍(lán)月亮?xí)r都會(huì)給我一個(gè)例外。 詳細(xì)程度令人震驚：

java.lang.NullPointerException

就是這樣–沒有可使用的stacktrace。 而且該應(yīng)用程序由一個(gè)真正邪惡的系統(tǒng)管理員保護(hù)著，他不允許我在部署后100碼之內(nèi)。 因此，為所有通宵人員準(zhǔn)備了一個(gè)階段，他們?cè)噲D了解導(dǎo)致錯(cuò)誤的原因。 我敢打賭，大多數(shù)讀者都知道我在這里說什么。 第一個(gè)嫌疑犯是顯而易見的。 暑期實(shí)習(xí)生從未真正獲得過異常處理，并且可以輕松地吞下異常，而無需重新拋出或正確記錄日志。 所以我期望在代碼中的某處找到這樣的東西：

System.out.println(e);

但是，無論我對(duì)源代碼進(jìn)行多徹底的檢查 ，都找不到類似這種粗心大意的東西。 從第二天起，除了每隔幾個(gè)小時(shí)接一個(gè)電話并提供“進(jìn)度報(bào)告”，我就沒有多少回憶。 不幸的是，進(jìn)展遙遙無期。 除非我想盡一切努力對(duì)生產(chǎn)進(jìn)行大量更新，以使他們對(duì)可能的原因有一些更有意義的嘗試。 但是，我確實(shí)記得我開始懷疑自己一直認(rèn)為不可能的事情時(shí)對(duì)測試Java的信念。 也就是說，Java能夠從字面上吞噬您的Exception堆棧跟蹤。 實(shí)際上，JIT可以并且將會(huì)做到。 需要證明嗎？ 運(yùn)行以下代碼：

for (int i = 0; i < 100_000; i++) {try {args[0].toString();} catch (Exception e) {if (e.getStackTrace().length == 0) {System.out.format("Java ate my stacktrace after iteration #%d %n", i);break;}} }

在配備了最新穩(wěn)定JDK 7熱點(diǎn)的MB Pro中，異常堆棧跟蹤在＃12,288迭代中被吞噬。 但是為什么在地球上會(huì)發(fā)生這種情況，又如何避免呢？ 簡單的答案是它是運(yùn)行時(shí)期間應(yīng)用的JIT優(yōu)化之一。 正如我們最近發(fā)表的一篇文章所描述的，創(chuàng)建Exceptions 非常昂貴 。 因此，出于性能目的，當(dāng)JIT發(fā)現(xiàn)多次拋出異常時(shí)，可以重新編譯代碼。 重新編譯后，編譯器可以使用不提供堆棧跟蹤的預(yù)分配異常來選擇更快的策略。 希望你們中的絕大多數(shù)將永遠(yuǎn)不必處理這種情況。 畢竟，當(dāng)以觸發(fā)JIT切換到預(yù)分配的異常的速度創(chuàng)建異常時(shí)，您肯定在做其他錯(cuò)誤。 畢竟，僅在例外情況下才應(yīng)發(fā)生例外。 但是對(duì)于那些這樣做的人，解決方案很簡單。 您可以通過將-XX：-OmitStackTraceInFastThrow添加到JVM啟動(dòng)參數(shù)來禁用預(yù)分配的異常。 在下一次JVM重新啟動(dòng)后，我也找到了罪魁禍?zhǔn)住?

參考： Plumbr Blog博客上的JCG合作伙伴 Nikita Salnikov Tarnovski 尋求丟失 堆棧跟蹤的信息 。

翻譯自: https://www.javacodegeeks.com/2013/09/on-a-quest-for-missing-stacktraces.html

堆棧跟蹤 堆棧跟蹤

總結(jié)

以上是生活随笔為你收集整理的堆栈跟踪 堆栈跟踪_寻找缺少的堆栈跟踪的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。