【发布时间】：2010-10-03 12:36:29
【问题描述】：
分页对垃圾回收有什么影响？
【问题讨论】：
标签： java garbage-collection heap-memory
【发布时间】：2010-10-03 12:36:29
【问题描述】：
分页对垃圾收集的影响与任何事情几乎相同；它允许访问大量内存，但会损害性能。
更紧迫的问题是，垃圾回收对分页有什么影响？
垃圾收集可能会导致在给定时间点读取和写入不会以其他方式考虑的内存区域。因此，减少垃圾收集导致分页发生的程度是有利的。这是分代压缩收集器提供的优势之一，因为它导致更多的短期对象位于一个页面中，从该页面收集，并且内存可供其他对象使用，同时还将长期对象保存在一个相关对象也更有可能存在的页面（长寿对象通常与其他长寿对象相关，因为一个长寿对象使其他对象保持活动状态）。这不仅减少了执行收集所需的分页量，还有助于减少应用程序其余部分所需的分页量。
【讨论】：
-
还有一件事。垃圾收集器可能必须查看 lot 的内存，然后在查看之前需要交换这些内存。影响可能会更糟。
-
@Thorbjørn 是的，我在“与任何事情都一样”中考虑过这一点，但是与大多数其他代码相比，GC 必须扫描的内存量异常大，所以这很好值得单独列出。
首先是一些术语。在某些领域，例如Linux 相关讨论，分页 是操作系统的一项功能，其中可执行代码不需要永久保存在 RAM 中。可执行代码来自可执行文件，当 CPU 遍历程序中的指令时，内核会根据需要从磁盘加载它。当内存紧张时，内核可能会决定简单地“忘记”一页代码，因为它知道如果需要再次执行该代码，它总是可以从可执行文件中重新加载它。
内核还实现了另一个称为 swapping 的功能，它是关于类似的东西，但用于数据。数据不是从可执行文件中获取的。因此，内核不能简单地忘记一页数据。它必须将其保存在某个称为“交换文件”或“交换分区”的专用区域中。这使得交换比分页更昂贵：内核必须在重用相应的 RAM 之前写出数据页，而代码页可以简单地直接重用。实际上，在考虑交换之前，内核页面相当多。
分页 因此与垃圾收集正交。 交换，然而，不是。一般的经验法则是交换和 GC 不能很好地混合。大多数 GC 通过定期检查数据来工作，如果所述数据已发送到交换分区，则必须从该分区重新加载，这意味着必须将一些其他数据发送到所述分区，因为如果数据在交换中而不是在 RAM 中，那么这意味着内存很紧。在存在交换的情况下，GC 往往意味着大量的磁盘活动。
一些 GC 应用复杂的策略来减少与交换相关的策略。这包括分代 GC（尝试较少地探索旧数据）和严格类型（GC 查看数据是因为它需要定位 pointers；如果它知道一大块 RAM 只包含非指针，例如它是一些只有像素值的图片数据，然后它可以不理会它，特别是 not 将其从交换区域强制返回）。众所周知，Java 虚拟机（来自 Sun/Oracle）中的 GC 非常擅长这一点。但这只是相对的：如果您的 Java 应用程序命中交换，那么您将遭受可怕的痛苦。但情况可能会更糟。
只需购买一些额外的 RAM。
【讨论】：