调查内存泄漏第2部分–分析问题
這個小型系列的第一個博客介紹了如何創(chuàng)建一個非常泄漏的示例應(yīng)用程序，以便我們可以研究解決服務(wù)器應(yīng)用程序上基于堆的問題的技術(shù)。 它展示了Producer-Consumer模式的一個大問題，即消費(fèi)者代碼必須能夠至少與生產(chǎn)者一樣快（如果不是更快）從隊列中刪除項(xiàng)目。 博客的結(jié)尾是我開始示例代碼，然后坐下來，同時它泄漏了足夠的內(nèi)存以進(jìn)行調(diào)查。 現(xiàn)在該進(jìn)行調(diào)查了。
如果您閱讀本博客的第1部分 ，您將知道泄漏代碼是應(yīng)用程序1的一部分，該應(yīng)用程序使用Producer Consumer模式在虛擬數(shù)據(jù)庫中記錄了股票/股票定單。 編寫的示例代碼包含一個非常明顯的缺陷，即OrderRecord無法跟上OrderFeed 。 這意味著Order隊列會越來越大，直到最后，應(yīng)用程序用完堆空間并崩潰為止。 問題是，看我的簡單代碼，問題應(yīng)該很明顯，但是如果您以前從未看過代碼，并且它是巨大的，復(fù)雜的工業(yè)強(qiáng)度代碼，又沒有簡單的監(jiān)視線程來監(jiān)視隊列大小，該怎么辦？或其他內(nèi)部零件？ 那你怎么辦呢？
他們是發(fā)現(xiàn)泄漏應(yīng)用程序問題所需的三個步驟：
您可以使用多種工具來創(chuàng)建堆轉(zhuǎn)儲文件。 這些包括：
使用jconsole進(jìn)行堆轉(zhuǎn)儲
將jconsole連接到您的應(yīng)用程序。 單擊MBeans選項(xiàng)卡，然后打開com.sun.management包。 然后，單擊HotSpotDiagnostic 。 打開“ Operations然后選擇dumpHeap 。 現(xiàn)在，您將看到dumpHeap操作，該操作dumpHeap兩個參數(shù)p0和p1 。 在p0編輯框中鍵入堆轉(zhuǎn)儲的文件名，然后按dumpHeap按鈕。
使用jvisualvm進(jìn)行堆轉(zhuǎn)儲
連接到示例代碼后，在左側(cè)“應(yīng)用程序”窗格中右鍵單擊您的應(yīng)用程序，然后選擇“堆轉(zhuǎn)儲”。
請注意，如果您與泄漏的服務(wù)器建立了遠(yuǎn)程連接，則jvisualvm將轉(zhuǎn)儲文件存儲在遠(yuǎn)程計算機(jī)的/tmp目錄中（假設(shè)它是Unix機(jī)器）。 您將必須將該文件通過FTP傳輸?shù)接嬎銠C(jī)上，以進(jìn)行進(jìn)一步分析。
使用MAT進(jìn)行堆轉(zhuǎn)儲
盡管jconsole和jvisualvm是JDK，MAT或內(nèi)存分析器工具的一部分，但它是基于eclipse的工具，您可以從eclipse org下載
當(dāng)前版本的MAT需要在您的PC上安裝1.6 jdk。 如果您使用的是Java 1.7，請放心，它將為您安裝1.6，并且不會破壞您計算機(jī)的其余部分和默認(rèn)的1.7版本。
使用MAT時，只需單擊“獲取堆轉(zhuǎn)儲”并按照說明進(jìn)行操作即可。
遠(yuǎn)程連接
這里要注意的是，如果您想弄清楚生產(chǎn)服務(wù)器為何倒塌，那么您可能必須使用JMX進(jìn)行遠(yuǎn)程連接，為此，您需要以下命令行選項(xiàng)，我從我以前的博客重復(fù)過：
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false何時進(jìn)行堆轉(zhuǎn)儲
這需要一些思想和運(yùn)氣。 如果過早獲得堆轉(zhuǎn)儲，那么您將看不到問題，因?yàn)樗鼈儽缓戏ǖ?#xff0c;非泄漏的類實(shí)例掩蓋了； 但是，不要等待太久，因?yàn)檫M(jìn)行堆轉(zhuǎn)儲需要內(nèi)存，因此進(jìn)行堆轉(zhuǎn)儲的行為可能會導(dǎo)致您的應(yīng)用程序崩潰。
最好的主意是將jconsole附加到您的應(yīng)用程序并監(jiān)視其堆，直到看起來即將崩潰為止。 這很容易發(fā)現(xiàn)，因?yàn)槿齻€堆區(qū)指示器都是綠色的：
分析堆轉(zhuǎn)儲
這就是MAT自身的用途，因?yàn)樗荚诜治??堆轉(zhuǎn)儲。 要打開并分析堆轉(zhuǎn)儲，請選擇“ File | Open Heap Dump File | Open Heap Dump 。 選擇堆轉(zhuǎn)儲文件后，現(xiàn)在將為您提供三個選擇，如下所示：
選擇： 泄漏可疑報告 。 現(xiàn)在，MAT將流失幾秒鐘，然后生成如下所示的頁面：
餅圖表明，在這種情況下，存在一個主要的泄漏嫌疑人。 您可能會認(rèn)為這是一個修復(fù)程序，畢竟這是示例代碼，您期望什么？ 好吧，是的，在這種情況下，它很明顯。 懷疑“ a”占用98.7MB，而內(nèi)存中的其余對象使用其他1.5MB。 在現(xiàn)實(shí)情況下，您確實(shí)會得到可疑的泄漏餅圖。
接下來要做的是更深入地挖掘……
該報告的下一部分（如上所示）告訴我們，有一個LinkedBlockingQueue正在使用98.46％的內(nèi)存。 要對此進(jìn)行進(jìn)一步調(diào)查，請單擊Details>> 。
這表明問題確實(shí)出在我們的orderQueue ，可通過我以前的博客中的三個對象訪問： OrderFeed ， OrderRecord和OrderMonitor并且正如我們從代碼中知道的那樣，它包含一堆Order對象。
就是這樣了; MAT告訴我們，該示例代碼具有一個LinkedBlockingQueue ，它用盡了所有示例應(yīng)用程序的堆空間，從而導(dǎo)致了巨大的問題。 它并沒有告訴我們?yōu)槭裁磿@樣，您真的不能期望它會發(fā)生。 就像阿加莎·克里斯蒂 （ Agatha Christie ）的赫爾克里·波洛 （ Hercule Poirot）所說的那樣，使用“ ze little grey cell”……
翻譯自: https://www.javacodegeeks.com/2013/12/investigating-memory-leaks-part-2-analysing-the-problem.html
總結(jié)
以上是生活随笔為你收集整理的调查内存泄漏第2部分–分析问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 项目学生：Spring数据的持久性
- 下一篇： 调查内存泄漏第1部分–编写泄漏代码