gc模块 — 垃圾回收接口

Python标准库精讲专题 · 开发辅助篇 · 掌握垃圾回收机制

专题：Python标准库精讲系统学习

关键词：Python, 标准库, gc, 垃圾回收, 引用计数, 分代回收, collect, get_objects, 循环引用, 内存泄漏

一、Python内存管理

Python 的内存管理采用"引用计数为主，分代回收为辅"的双层架构。引用计数（Reference Counting）是最基础的内存管理手段：每个 Python 对象内部维护一个 ob_refcnt 字段，每当有新的引用指向该对象时计数加 1，引用被删除时计数减 1，当计数归零时对象立即被回收。这种策略的优点是简单、实时，缺点是无法处理循环引用——当两个或多个对象互相引用时，它们的引用计数永远不会归零，导致内存泄漏。

正是为了弥补引用计数的这个致命短板，gc 模块（Garbage Collector）应运而生。它负责检测并回收那些引用计数无法处理的"垃圾"——主要是容器对象（list、dict、set、tuple、自定义类实例等）之间形成的循环引用。gc 模块在 Python 的 CPython 实现中默认是启用的，它作为引用计数的"安全网"，确保循环引用不会导致永久的内存泄漏。

核心理解：引用计数负责"快速回收"（对象无引用时立即销毁），gc 模块负责"兜底回收"（清理循环引用的孤岛）。两者协同工作，构成了 Python 内存安全的基石。

需要特别注意的是，gc 模块跟踪的容器对象仅限于那些"可能包含其他对象引用"的类型。不可变类型如 int、str、tuple（不含嵌套引用时）不会被 gc 跟踪。可以通过 gc.is_tracked(obj) 检查某个对象是否被 gc 跟踪。

import gc

# 查看当前是否启用了垃圾回收
print(gc.isenabled())  # True

# 检查一个简单对象是否被 gc 跟踪
print(gc.is_tracked(42))       # False — int 不可变，不会被跟踪
print(gc.is_tracked([]))       # True — list 是可变容器
print(gc.is_tracked({}))       # True — dict 是可变容器
print(gc.is_tracked("hello"))  # False — str 不可变

二、分代回收机制

Python 的垃圾回收器采用"分代回收"（Generational GC）策略，将对象分为三代（Generation 0、1、2）。其核心理念基于"弱代假设"（Weak Generational Hypothesis）：绝大多数对象在创建后很快就不再需要，存活时间越长的对象越不可能被回收。通过将对象按"年龄"划分，gc 可以优先扫描年轻代，以最小的开销回收最多的垃圾。

三代结构

代	名称	特征
0	年轻代	新创建的可跟踪对象，回收频率最高
1	中年代	经历一次 GC 后幸存的对象
2	老年代	经历两次及以上 GC 后幸存的对象，回收频率最低

对象在创建时被放入第 0 代。当 gc 执行一次第 0 代收集后，所有仍然存活的对象会被"晋升"（promote）到第 1 代；同理，第 1 代收集后存活的对象晋升到第 2 代。第 2 代是最高代，其中的对象会一直保留直到第 2 代收集发生。

阈值与触发条件

gc 模块使用三个阈值（thresholds）控制各代回收的触发时机。默认阈值为 (700, 10, 10)：

阈值0（700）：第 0 代对象数量减去第 0 代幸存对象数后的差值达到 700 时，触发第 0 代收集。
阈值1（10）：每执行 10 次第 0 代收集后，触发一次第 1 代收集。
阈值2（10）：每执行 10 次第 1 代收集后，触发一次第 2 代收集。

import gc

# 查看当前阈值
print(gc.get_threshold())  # (700, 10, 10)

# 查看各代的统计信息
for i, gen in enumerate(gc.get_stats()):
    print(f"Generation {i}: {gen}")

# 输出示例:
# Generation 0: {'collections': 12, 'collected': 3840, 'uncollectable': 0}
# Generation 1: {'collections': 1, 'collected': 128, 'uncollectable': 0}
# Generation 2: {'collections': 0, 'collected': 0, 'uncollectable': 0}

分代统计（get_stats）

gc.get_stats() 返回一个包含三个字典的列表，每个字典对应一代的统计信息，包含以下字段：

collections — 该代已执行的收集次数
collected — 该代已回收的对象总数
uncollectable — 该代无法回收的对象总数（通常由 __del__ 方法导致）

这些统计信息对于监控程序的内存健康状况非常有价值。如果你发现 uncollectable 数量持续增长，说明存在循环引用且涉及析构方法，需要排查代码。

三、回收控制

gc 模块提供了完整的回收控制接口，允许开发者启用、禁用垃圾回收，以及在合适的时机手动触发回收。这在性能敏感型应用（如实时系统、游戏引擎）中尤为重要——你可能希望在关键时刻临时禁用 gc，待空闲时再手动回收。

