當(dāng)應(yīng)用程序崩潰時，您可以學(xué)到什么？

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

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

在這篇文章中，我想看看可以幫助您獲得有關(guān)錯誤的相關(guān)信息并幫助您重現(xiàn)和修復(fù)它們的工具和技術(shù)。

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

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

結(jié)構(gòu)化日志

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

線程名稱

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

更多日志類型

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

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

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

對于生產(chǎn)系統(tǒng)來說，打開它的一個好主意是： -XX：+ HeapDumpOnOutOfMemoryError ，這將使JVM在發(fā)生OutOfMemory錯誤時創(chuàng)建內(nèi)存轉(zhuǎn)儲。

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

現(xiàn)代開發(fā)人員工具

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

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

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

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

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

重現(xiàn)某些條件的最有效方法是對其進行測試。 當(dāng)它不可用時，下一個最好的事情就是使用一個錄制調(diào)試器，例如Takipi進行生產(chǎn)調(diào)試或Chronon 。

使用Chronon，您可以記錄代碼中發(fā)生的操作，它們產(chǎn)生的結(jié)果，每給定時刻堆棧中的內(nèi)容以及產(chǎn)生程序執(zhí)行的事務(wù)日志的記錄。 稍后，您可以將此日志提供給另一個程序運行，并來回逐步執(zhí)行。

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

再說一次，如果要監(jiān)視生產(chǎn)環(huán)境，則可能需要一個錯誤管理解決方案，該解決方案專門為獲取盡可能多的錯誤信息而創(chuàng)建。

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

在這篇文章中，我們研究了幾種工具和技術(shù)，可以使您在積極開發(fā)應(yīng)用程序或?qū)⑵洳渴鸬缴a(chǎn)環(huán)境中時更加了解應(yīng)用程序中正在發(fā)生的事情。 無論是通過熟練地將JMC與飛行記錄器配合使用，還是通過優(yōu)雅制作的日志，重現(xiàn)錯誤都是糾正任何錯誤的最重要步驟。

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

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

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

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

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