为什么GC甚至发生在有大量未使用的内存的左

Question

（承诺和最高线是相同的）

我在看的内存使用量在一NewRelic的Java应用程序。这里有几个问题：

＃1

的committed PS Survivor Space Heap多样过去几天。但是它应该是一个常量，因为它是由JVM配置的？

＃2

从我所了解，当有一个垃圾收集堆内存应该减少。 Eden的内存可能会减少，当一个主要的gc或次要的gc发生时，而Old的内存可能会减少，当一个主要的gc发生时。

但是，如果你看看Old内存使用情况，在6月6日到7日之间的某段时间，内存升高，然后降低。这应该代表一个重大的gc发生，对吧？但是，仍有大量未使用的内存。它似乎并没有达到极限。那么主要的gc如何被触发？内存使用量相同，但从未达到极限，但仍然下降。

应用程序从其他地方获取文件。这个文件可能很大，并在内存中处理。这可以解释上述问题吗？

Answer 1

您需要提供更多关于您的配置的信息来明确回答这个问题，我会假设您使用的是Oracle的Hotspot JVM，并且您使用的是G1收集器。发布启动JVM的标志也很有用。

1. 这里的关键词是'犯'。这是由JVM保留的内存，但不一定在使用（或者甚至映射到物理页面，这只是JVM可以使用的一系列虚拟内存）。在java.lang.management包的MemoryUsage类中有一个很好的描述（检查API文档）。它表示，“提交表示保证可供Java虚拟机使用的内存量（以字节为单位）。提交的内存量可能会随时间变化（增加或减少）。Java虚拟机可能会释放内存到系统......“这就是你看到它发生变化的原因。

2. 假设您使用的是G1，那么收集器会执行增量压缩。你是正确的，如果收集者无法跟上旧有分配，并且空间不足，它将执行完整的压缩集合。由于最后一个图表显示您在分配的堆空间附近没有使用，因此这里不会发生这种情况。但是，为了避免这种情况，G1会与您的应用程序同时收集和压缩。这就是为什么你看到使用率上升（当你的应用程序实例化更多的对象），然后下降（因为G1收集器回收不再需要的对象的空间）。有关G1如何工作的更详细说明，请参阅文档https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html。