我有些怀疑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 值时，它是否运行？或者他们根本没有关系？
这里有几件事需要理解，然后在您的情况中考虑。
每个 JVM 进程都有自己的虚拟地址空间，操作系统保护该空间免受其他进程的影响。 OS 将地址的物理范围(称为页(映射到每个进程的虚拟地址空间。 当所需的物理页多于可用页时，一段时间未使用的页将被写入磁盘(称为分页(，然后可以重复使用。 当再次需要这些保存页面的数据时，它们将被读回相同或不同的物理页面。 通过这样做，您可以在具有 8Gb 物理内存的机器上轻松运行 16 个或更多 JVM，所有 JVM 的堆为 1Gb。 问题在于，所需的磁盘分页越多，就越会降低应用程序的性能，因为磁盘 IO 比 RAM 访问慢几个数量级。 这也是单个 JVM 的堆空间不应大于物理内存的原因。
使用 -Xms 和 -Xmx 选项的原因是，您可以指定堆的初始大小和最大大小。 当您的应用程序运行并需要更多的堆空间时，JVM 能够在这些范围内增加堆大小。 很多时候，这些值设置为相同，以消除在应用程序运行时必须调整堆大小的开销。 大多数操作系统只在需要时分配物理页，因此在您的情况下，使 -Xms 变小不会更改发生的分页量。
这里的关键点是，操作系统的虚拟内存系统使看起来使用的内存可能比计算机中的物理内存多。