启用与禁用

函数	说明
`gc.enable()`	启用自动垃圾回收（默认启用）
`gc.disable()`	禁用自动垃圾回收
`gc.isenabled()`	返回当前是否启用了自动回收

import gc

# 在性能关键区域前临时禁用 GC
gc.disable()
# ... 执行高性能计算 ...
# 完成后重新启用
gc.enable()

# 但要注意：即使禁用 gc，引用计数依然在运作
# 只有循环引用才会泄漏

手动回收（collect）

gc.collect() 是最核心的手动回收函数。它可以指定回收哪一代，如果不传参数则执行一次"完全回收"（所有代）。

import gc

# 仅回收第 0 代（最快，最常用）
n = gc.collect(0)
print(f"第0代回收了 {n} 个对象")

# 回收第 0 代 + 第 1 代
n = gc.collect(1)
print(f"第1代回收了 {n} 个对象")

# 完全回收所有代（等同于 gc.collect()）
n = gc.collect(2)
print(f"第2代回收了 {n} 个对象")

# 完全回收（最彻底的清理）
n = gc.collect()
print(f"共回收了 {n} 个对象")

实践建议：在生产环境中，gc.collect() 调用最好放在明确的内存压力点，例如处理完大批量数据后、请求结束时、或者长时间运行的任务的"检查点"。不要在每个函数中都调用，这会显著降低性能。

四、调试辅助

gc 模块提供了一组非常强大的调试工具，用于检查当前哪些对象被 gc 跟踪、对象之间的引用关系以及内存泄漏的根因。这些工具在排查内存泄漏问题时不可替代。

get_objects — 列出所有被跟踪的对象

gc.get_objects() 返回当前被 gc 跟踪的所有对象的列表（不包括 generation=None 的对象）。这是了解 Python 进程内存布局的入口，但请注意：在大型应用中，这个列表可能非常庞大，直接调用会消耗大量内存和时间。

import gc

# 获取所有被跟踪的对象
all_objects = gc.get_objects()
print(f"当前跟踪的对象总数: {len(all_objects)}")

# 按类型统计对象数量
from collections import Counter
type_counts = Counter(type(obj).__name__ for obj in all_objects)
print(type_counts.most_common(10))

# 输出示例:
# [('list', 1240), ('dict', 892), ('function', 456), ('type', 312), ...]

get_referrers — 查找谁引用了指定对象

gc.get_referrers(*objs) 返回所有直接引用指定对象的对象。这在分析"为什么这个对象没有被回收"时非常有用——你可以找到到底是谁还持有这个对象的引用。

import gc
import weakref

class MyObject:
    def __init__(self, name):
        self.name = name

# 创建循环引用的场景
a = MyObject("A")
b = MyObject("B")
a.ref = b
b.ref = a

# 查看谁引用了 a
referrers = gc.get_referrers(a)
for r in referrers:
    print(type(r).__name__, end=" ")
# 输出可能包含: MyObject (即 b 引用了 a), dict (全局命名空间), ...

get_referents — 查找指定对象引用了谁

gc.get_referents(*objs) 是 get_referrers 的反向操作，返回指定对象直接引用的所有对象。可以用来追踪对象的引用链。

import gc

class Node:
    def __init__(self):
        self.children = []

# 构建引用链
root = Node()
child1 = Node()
child2 = Node()
root.children = [child1, child2]

# 查看 root 引用了哪些对象
for ref in gc.get_referents(root):
    print(type(ref).__name__, repr(ref)[:60])
# 输出: list [...] — 因为 root.children 是一个 list

set_debug — 打印回收日志

gc.set_debug(flags) 可以设置调试标志，让 gc 在回收时输出详细信息。常用标志在 gc 模块中以常量形式提供：

标志	说明
`gc.DEBUG_STATS`	每次收集后打印统计信息
`gc.DEBUG_SAVEALL`	将无法回收的对象保存到 `gc.garbage` 列表
`gc.DEBUG_LEAK`	DEBUG_COLLECTABLE \| DEBUG_UNCOLLECTABLE \| DEBUG_SAVEALL 的组合

import gc

# 启用调试输出
gc.set_debug(gc.DEBUG_STATS | gc.DEBUG_LEAK)

# 执行一次回收，观察输出
gc.collect()

# 输出类似:
# gc: collecting generation 0...
# gc: objects in each generation: 128, 0, 0
# gc: done, 5 unreachable, 0 uncollectable

# 调试完成后关闭（否则会持续输出）
gc.set_debug(0)

使用场景：get_referrers 和 get_referents 配合使用，可以构建完整的对象引用图，非常适合在内存泄漏时定位"谁持有了本应释放的对象"。set_debug 则适合在开发和测试阶段观察 gc 的行为。

