這篇文章是我們開放文化的一部分-我們繼續分享日常工作中的見解。 這次，我們窺視了我們價值主張的核心，即–尋找以下問題的答案：

• Java應用程序中多長時間發生一次內存泄漏？
• 內存泄漏有多大？
• 內存泄漏增長多快？

如果您接下來的幾分鐘與我在一起，我將根據過去六個月內Plumbr內存泄漏檢測器代理收集的數據，一個一個地打開答案。

首先，該分析基于與Plumbr代理一起運行的2,180種不同應用程序 。 “不同應用程序”的定義有些棘手，我為您省去了世俗的細節，但是我們盡力根據可用數據來標識唯一的JVM。

在這2180個應用程序中， Plumbr發現了754種不同的堆內存泄漏 。 由于某些應用程序包含多個內存泄漏，因此檢測到泄漏的唯一應用程序的數量要少一些-準確地說是682。 根據這些數據，我們可以得出結論： 31％的Java應用程序包含堆內存泄漏 。 對此一針見血–我們確實承認，Plumbr最終監視的應用程序比我們不監視的應用程序更可能包含內存泄漏。

現在，知道您的應用程序中有大約三分之一的機會發生堆內存泄漏，讓我們看看是否應該擔心泄漏。 為此，讓我們看一下這754個堆內存泄漏的兩個不同特征。

內存泄漏大小

當Plumbr發現內存泄漏時，它將運行復雜的計算以確定泄漏的保留大小。 或者，以更簡單的方式– Plumbr計算特定泄漏的大小（以兆字節為單位）。 下表顯示了該數據：

從數據中我們可以看到，Plumbr在嬰兒期就發現了許多泄漏-例如，它發現了187個泄漏（占總泄漏的25％），而在發現時泄漏仍小于1MB 。 在另一種極端情況下，檢測到一些泄漏需要更長的時間，因此在31種情況下，只有在泄漏到1GB之后才檢測到泄漏。 在發現之前，最大的泄漏已設法升級到3GB。

從上面得出的另一個有趣的結論是，大多數泄漏是在應用程序的最終用戶感受到任何影響之前被Plumbr捕獲的–在Plumbr報告泄漏為事件時，泄漏的70％仍小于100MB。

內存泄漏速度

現在，應用程序包含的泄漏不足100MB的事實已成為不可采取的措施。 將泄漏的大小與泄漏的速度耦合起來，事件的嚴重性變得更加清楚：

上圖的信息可以這樣解釋：對于6％（37次出現）的情況，發現時的泄漏速度在100到500 MB /小時之間。

在極端情況下，我們的泄漏速度非常慢或非常快。 在398次（發現泄漏的53％）中，泄漏以每小時1MB或更少的速度遞增。 在頻譜的另一端，我們以31GB /小時或更快的速度增加了31個泄漏 。 在這方面，“記錄保存者”每小時的泄漏量超過3GB。

結合速度信息與應用程序當前的泄漏大小和最大堆可用信息，您可以估計特定應用程序在崩潰前所剩下的時間，并導致OutOfMemoryError 。

上周五的一個特定示例：Plumbr報告了一次泄漏大小為120MB的事件。 泄漏速度為每天160MB。 將這些信息與當前的堆使用情況和可用的最大堆鏈接在一起，我們可以預測到特定的JVM將在星期二下午2點之前消失。 我們錯了六個小時，如果考慮到應用程序使用模式會隨著時間的推移而發生變化，這是預測游戲的一部分，那么預測就足夠接近了。

翻譯自: https://www.javacodegeeks.com/2014/09/memory-leaks-measuring-frequency-and-severity.html

總結

以上是生活随笔為你收集整理的内存泄漏–测量频率和严重性的全部內容，希望文章能夠幫你解決所遇到的問題。

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