當應用程序崩潰時，您可以學到什么？

我認為，“后見之明是20 /”是最喜歡的短語之一托馬斯·羅梅爾 ，工程ZeroTurnaround的副總裁。 好吧，我實際上不確定在他的短語中占什么位置，但是我已經聽過他幾次說了。 鑒于這意味著回顧過去，您可以對事情進行推理比預測將來發生的事情要好得多，通常發生在我們未能正確預測事情并反映行動結果的情況下。 如果您經常聽到此短語，則意味著您經常對事情進行反思，并且您知道每一次失敗，每一次錯誤都會提供一個教訓。

好吧，可能是您沒有犯錯誤，或者您沒有犯任何會傳播到最終產品以及最終用戶的重要錯誤。 我確實偶爾制作它們，不止一次，我對服務器進行了多次轟炸，并且無數次提交了損壞的代碼。 有時它也會滑入最終產品。 每當我寫的破損代碼再次咬我時，我都會學到一些東西。 每次我必須調查造成錯誤的原因是什么，將其復制到我的機器上并進行修復。

在這篇文章中，我想看看可以幫助您獲得有關錯誤的相關信息并幫助您重現和修復它們的工具和技術。

新帖：JVM崩潰時：如何調查最嚴重錯誤的根本原因http://t.co/bvHVYhT2m4 pic.twitter.com/dKhgiKMhT5

— Takipi（@takipid） 2015年4月27日

結構化日志

弄清楚某些代碼中發生了什么的默認goto方法是閱讀源代碼。 當該來源實際上是您每天工作8-10個小時而仍然找不到罪魁禍首時，則您必須在錯誤發生時添加一些有關上下文的情境意識。 自然地，您可以從日志中獲取該上下文。 我毫不懷疑您一直在使用日志，但這是您可以做的一個很好的技巧，可以使日志更加有用。

線程名稱

如果配置線程名稱以反映應用程序中發生的事情，則可以獲得有關上下文的更多信息。 線程名稱幾乎總是包含在日志中，并且打印線程名稱不會帶來任何明顯的性能開銷。 例如，找出記錄器的調用方類需要花費時間，因為您必須構造和遍歷堆棧跟蹤。 但是訪問線程名稱既快速又便宜。 另外，線程名很少用于其他任何事情，因此，在您認為合適的地方充填盡可能多的信息：系統組件名稱，事務ID，發出請求的用戶名等。稍后在調試問題時，您將感謝這些詳細的日志，輕輕松松。

更多日志類型

另一個技巧是使JVM產生更多的日志，可以使JVM產生可以稍后分析的垃圾收集日志，JIT編譯日志和堆轉儲。 由于性能開銷，其中大多數可能不適合生產系統，但是您絕對可以在暫存階段或在自己的開發站上對它們進行試驗。

稍后，您可以調整垃圾回收的性能，并進行大量優化， 如本文所述 ，但首先，您可以使用以下JVM選項啟用垃圾回收日志： -XX：+ PrintGC -XX：+ PrintGCDetails -XX：+ PrintGCTimeStamps和-XX：+ PrintGCDateStamps -Xloggc：file 。

手動調查JIT編譯日志可能不會告訴您太多信息，但是您始終可以嘗試使用JITWatch來查看JVM編譯代碼時發生了什么。

對于生產系統來說，打開它的一個好主意是： -XX：+ HeapDumpOnOutOfMemoryError ，這將使JVM在發生OutOfMemory錯誤時創建內存轉儲。

日志種類繁多，并非對崩潰管理都同樣有用，但是它們都是必不可少的，也是您軍械庫中最容易使用的工具。

現代開發人員工具

等一下 您是否要告訴我，在21世紀，沒有什么比找出日志并從早期石器時代采用取證技術更好的方法來弄清您的應用程序中發生了什么？ 好吧，不是真的。 但是我不知道有什么通用工具可以為您提供最佳的見解，以了解代碼中發生了什么以及為什么發生這種情況。

在開發環境中，情況變得更容易，您擁有大量的備用計算資源，并且可能會冒險附加不需要經過Ops批準流程的各種工具。

例如， 以Plumbr的IvoM?gi的帖子為例 ，他討論了他們的內存泄漏檢測工具是否適合操作人員或開發人員。 理想情況下，該工具是有用且穩定的，因此您既可以在開發過程中享受其性能和功能，又不必擔心將其附加到實時系統中。 但是這種情況很少發生，您不需要在生產環境中進行調試，也不想與JRebel即時交換類，等等。

但是，這并不意味著您根本不應該使用任何現代工具，而應該將自己限制在老式的，但已被證實的發現邪惡根源的方法上：日志。 毫無疑問，日志仍將是您將獲得的最有用的取證信息來源，但是您可以做得更好。

通常，開發過程包括大量盯著代碼，思考并有時在此處和此處更改功能位。 這是一項艱苦的工作，需要集中精力解決問題和系統邏輯。 如果您知道使事情變得更輕松的方法論或一些神奇的秘訣，請在Twitter上與我分享智慧： @shelajev 。 在此之前，我們將以軟件工程需要集中精力為前提。 這意味著任何工具都有兩個主要的非功能性要求：在功能上必須強大，并且必須具有非侵入性，因此您不必在如何實現所需的功能上費心。

重現某些條件的最有效方法是對其進行測試。 當它不可用時，下一個最好的事情就是使用一個錄制調試器，例如Takipi進行生產調試或Chronon 。

使用Chronon，您可以記錄代碼中發生的操作，它們產生的結果，每給定時刻堆棧中的內容以及產生程序執行的事務日志的記錄。 稍后，您可以將此日志提供給另一個程序運行，并來回逐步執行。

如果您要查明性能問題，則可以使用Java Mission Control的 Java Flight Recorder收集有關程序執行配置文件，垃圾收集統計數據，堆使用情況數據（例如對象分配，鎖和IO詳細信息）的信息。如果要運行附加到生產節點上的Java Mission Control，您必須支付許可證的費用，但是對于開發環境，則沒有這樣的問題。

再說一次，如果要監視生產環境，則可能需要一個錯誤管理解決方案，該解決方案專門為獲取盡可能多的錯誤信息而創建。

Takipi的儀表板和本機代理使您無需使用日志文件即可調試生產中的代碼。 您將獲得錯誤分析，分布式系統中的統一堆棧跟蹤以及其他可以大大減少理解和修復錯誤的時間的事物。

在這篇文章中，我們研究了幾種工具和技術，可以使您在積極開發應用程序或將其部署到生產環境中時更加了解應用程序中正在發生的事情。 無論是通過熟練地將JMC與飛行記錄器配合使用，還是通過優雅制作的日志，重現錯誤都是糾正任何錯誤的最重要步驟。

您要記住的是，盡管每次都會使用好的舊工具，但幾乎每個領域都有新的發展，并且崩潰管理和錯誤監視也不例外。 了解其中有哪些工具，并了解如何正確使用它們。 它將使您成為更好的開發人員。

翻譯自: https://www.javacodegeeks.com/2015/04/when-jvms-crash-how-to-investigate-the-root-cause-of-your-toughest-errors.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的JVM崩溃时：如何调查最严重错误的根本原因的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。