五、循环引用与析构

循环引用是引用计数机制的天敌。当两个或多个对象互相引用形成一个"引用环"时，即使外部已经没有变量指向这些对象，它们的引用计数也不会归零，因为环内的每个对象都被环内的另一个对象引用着。如果没有 gc 介入，这些对象将永远无法被回收。

典型的循环引用场景

import gc
import sys

class Container:
    def __init__(self, name):
        self.name = name
        self.ref = None

# 创建循环引用
a = Container("A")
b = Container("B")
a.ref = b
b.ref = a

# 删除外部引用
del a
del b

# 此时两个对象仍然存活（互相引用），但已无法从外部访问
# 手动触发 GC 可以回收它们
n = gc.collect()
print(f"回收了 {n} 个对象")  # 将回收上面的两个 Container 对象

# 如果是简单引用（非循环），引用计数就能处理
x = Container("X")
y = Container("Y")
x.ref = y
del x
# y.ref 仍然指向 y，但是 y 本身还存在外部引用，所以没泄漏？
# 实际上 del x 后，x 的引用计数归零，x 被回收
# 但是 x.ref 原来指向 y，x 被销毁时，y 的引用从 2 降到 1
# y 依然可达，所以没问题

garbage 列表与 del 方法

当循环引用中的对象定义了 __del__ 方法（析构函数）时，问题就变得复杂了。gc 无法确定以什么顺序调用这些 __del__ 方法——因为环中的每个对象都依赖其他对象，如果先销毁 A，B 可能无法正常工作。这种情况下，gc 会将这些对象标记为"不可回收"（uncollectable），并将它们放入 gc.garbage 列表。

import gc

class WithDel:
    def __init__(self, name):
        self.name = name
        self.ref = None
    def __del__(self):
        print(f"{self.name} 被销毁")

# 如果启用 DEBUG_SAVEALL，不可回收对象会进入 gc.garbage
gc.set_debug(gc.DEBUG_SAVEALL)

a = WithDel("A")
b = WithDel("B")
a.ref = b
b.ref = a

del a, b

# 执行回收
gc.collect()

# 查看 gc.garbage
if gc.garbage:
    print("不可回收的对象:")
    for obj in gc.garbage:
        print(f"  {obj.name}, 类型: {type(obj).__name__}")

# 清理 gc.garbage 并关闭调试
gc.garbage.clear()
gc.set_debug(0)

重要：在现代 Python（3.4+）中，gc.garbage 在大多数情况下是空的，因为 CPython 已经改进了循环引用中 __del__ 的处理。但在涉及 C 扩展类型或旧版 Python 时仍需留意。最佳实践是尽量避免在容器类中定义 __del__ 方法，改用上下文管理器（__enter__/__exit__）或 weakref.ref 回调来执行清理逻辑。

弱引用替代方案

weakref 模块是打破循环引用的标准方案。弱引用不会增加对象的引用计数，因此不会阻碍 gc 回收对象。当你需要一种"引用但不控制生命周期"的关系时，弱引用是最佳选择。

import weakref

class Parent:
    def __init__(self, name):
        self.name = name
        self.children = []

class Child:
    def __init__(self, name, parent):
        self.name = name
        self.parent = weakref.ref(parent)  # 弱引用，不增加引用计数

p = Parent("家庭")
c = Child("孩子", p)
p.children.append(c)

# p 引用 children → children 引用 c → c.parent 弱引用 p
# 没有形成强引用环，gc 可以正常回收

# 使用弱引用时需要通过 () 调用解引用
parent = c.parent()
if parent is not None:
    print(f"父对象仍在: {parent.name}")
else:
    print("父对象已被回收")

# 也可以用 weakref.proxy 创建透明代理
parent_proxy = weakref.proxy(p)
print(parent_proxy.name)  # "家庭" — 使用方式与原始对象一致

六、性能调优

在大多数 Python 应用中，默认的 gc 配置已经足够好。但在某些特殊场景下——比如长时间运行的服务器、嵌入式 Python、高吞吐量数据处理——调优 gc 参数可以带来可观的性能提升。合理的调优方向包括调整各代的阈值、在特定时段禁用 gc，以及监控回收开销。

调整阈值（set_threshold）

gc.set_threshold(threshold0[, threshold1[, threshold2]]) 用于设置各代的回收阈值。调整原则如下：

增大阈值0：减少第 0 代回收频率，适合创建大量临时对象的场景，降低 GC 开销但也增加了内存峰值。
减小阈值0：提高响应速度，适合对内存敏感的应用，更快回收临时对象。
增大阈值1/阈值2：减少老年代回收频率，适合长期运行的服务，减少"全停顿"（stop-the-world）时间。

