监视堆上类的实例数

Question

我工作的公司构建Java“企业软件”：大型，复杂，通常没有精心设计和维护的软件。我们经常遇到内存泄漏问题，如果不是几分钟就能在几小时内看到。通过正常监视内存使用情况并在堆转储变得严重时进行堆转储，可以清楚地看到这些内存泄漏。

根据我们的监控情况，它看起来似乎也在长时间内（几周甚至几个月）慢慢泄漏记忆。单个内存转储无法提供有关内存泄漏位置及其随时间发展的信息。

所以我正在寻找某种工具，可以定期生成/提供当前驻留在堆中的每个类的数字实例的报告。很像jmap -histo可以提供。但是，由于这应该在生产实例上定期运行，因此应该具有较低的开销，而不是冻结JVM。

具有29M 27K类实例的2GiB活动堆并非罕见数字。

Answer 1

从heapSpank.org查看heapSpank - 我是作者。 heapSpank以您可以配置的间隔执行jmap -histo。 它显示了最有可能泄漏的15个类的字节数增加的时间百分比。 该百分比称为“泄漏百分比” - 表示为LKY％。 LKY％为100％的班级是最可能的泄密嫌疑人。

这种方法的优点如下：

• 捕获jmap -histo数据的开销明显低于heapdumps。
• 无需重新启动JVM，就像连接分析器一样。
• 如果你习惯在生产中执行jmap -histo几次，那么heapSpank只会增加少量的开销。
• 开源和纯java解决方案。
• 只需下载小（2mb）可执行jar文件并传入漏洞JVM的pid。

缺点：

• 不支持permgen / metaspace泄漏。
• 不支持jmap与远程JVM的连接。
• 仅适用于HotSpot JDK - 不适用于IBM J9 This link是我在寻求支持J9方面的帮助请求。

以下是关于保持低开销的一些注意事项。

This link提供有关配置的详细信息。 增加此间隔以进一步降低开销：

org.heapspank.jmap.histo.interval.seconds=5

默认情况下，为了保持低开销，heapSpank不会将-live参数传递给jmap -histo。 但有一个权衡。不使用-live参数会提供不太准确的结果。

#If true, jmap -histo is passed the '-live' parameter, 
#which forces a full GC with every jmap -histo run.
#Using true will identify leak suspects more quickly & accurately, 
#but will incur extra GC overhead.  
org.heapspank.jmap.histo.live=false

目前，heapSpank是一个命令行程序，具有unix'top'之类的显示。 The heapSpank roadmap表明我们希望使用通用/流行的开源监控工具和容器部署相同的技术。