分页对垃圾回收有何影响？
分页对垃圾收集有什么影响？
what are the effects of paging on garbage collection ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
分页对垃圾收集有什么影响？
what are the effects of paging on garbage collection ?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（2）
分页对垃圾收集的影响与对任何事物的影响几乎相同。它允许访问大量内存，但在发生这种情况时会损害性能。
更紧迫的问题是垃圾收集对分页的影响是什么？
垃圾收集可能会导致在给定时间点读取和写入原本不会考虑的内存区域。因此，减少垃圾收集导致分页发生的程度是有利的。这是分代压缩收集器提供的优点之一，因为它会导致更多短期对象位于一页中，从该页收集，并且内存可供其他对象使用，同时还将长期对象保留在一个页面中。相关对象更有可能存在的页面（长寿命对象通常会与其他长寿命对象相关，因为一个长寿命对象使其他对象保持活动状态）。这不仅减少了执行收集所需的分页量，而且有助于减少应用程序其余部分所需的分页量。
The effects of paging on garbage-collection are pretty much the same as upon anything; it allows access to lots of memory, but hurts performance when it happens.
The more pressing question, is what is the effect of garbage-collection on paging?
Garbage collection can cause areas of memory to be read from and written to that would not be considered otherwise at a given point of time. Reducing the degree to which garbage collection causes paging to happen is therefore advantageous. This is one of the advantages that a generational compacting collector offers, as it leads to more short-lived objects being in one page, collected from that page, and the memory made available to other objects, while also keeping long-lived objects in a page where related objects are more likely to also be (long-lived objects will often be related to other long-lived objects because one long-lived object is keeping the others alive). This not only reduces the amount of paging necessary to perform the collection, but can help reduce the amount of paging necessary for the rest of the application.
首先是一些术语。在某些领域，例如与 Linux 相关的讨论，分页是操作系统的一项功能，其中可执行代码不需要永久保存在 RAM 中。可执行代码来自可执行文件，当CPU遍历程序中的指令时，内核按需从磁盘加载它。当内存紧张时，内核可能决定简单地“忘记”一页代码，因为它知道如果需要再次执行该代码，它总是可以从可执行文件重新加载它。
内核还实现了另一个称为交换的功能，它与类似的功能有关，但针对的是数据。数据不是从可执行文件中获取的。因此，内核不能简单地忘记一页数据；它必须将其保存在某个称为“交换文件”或“交换分区”的专用区域中。这使得交换比分页更昂贵：内核必须在重用相应的 RAM 之前写出数据页，而代码页可以直接重用。实际上，在考虑交换之前，内核会进行很多分页。
因此，分页与垃圾收集是正交的。 交换却不是。一般的经验法则是交换和 GC 不能很好地混合。大多数GC通过定期检查数据来工作，如果所述数据已发送到交换分区，则必须从该分区重新加载它，这意味着必须将其他一些数据发送到所述分区，因为如果数据在交换区中而不是在 RAM 中，那么这意味着内存紧张。在存在交换的情况下，GC 往往意味着大量的磁盘活动。
一些 GC 应用复杂的策略来减少与交换相关的策略。这包括分代 GC（尝试较少地探索旧数据）和严格类型化（GC 查看数据，因为它需要定位指针；如果它知道一大块 RAM 仅包含非指针，例如，它是一些仅具有像素值的图片数据，那么它可以不理会它，特别是不将其从交换区域强制返回）。 Java 虚拟机（来自 Sun/Oracle 的虚拟机）中的 GC 非常擅长这一点。但这只是相对的：如果您的 Java 应用程序发生交换，那么您将遭受可怕的痛苦。但情况可能更糟。
只需购买一些额外的内存即可。
First a bit of terminology. In some areas, e.g. Linux-related talks, paging is a feature of the operating system in which executable code needs not be permanently in RAM. Executable code comes from an executable file, and the kernel loads it from the disk on demand, when the CPU walks through the instructions in the program. When memory is tight, the kernel may decide to simply "forget" a page of code, because it knows that it can always reload it from the executable file, if that code needs to be executed again.
The kernel also implements another feature which is called swapping and is about something similar, but for data. Data is not obtained from the executable file. Hence, the kernel cannot simply forget a page of datal; it has to save it somewhere, in a dedicated area called a "swap file" or "swap partition". This makes swapping more expensive than paging: the kernel must write out the data page before reusing the corresponding RAM, whereas a code page can simply be reused directly. In practice, the kernel pages quite a lot before considering swapping.
Paging is thus orthogonal to garbage collection. Swapping, however, is not. The general rule of thumb is that swapping and GC do not mix well. Most GC work by regularly inspecting data, and if said data has been sent to the swap partition, then it will have to be reloaded from that partition, which means that some other data will have to be sent to the said partition, because if the data was in the swap and not in RAM then this means that memory is tight. In the presence of swapping, a GC tends to imply an awful lot of disk activity.
Some GC apply intricate strategies to reduce swap-related strategies. This includes generational GC (which try to explore old data less often) and strict typing (the GC looks at data because it needs to locate pointers; if it knows that a big chunk of RAM contains only non-pointers, e.g. it is some picture data with only pixel values, then it can leave it alone, and in particular not force it back from the swap area). The GC in the Java virtual machine (the one from Sun/Oracle) is known to be quite good at that. But that's only relative: if your Java application hits swap, then you will suffer horribly. But it could have been much worse.
Just buy some extra RAM.