JProfiler：尝试查找内存泄漏

Question

我的应用程序需要大约10GB的RAM用于特定输入，而对于常规输入，大约1GB就足够了。通过对JProfiler进行更仔细的分析，可以发现（在GC之后）java的标准类使用了相当多的内存。util* ：

LinkedHashMap$Entry、HashMap$Entry[]、LinkedHashMap、HashMap$KeySet、HashMap$EntrySet、LinkedHashSet、TreeMap$Entry、TreeMap（按此顺序）和相关类。下面的条目是我自己代码中的一个类，其中实例的数量和使用的内存量似乎非常合理。

详细说明，总堆使用量约为900 MByte，我在All Object视图中看到以下Size条目：

• LinkedHashMap$Entry:418 MB
• HashMap$Entry[]：178 MB
• LinkedHashMap:124兆字节
• HashMap$KeySet:15 MB

LinkedHashMap使用的内存似乎过高，即使考虑到每个LinkedHashSet都有一个LinkedHashMap作为后盾。

我在JProfiler中记录了对象分配，并观察了LinkedHashMap的分配热点。在那里，我看到我不理解的条目：

• 第三个条目显示了一个名为X的热点（占分配内存的6.5%）。

一般来说，如何找到保留对（许多）LinkedHashMap对象引用的代码？使用堆遍历器，我只能看到很多这样的实例，但看不到任何模式（即使在观察GC根的路径时）。在我的实验中，所有的例子似乎都是有序的。

可能重要的事情：

• 我的应用程序构造了一个结果（用于进一步处理），对于这种构造，观察到内存使用率很高。构造会不断创建对象，因此不可能等待一个稳定点，然后观察每个创建的LinkedHashMap对象




Answer 1

一般来说，如何找到保留对（大量）LinkedHashMap对象的引用的代码？

在堆遍历器中，选择“LinkedHashMap”并创建一个新的对象集。然后切换到“引用”视图并显示“累积传入引用”。在那里，您可以分析整个对象集的引用。

至于你关于分配热点和为什么显示Thread.run方法的问题：这些是反向跟踪，它们显示热点是如何被调用的，节点上的所有数字都是对顶部热点的贡献。最深的节点将永远是切入点，通常是Thread.run方法或主方法。