我最近用一个应用程序监视工具（StatsD）配置了一个JBOSS应用程序，该工具有助于捕获该应用程序的JVM使用率。即使没有任何单个用户使用该应用程序，内存模式也会占用已分配内存（1024 MB）的大约90-95％（850-970 MB）。 当内存达到90-95％时，次要GC会在每个点运行。同样，请参见下面的屏幕截图。
请求您的帮助以了解造成这种内存模式的原因。 *没有批处理作业或后台进程正在运行。 enter image description here
答案 0 :(得分：0)
这对我来说似乎是正常行为。使用的堆空间逐渐增加到运行GC的地步。然后，GC会回收大量可用空间，并且所使用的堆空间会急剧下降。然后重复。
看起来您在同一张图中有来自两个单独的JVM的统计信息，但我想您知道这一点。 （您已经遮盖了图形上可以解释这一点的标签。）
我能从中学到的另一件事是，内存分配率偏高，导致GC频繁运行。建议进行一些GC调整。但是我只建议如果应用程序级性能受到影响。 （很可能真正的问题是应用程序的效率而不是GC的性能。）
然后：
但是我在这里也遇到了一个问题，即堆转储说它约为1GB，但是当我将其上传到Eclipse MAT时，它仅显示11MB的转储。大多数重物可以在MAT的“未到达物”部分看到。如果您有任何想法或使用MAT进行分析，请让我知道为什么1GB的转储在MAT中仅显示11MB的大小。
这也很容易解释。 “未到达的对象”是垃圾。您必须在堆使用率接近峰值之一的瞬间运行堆转储工具。
退后一步，我不清楚您在这里真正寻找的是什么
如果您只是想了解监视的外观，那么这就是JVM通常的外观。
如果您要调查性能问题（GC暂停等），则需要查看其他证据。
如果您正在寻找内存泄漏的证据，那么您就在错误的位置。这些图对此无济于事。您需要长期观察JVM的行为。寻找诸如“锯齿”中的长期趋势之类的事物，例如槽底部的水平趋于上升。要调查可疑的内存泄漏，您需要比较MAT分析以了解一段时间内发生的转储。
但是请记住，随着时间的推移增加内存使用量并不一定会导致内存泄漏。它可能是应用程序库中的东西缓存。如果JVM开始耗尽内存，则正确实现的缓存将释放对象。
