內存泄漏分析

這個小型系列的第一個博客介紹了如何創建一個非常泄漏的示例應用程序，以便我們可以研究解決服務器應用程序上基于堆的問題的技術。 它展示了Producer-Consumer模式的一個大問題，即消費者代碼必須能夠至少與生產者一樣快（甚至不是更快）從隊列中刪除項目。 博客以我開始的示例代碼結尾，然后坐了下來，同時它泄漏了足夠的內存以進行調查。 現在該進行調查了。

如果您閱讀本博客的第1部分 ，您將知道泄漏代碼是應用程序^1的一部分，該應用程序使用Producer Consumer模式在虛擬數據庫中記錄了股票/股票定單。 編寫示例代碼包含一個非常明顯的缺陷，即OrderRecord無法跟上OrderFeed 。 這意味著Order隊列變得越來越大，直到最后，應用程序用完了堆空間并崩潰為止。 問題是，看我的簡單代碼，問題應該很明顯，但是如果您以前從未看過代碼，并且它是巨大的，復雜的工業強度代碼，又沒有簡單的監視線程來監視隊列大小，該怎么辦？或其他內部零件？ 那你怎么辦呢？

他們是發現泄漏應用程序問題所需的三個步驟：

轉儲泄漏的服務器堆。

使用堆轉儲生成報告。

分析報告。

您可以使用多種工具來創建堆轉儲文件。 這些包括：

控制臺

可視化

eclipse內存分析器工具（MAT）

使用jconsole進行堆轉儲

將jconsole連接到您的應用程序。 單擊MBeans選項卡，然后打開com.sun.management包。 然后，單擊HotSpotDiagnostic 。 打開“ Operations然后選擇dumpHeap 。 現在，您將看到dumpHeap操作，該操作dumpHeap兩個參數p0和p1 。 在p0編輯框中鍵入堆轉儲的文件名，然后按dumpHeap按鈕。

使用jvisualvm進行堆轉儲

連接到示例代碼后，右鍵單擊左側“應用程序”窗格中的應用程序，然后選擇“堆轉儲”。

請注意，如果您與泄漏的服務器具有遠程連接，則jvisualvm將轉儲文件存儲在遠程計算機的/tmp目錄中（假設它是Unix機器）。 您將必須將該文件通過FTP傳輸到您的計算機上以進行進一步分析。

使用MAT進行堆轉儲

盡管jconsole和jvisualvm是JDK，MAT或內存分析器工具的一部分，但它是基于eclipse的工具，您可以從eclipse org下載

當前版本的MAT需要在您的PC上安裝1.6 jdk。 如果您使用的是Java 1.7，請放心，它將為您安裝1.6，并且不會破壞您計算機的其余部分和默認的1.7版本。

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

遠程連接

這里要注意的是，如果您想弄清楚生產服務器倒塌的原因，那么您可能必須使用JMX進行遠程連接，為此，您需要以下命令行選項，我從我以前的博客重復過：

-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

何時進行堆轉儲

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

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

分析堆轉儲

這就是MAT自身的用途，因為它旨在分析??堆轉儲。 要打開并分析堆轉儲，請選擇“ File | Open Heap Dump File | Open Heap Dump 。 選擇堆轉儲文件后，現在將為您提供三個選擇，如下所示：

選擇： 泄漏可疑報告 。 現在，MAT將流失幾秒鐘，然后生成如下所示的頁面：

餅圖表明，在這種情況下，存在一個主要的泄漏嫌疑人。 您可能會認為這是一個修復程序，畢竟這是示例代碼，您期望什么？ 好吧，是的，在這種情況下，它很明顯。 懷疑“ a”占用98.7MB，而內存中的其余對象使用其他1.5MB。 在現實情況中，您確實會得到可疑的泄漏餅圖，這是事實。

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

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

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

就是這樣了; MAT告訴我們，該示例代碼具有一個LinkedBlockingQueue ，它用盡了所有示例應用程序的堆空間，從而導致了巨大的問題。 它并沒有告訴我們為什么會這樣，您真的不能期望它會發生。 就像阿加莎·克里斯蒂 （ Agatha Christie ）的赫爾克里·波洛 （ Hercule Poirot）所說的那樣，要使用“ ze little grey cell”……

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

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

內存泄漏分析

總結

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

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