gc.collect() 不能立刻回收所有对象，仅回收当前不可达对象，不处理有外部引用的循环引用，也不立即执行__del__方法，返回值为本次回收的不可达对象数量。
gc.collect() 能不能立刻回收所有对象
不能。调用 gc.collect() 会启动一次完整的垃圾回收周期，但它只回收当前可判定为不可达的对象，不会强制释放被循环引用但仍有外部引用的对象，也不会触发 __del__ 方法的立即执行（该方法可能延迟到解释器退出前）。常见误解是“调用了就清空了内存”，实际效果取决于引用图状态和 gc 的代际策略。
实操建议：
- 默认不带参数时，
gc.collect()清理第 0 代；传入0、1、2可指定代（Python 3 默认三代理论） - 想尽可能回收，用
gc.collect(2)，但代价高，别在热路径频繁调用 - 回收返回值是本次清理出的不可达对象数量，可用于简单验证是否真有对象被回收：
print(gc.collect())
为什么 gc.enable() / gc.disable() 后对象还在内存里
启用或禁用 gc 只影响自动触发机制，不影响已有对象的生命周期。禁用后，对象仍靠引用计数存活；启用后，也不会回溯清理之前积累的循环引用——除非你手动调用 gc.collect()。
典型误用场景：
立即学习“Python免费学习笔记（深入）”；
librosa Python 音频与音乐分析库
下载
librosa 是一个用于音频和音乐分析的 Python 库。它提供了特征提取、频谱分析、节拍跟踪、起始检测和音频可视化的工具，基于 NumPy 和 SciPy 构建，用于科学音频计算。
- 在关键性能段用
gc.disable()暂停自动回收，但忘了在结尾gc.enable()+gc.collect()，导致后续大量循环引用堆积 - 误以为
gc.disable()能让对象“跳过 GC”，其实只是跳过自动扫描，引用计数该减还是减，del obj依然有效 - 多线程中调用
gc.disable()只影响当前线程，其他线程的自动回收照常运行（CPython 中 gc 是全局状态，但线程安全由 GIL 保证）
怎么查哪些对象卡在 gc.garbage 里
gc.garbage 是一个列表，只在 gc 循环检测到无法处理的带 __del__ 方法的循环引用时才被填充（且需提前设置 gc.set_debug(gc.DEBUG_SAVEALL)）。它不是“待回收队列”，而是“放弃治疗名单”——这些对象因析构逻辑不确定，被隔离出来防止无限递归。
调试步骤：
- 先开启调试：
gc.set_debug(gc.DEBUG_SAVEALL | gc.DEBUG_UNCOLLECTABLE) - 运行疑似泄露代码段
- 检查
gc.garbage长度和内容：print(len(gc.garbage)); print([type(x).__name__ for x in gc.garbage[:5]]) - 注意：一旦对象进了
gc.garbage，必须手动从列表中移除并显式del，否则永不释放
gc.get_objects() 查出来的对象为什么和内存占用对不上
gc.get_objects() 只返回当前被 gc 跟踪的对象（即参与循环引用检测的对象），不包括纯引用计数管理的对象（如大多数整数、字符串、小元组）。所以它看到的是“GC 管理池”，不是全部内存。
更准的排查方式：
- 用
gc.get_count()看三代理数，突然增长说明某代对象堆积，比如第 0 代激增常意味着短命对象没及时释放 - 结合
objgraph库：objgraph.show_most_common_types(limit=20)能列出高频类型，比 rawgc.get_objects()更实用 -
gc.get_referrers(obj)和gc.get_referents(obj)是定位引用链的关键，但慎用——传入内置类型（如int）可能返回巨量结果甚至卡死
真正难的从来不是触发回收，而是确认“谁在强引用着本该死掉的对象”。盯着 gc.garbage 或 gc.get_objects() 看数字，不如用 gc.get_referrers() 顺藤摸瓜查三层引用链。
