gpt4 book ai didi

JProfiler:尝试查找内存泄漏

转载 作者:行者123 更新时间:2023-12-03 00:26:50 26 4
gpt4 key购买 nike

我的应用程序需要大约 10 GB 的 RAM 用于特定输入,而对于常规输入,大约 1 GB 就足够了。使用 JProfiler 进行更仔细的分析表明(GC 之后)相当多的内存被 java.util.* 中的标准类使用。 :

LinkedHashMap$Entry , HashMap$Entry[] , LinkedHashMap , HashMap$KeySet , HashMap$EntrySet , LinkedHashSet , TreeMap$Entry ,和TreeMap (按此顺序)和相关类(class)。下面的条目是我自己代码中的一个类,其中实例的数量和使用的内存量看起来非常合理。

详细而言,总堆使用量约为 900 MB,我看到以下内容 Size All Objects 中的条目查看:

  • LinkedHashMap$Entry : 418 MB
  • HashMap$Entry[] : 178 MB
  • LinkedHashMap : 124 MB
  • HashMap$KeySet : 15 MB

LinkedHashMap 使用的内存似乎太高了,即使考虑到每个 LinkedHashSetLinkedHashMap 支持.

我在 JProfiler 中记录了对象分配并观察 Allocation Hot Spots对于 LinkedHashMap 。在那里,我看到了我不理解的条目:

  • 第三个条目显示了一个名为 X.<init> 的热点(占已分配内存的 6.5%)。哪里X是我自己的代码中的一个类。该方法的构造函数与LinkedHashMap没有任何关系。 。继此条目后进入Thread.run最后显示从 6.5% 缓慢下降到 5.8% Thread.run 。我在 X 中的代码可能有什么问题? ?为什么会显示在这里?
  • 大约 8% 的已分配内存显示在名为 java.util.HashSet.iterator 的热点中。 。沿着百分比最高的路径(第一个条目:2.8%)跟踪此条目,我在代码中得到了几个方法,直到最后 java.lang.Thread.run显示(2.8%)。这是什么意思?据我所知Thread.run方法不会创建 LinkedHashMap 的实例。与 iterator 有什么关系?方法?

一般来说,如何找到保留对(很多)LinkedHashMap 的引用的代码物体?使用 Heap Walker,我只能看到很多这些实例,但看不到任何模式(即使在观察 GC 根的路径时)。在我的实验中,所有实例似乎都是有序的。

可能重要的事情:

  • 我的应用程序构建了一个结果(用于进一步处理),并且对于此构建,观察到了高内存使用率。该结构不断创建对象,因此等待稳定点,然后观察创建的每个对象 LinkedHashMap对象是不可能的。
  • 我拥有可供调试的优质计算机(最多 48 个内核和 192 GB RAM,甚至可能更多)。
  • java 版本“1.7.0_13”(Java(TM) SE 运行时环境(版本 1.7.0_13-b20),Java HotSpot(TM) 64 位服务器 VM(内部版本 23.7-b01,混合模式)
  • JProfiler 7.2.2(内部版本 7157),已获得许可

最佳答案

In general, how do I find the code that keeps references to (a lot of) LinkedHashMap objects?

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

enter image description here

至于您关于分配热点以及为什么显示 Thread.run 方法的问题:这些是回溯,它们显示了如何调用热点以及节点上的所有数字对热点的贡献位于顶部。最深的节点始终是入口点,通常是 Thread.run 方法或 main 方法。

关于JProfiler:尝试查找内存泄漏,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14954131/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com