Python：垃圾收集器是否在引发 MemoryError 之前运行？

Question

在一个 Python 代码中，该代码迭代了一系列涉及内存和 CPU 密集型数值计算的 30 个问题，我观察到 Python 进程的内存消耗随着 30 次迭代中的每一次迭代的开始而增长约 800MB，最后在第 8 次迭代中引发MemoryError（实际上系统内存已耗尽）。但是，如果我 import gc 并让 gc.collect() 在每次迭代后运行，则内存消耗保持在 ~2.5GB 不变，并且 Python 代码在解决所有 30 个问题后很好地终止。该代码只使用了连续2个问题的数据，没有引用循环（否则手动垃圾收集也无法降低内存消耗）。

问题

如果 Python 在引发 MemoryError 之前尝试运行垃圾收集器，此行为会引发问题。在我看来，这将是一件非常理智的事情，但也许有反对这样做的理由？

在此处进行了与上述类似的观察：https://stackoverflow.com/a/4319539/1219479

Answer 1

实际上，存在 个引用循环，这也是手动 gc.collect() 调用完全能够回收内存的唯一原因。

在 Python 中（我在这里假设 CPython），垃圾收集器的唯一目的是打破引用循环。当没有对象存在时，对象将被销毁，并在最后一次对它们的引用丢失时回收它们的内存。

至于垃圾收集器何时运行，完整文档在这里：http://docs.python.org/2/library/gc.html

它的 TLDR 是 Python 维护一个对象分配和释放的内部计数器。每当(allocations - deallocations) 达到 700（阈值 0）时，就会运行垃圾回收并重置两个计数器。

每次发生收集（自动或使用gc.collect() 手动运行）时，都会收集第 0 代（尚未在收集中幸存的所有对象）（即遍历没有可访问引用的对象，寻找引用循环——如果找到，循环被破坏，可能导致对象被破坏，因为没有剩下的引用）。在该集合之后剩余的所有对象都将移至第 1 代。

每 10 个集合（阈值 1），第 1 代也被收集，并且在第 1 代中存活的所有对象 被移动到第 2 代。第 1 代的每 10 个集合（即每个100 个集合——阈值 2)，第 2 代也被收集。留在第 2 代中的幸存对象 - 没有第 3 代。

这 3 个阈值可以通过调用gc.set_threshold(threshold0, threshold1, threshold2) 由用户设置。

这对你的程序意味着什么：

1. GC 不是 CPython 用来回收内存的机制（引用计数是）。 GC 会中断“死”对象中的引用循环，这可能会导致其中一些被销毁。
2. 不，不能保证 GC 会在 MemoryError 引发之前运行。
3. 您有参考周期。尝试摆脱它们。