监视堆上类的实例数答案

【问题标题】：Monitor number of instances of classes on heap监视堆上类的实例数
【发布时间】：2016-05-27 19:12:24
【问题描述】：

我工作的公司构建 Java“企业软件”：大型、复杂且通常设计和维护不完善的软件。我们经常遇到内存泄漏问题，这些问题在数小时甚至数分钟内就会显现出来。这些内存泄漏通过正常监控内存使用情况并在变得严重时进行堆转储时清晰可见。

根据我们的监控，它看起来也在很长一段时间内（数周甚至数月）缓慢地泄漏内存。单个内存转储无法提供关于内存泄漏的位置以及随着时间的推移如何发展的深入信息。

所以我正在寻找某种工具，它可以定期生成/提供当前驻留在堆中的每个类的数量实例的报告。就像jmap -histo 可以提供的一样。但由于这应该在生产实例上定期运行，它的开销应该很低，并且不会冻结 JVM。

2GiB 的活动堆和 27K 类的 29M 实例并不少见。

【问题讨论】：

我想每周日凌晨 2 点重新启动应用程序的通常“企业级”解决方案不可行？
没有任何开销就无法监控此信息。开销最低的工具是飞行记录器，尽管这需要生产许可证。
@Thilo 我更喜欢实际解决问题。考虑到它泄漏的速度非常慢，它很少会泄漏足够长的时间而成为问题，因为服务器会接受定期维护，因此每个月或两个月重新启动并不奇怪。

标签： java memory-leaks heap-memory

【解决方案1】：

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

以下是该方法的优点：

捕获 jmap -histo 数据的开销明显低于堆转储。
无需像挂接分析器那样重新启动 JVM。
如果您愿意在生产环境中执行几次 jmap -histo，那么 heapSpank 只会增加少量开销。
开源纯java解决方案。
只需下载小 (2mb) 可执行 jar 文件并传入泄漏 JVM 的 pid。

缺点：

不支持永久/元空间泄漏。
不支持 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 的“顶部”显示。 The heapSpank roadmap 表明我们希望将同样的技术与常见/流行的开源监控工具和容器一起部署。

【讨论】：