垃圾收集器如何处理 Xmx 和 Xms 值答案

【问题标题】：How garbage collector works with Xmx and Xms values垃圾收集器如何处理 Xmx 和 Xms 值
【发布时间】：2018-09-26 03:06:03
【问题描述】：

我对 JVM 垃圾收集器如何处理不同的 Xmx 和 Xms 值以及机器内存大小有一些疑问：垃圾收集器将如何在以下情况下工作：

1. Machine memory size = 7.5GB
   Xmx = 1024Mb
   Number of processes = 16
   Xms = 512Mb

我知道 16*512Mb 已经超过了机器内存大小。在这种情况下垃圾收集器将如何工作。我认为在这种情况下，内存使用量将是整个 7.5GB。这些流程将能够在这方面做任何事情吗？或者他们都会被卡住？

2. Machine memory size = 7.5GB
   Xmx = 320MB
   Xms is not defined.
   Number of Processes = 16

在此，16*320Mb 应该小于 7.5GB。但就我而言，内存使用量再次达到 7.5GB。是否可以？或者我的应用程序中可能存在内存泄漏？

所以，基本上我想了解垃圾收集器何时运行？它是否在应用程序使用的内存达到恰好 Xmx 值时运行？还是根本没有关系？

【问题讨论】：

垃圾收集器不需要对你使用超过物理内存做任何事情。实现虚拟内存是操作系统的职责。除此之外，还有更多的堆内存。有程序代码、类元数据、堆栈、I/O 缓冲区等等。因此内存消耗可能高于您的最大堆大小。

标签： garbage-collection jvm

【解决方案1】：

这里有几件事需要了解，然后根据您的情况考虑。

每个 JVM 进程都有自己的虚拟地址空间，由操作系统保护它不受其他进程的影响。操作系统将地址的物理范围（称为页面）映射到每个进程的虚拟地址空间。当需要的物理页面多于可用页面时，一段时间未使用的页面将被写入磁盘（称为分页），然后可以重新使用。当再次需要这些已保存页面的数据时，它们将被读回相同或不同的物理页面。通过这样做，您可以轻松地在具有 8Gb 物理内存的机器上运行 16 个或更多 JVM，所有这些 JVM 都具有 1Gb 的堆。问题在于，需要的磁盘分页越多，应用程序的性能就会越低，因为磁盘 IO 比 RAM 访问慢几个数量级。这也是单个JVM的堆空间不能大于物理内存的原因。

使用 -Xms 和 -Xmx 选项的原因是您可以指定堆的初始大小和最大大小。当您的应用程序运行并需要更多堆空间时，JVM 能够在这些范围内增加堆大小。很多时候，这些值设置为相同，以消除在应用程序运行时必须调整堆大小的开销。大多数操作系统仅在需要时分配物理页面，因此在您的情况下，使 -Xms 变小不会改变发生的分页量。

这里的关键点是操作系统的虚拟内存系统使得它看起来使用的内存比你机器上的物理内存要多。

【讨论】：