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

采用堆转储并使用JVisualVM进行分析,我看到一大块内存存在于几个int[]没有引用的大数组中,通过比较堆转储,我可以看到它们似乎正在占用内存并被回收GC定期.
我很想跟踪这些,因为它引起了我的兴趣,我自己的代码永远不会故意分配任何int[]数组.
我确实使用了很多像netty这样的库,所以罪魁祸首可能在其他地方.我确实有其他服务器具有相同的框架组合,但在那里看不到这个锯齿.
我怎样才能发现谁在分配它们?
进行堆转储并找出保存它们的对象。一旦您知道哪些对象保存了数组,您应该可以轻松地弄清楚是什么在分配它们。
它没有回答你的问题,但我的问题是:
你为什么在乎?
您已经告诉 jvm 垃圾收集器 (GC) 它最多可以使用 1GB 内存。Java 使用的内存不足 250M。
GC 试图智能地了解垃圾收集的时间以及垃圾收集的工作量。在你的图表中,没有内存需求。jvm 远未接近您设置的 1GB 限制。我认为 GC 根本没有理由应该非常努力。也不知道为什么你会关心。
垃圾收集器偷懒是件好事。GC 工作的次数越少,您的应用程序可用的资源就越多。
您是否尝试过通过 JVisualVM“执行 GC”按钮触发 GC?该按钮应该触发“停止世界”垃圾收集操作。当图表位于其中一个锯齿斜坡的中间时尝试一下 - 我预测使用量将下降到锯齿的底部或以下。如果确实如此,那就证明内存锯齿只是垃圾堆积,GC 正在做正确的事情。
这是我使用的 java swing 应用程序的内存使用情况的屏幕截图:

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

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