这篇文章是我们开放文化的一部分-我们继续分享日常工作中的见解。 这次，我们窥视了我们价值主张的核心，即–寻找以下问题的答案：

• 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