內(nèi)存泄漏分析

這個小型系列的第一個博客介紹了如何創(chuàng)建一個非常泄漏的示例應(yīng)用程序，以便我們可以研究解決服務(wù)器應(yīng)用程序上基于堆的問題的技術(shù)。 它展示了Producer-Consumer模式的一個大問題，即消費者代碼必須能夠至少與生產(chǎn)者一樣快（甚至不是更快）從隊列中刪除項目。 博客以我開始的示例代碼結(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è)強度代碼，又沒有簡單的監(jiān)視線程來監(jiān)視隊列大小，該怎么辦？或其他內(nèi)部零件？ 那你怎么辦呢？

他們是發(fā)現(xiàn)泄漏應(yīng)用程序問題所需的三個步驟：

轉(zhuǎn)儲泄漏的服務(wù)器堆。

使用堆轉(zhuǎn)儲生成報告。

分析報告。

您可以使用多種工具來創(chuàng)建堆轉(zhuǎn)儲文件。 這些包括：

控制臺

可視化

eclipse內(nèi)存分析器工具（MAT）

使用jconsole進(jìn)行堆轉(zhuǎn)儲

將jconsole連接到您的應(yīng)用程序。 單擊MBeans選項卡，然后打開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)程計算機的/tmp目錄中（假設(shè)它是Unix機器）。 您將必須將該文件通過FTP傳輸?shù)侥挠嬎銠C上以進(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，并且不會破壞您計算機的其余部分和默認(rèn)的1.7版本。

使用MAT時，只需單擊“獲取堆轉(zhuǎn)儲”并按照說明進(jìn)行操作即可。

遠(yuǎn)程連接

這里要注意的是，如果您想弄清楚生產(chǎn)服務(wù)器倒塌的原因，那么您可能必須使用JMX進(jìn)行遠(yuǎn)程連接，為此，您需要以下命令行選項，我從我以前的博客重復(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)儲

這需要一點思考和一點運氣。 如果過早獲得堆轉(zhuǎn)儲，那么您將看不到問題，因為它們被合法的，非泄漏的類實例掩蓋了； 但是，不要等待太久，因為進(jìn)行堆轉(zhuǎn)儲需要內(nèi)存，因此進(jìn)行堆轉(zhuǎn)儲的行為可能會導(dǎo)致應(yīng)用程序崩潰。

最好的主意是將jconsole附加到您的應(yīng)用程序并監(jiān)視其堆，直到看起來即將崩潰為止。 這很容易發(fā)現(xiàn)，因為三個堆部分的指示器都是綠色的：

分析堆轉(zhuǎn)儲

這就是MAT自身的用途，因為它旨在分析??堆轉(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)實情況中，您確實會得到可疑的泄漏餅圖，這是事實。

接下來要做的是更深入地挖掘……

該報告的下一部分（如上所示）告訴我們，有一個LinkedBlockingQueue正在使用98.46％的內(nèi)存。 要對此進(jìn)行進(jìn)一步調(diào)查，請單擊Details>> 。

這表明問題確實出在我們的orderQueue ，可通過我以前的博客中的三個對象訪問： OrderFeed ， OrderRecord和OrderMonitor并且正如我們從代碼中知道的那樣，其中包含一堆Order對象。

就是這樣了; MAT告訴我們，該示例代碼具有一個LinkedBlockingQueue ，它用盡了所有示例應(yīng)用程序的堆空間，從而導(dǎo)致了巨大的問題。 它并沒有告訴我們?yōu)槭裁磿@樣，您真的不能期望它會發(fā)生。 就像阿加莎·克里斯蒂 （ Agatha Christie ）的赫爾克里·波洛 （ Hercule Poirot）所說的那樣，要使用“ ze little grey cell”……

參考： 調(diào)查內(nèi)存泄漏第2部分–在Captain Debug的Blog博客上分析我們的JCG合作伙伴 Roger Hughes 的問題 。

翻譯自: https://www.javacodegeeks.com/2013/12/investigating-memory-leaks-part-2-analysing-the-problem.html

內(nèi)存泄漏分析

總結(jié)

以上是生活随笔為你收集整理的内存泄漏分析_调查内存泄漏第2部分–分析问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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