网站开发合同甲方的权利,网站建设招标流程,北京公司注册地址查询,上海培训机构这篇文章是我们开放文化的一部分-我们继续分享日常工作中的见解。 这次#xff0c;我们窥视了我们价值主张的核心#xff0c;即–寻找以下问题的答案#xff1a; Java应用程序中多长时间发生一次内存泄漏#xff1f; 内存泄漏有多大#xff1f; 内存泄漏增长多快#… 这篇文章是我们开放文化的一部分-我们继续分享日常工作中的见解。 这次我们窥视了我们价值主张的核心即–寻找以下问题的答案 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的事实已成为不可采取的措施。 将泄漏的大小与泄漏的速度耦合起来事件的严重性变得更加清楚 上图的信息可以这样解释对于637次出现的情况发现时的泄漏速度在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