import gc

# 查看当前阈值
print(gc.get_threshold())  # (700, 10, 10)

# 场景1：数据分析/批处理 — 创建大量临时对象
# 降低第0代阈值，更频繁地回收临时对象
gc.set_threshold(500, 10, 10)

# 场景2：长时间运行的 Web 服务
# 增大第0代阈值，减少回收频率；增大老年代阈值，避免全 GC
gc.set_threshold(2000, 20, 20)

# 场景3：内存极度紧张
# 激进回收
gc.set_threshold(100, 5, 5)

# 恢复默认
gc.set_threshold(700, 10, 10)

禁用自动回收

在某些情况下，禁用自动 gc 并在"安全时刻"手动回收可以获得更好的确定性：

import gc

class HeavyProcessor:
    """批量处理器：在任务期间禁用 gc，任务结束后手动回收"""
    def __init__(self, batch_size=1000):
        self.batch_size = batch_size

    def process(self, items):
        # 禁用自动 gc
        was_enabled = gc.isenabled()
        if was_enabled:
            gc.disable()

        try:
            for i, item in enumerate(items):
                # 处理数据...
                _ = [{"id": j, "data": str(j) * 100} for j in range(100)]

                # 每处理完一批，手动回收一次
                if (i + 1) % self.batch_size == 0:
                    gc.collect(0)  # 只回收年轻代，开销小
        finally:
            # 恢复原始状态
            if was_enabled:
                gc.enable()

        # 全部处理完后执行一次完全回收
        gc.collect()

# 使用
processor = HeavyProcessor()
processor.process(range(5000))

监控回收开销

调优前应该先测量当前的回收开销：

import gc
import time

def measure_gc_overhead(iterations=100):
    """测量 gc.collect 的执行时间"""
    total_time = 0
    for _ in range(iterations):
        # 创建一些垃圾
        for _ in range(1000):
            _ = [{} for __ in range(10)]

        start = time.perf_counter()
        gc.collect()
        total_time += time.perf_counter() - start

    avg_ms = (total_time / iterations) * 1000
    print(f"平均每次 gc.collect() 耗时: {avg_ms:.3f} ms")

    # 查看各代统计
    stats = gc.get_stats()
    for i, s in enumerate(stats):
        if s['collections'] > 0:
            avg_per_collection = s['collected'] / s['collections']
            print(f"第{i}代: 收集{s['collections']}次, "
                  f"平均每次回收{avg_per_collection:.1f}个对象")

measure_gc_overhead(10)

调优原则：不要盲目调优。先测量、再调整、最后验证效果。Web 应用通常适合增大阈值减少全 GC 频率；数据处理脚本适合使用更频繁的年轻代回收；实时系统可能需要在关键路径上临时禁用 gc。每次只调整一个参数，对比前后的吞吐量和内存占用变化。

七、核心总结

gc 模块的核心价值在于弥补引用计数无法处理循环引用的短板，为 Python 程序的内存安全提供最后一道防线。

知识体系速览

维度	核心要点
内存管理架构	引用计数（主）+ 分代回收（辅），两者协同工作
分代策略	三代（0/1/2），年轻代频繁收集、老年代低频收集
默认阈值	(700, 10, 10) — 700 个新对象触发第 0 代收集
回收控制	enable/disable，collect(generation) 手动触发
调试工具	get_objects / get_stats / get_referrers / get_referents / set_debug
循环引用	gc 自动检测循环引用孤岛；__del__ 可能导致对象不可回收进入 garbage 列表
弱引用	weakref.ref / weakref.proxy 打破循环引用，不增加引用计数
性能调优	调整阈值、临时禁用 gc、在安全点手动 collect

最佳实践清单

默认配置适用大多数场景——不需要一上来就调优 gc
优先用 weakref 打破循环引用，而不是依赖 gc 事后清理
避免在容器类中定义 __del__，改用上下文管理器或弱引用回调
定期检查 gc.get_stats() 中 uncollectable 的数量，持续增长说明有问题
内存泄漏排查三步法：先用 gc.get_objects() 全员扫描，再用 gc.get_referrers() 定位引用源头，最后检查是否存在意外的全局缓存或闭包引用
测试时开启 gc.set_debug(gc.DEBUG_LEAK)，可以在开发阶段就发现潜在的循环引用问题
在高并发服务中谨慎执行 gc.collect()，它会暂停所有线程（stop-the-world），应选择在请求低峰期执行

理解 gc 模块的本质，就是理解 Python 在"自动内存管理"和"可预测性能"之间的权衡。引用计数提供了确定性，分代回收提供了处理极端情况的兜底。掌握 gc 的机制与工具，不仅能写出更健壮的程序，更能在面对内存泄漏时精准定位、快速解决。