追踪int []的分配

Wil*_*ill 8 java debugging

通过JMX在JVisualVM中查看我的远程应用程序时,我发现空闲时内存使用情况如下:

在此输入图像描述

采用堆转储并使用JVisualVM进行分析,我看到一大块内存存在于几个int[]没有引用的大数组中,通过比较堆转储,我可以看到它们似乎正在占用内存并被回收GC定期.

我很想跟踪这些,因为它引起了我的兴趣,我自己的代码永远不会故意分配任何int[]数组.

我确实使用了很多像netty这样的库,所以罪魁祸首可能在其他地方.我确实有其他服务器具有相同的框架组合,但在那里看不到这个锯齿.

我怎样才能发现谁在分配它们?

Rya*_*yan 3

进行堆转储并找出保存它们的对象。一旦您知道哪些对象保存了数组,您应该可以轻松地弄清楚是什么在分配它们。

它没有回答你的问题,但我的问题是:

你为什么在乎?

您已经告诉 jvm 垃圾收集器 (GC) 它最多可以使用 1GB 内存。Java 使用的内存不足 250M。

GC 试图智能地了解垃圾收集的时间以及垃圾收集的工作量。在你的图表中,没有内存需求。jvm 远未接近您设置的 1GB 限制。我认为 GC 根本没有理由应该非常努力。也不知道为什么你会关心。

垃圾收集器偷懒是件好事。GC 工作的次数越少,您的应用程序可用的资源就越多。

您是否尝试过通过 JVisualVM“执行 GC”按钮触发 GC?该按钮应该触发“停止世界”垃圾收集操作。当图表位于其中一个锯齿斜坡的中间时尝试一下 - 我预测使用量将下降到锯齿的底部或以下。如果确实如此,那就证明内存锯齿只是垃圾堆积,GC 正在做正确的事情。

这是我使用的 java swing 应用程序的内存使用情况的屏幕截图: 在此输入图像描述

注意锯齿图案。

你说你担心 int[]。当我启动内存分析器并让它分析所有内容时,我可以看到 int[] 的分配

在此输入图像描述

基本上所有分配都来自 ObjectOutputStream$HandleTable.growEntries 方法。看起来进行分配的线程已启动以处理网络消息。
我怀疑是jmx本身造成的。可能是通过 rmi (你使用 rmi 吗?)。或调试器(您是否连接了调试器?)。