凌晨两点，监控告警把我吵醒——线上服务内存占用97%。
我看了一眼代码，每个对象用完都设了None，引用计数应该归零了啊……怎么内存就是不肯还？
这感觉就像——你把房间的灯一盏盏关了，电表还在疯转。哪来的暗耗？
后来我才搞明白：房间里有两个灯，互相给对方供着电，你关哪盏都关不掉。
这就是Python引用循环。今天就把这个坑，从头到尾翻一遍。
引用计数：那个靠谱但不完美的管家
Python内存管理，主力是引用计数。简单粗暴：一个对象被几个人指着，计数器就记几。没人指了，立刻回收。
import sysa = [1, 2, 3]print(sys.getrefcount(a)) # 2（a本身 + getrefcount的参数引用）del a # 计数归零，内存释放
大部分时候，这位管家靠谱得很。对象一没引用，秒回收，不用等，不用猜。
但它有个致命盲区。
两个灯互相供电
来看这段代码：
class Node: def __init__(self): self.friend = Nonea = Node()b = Node()a.friend = b # a引用bb.friend = a # b引用adel adel b
没有。
a和b的引用计数都没归零——因为它们互相指着对方。你删了变量名，但对象之间的引用链还在。管家看了一眼计数器：嗯，还大于0，不能收。
这就是引用循环。A引用B，B引用A，形成一个死结。引用计数拿它毫无办法。
回到那个比喻：两个灯互相供电，你关了开关，灯还亮着。电从对方那来回流，根本断不掉。
而我在凌晨两点遇到的，正是这种死结。只不过当时的代码，藏得更深。
gc模块：专门来拆死结的
Python当然知道引用计数有这个缺陷，所以配了个副手：gc模块，用标记-清除算法专门处理引用循环。
原理不复杂：从根对象（全局变量、栈上的局部变量等）出发，沿引用链遍历，能到达的对象标记为"活"的，到达不了的，那就是循环垃圾，收掉。
还有个分代回收机制。对象活得越久，越不容易是垃圾，gc就少检查它。Python把对象分三代，新生代检查最频繁，老生代偶尔扫一次。
import gcprint(gc.get_threshold()) # (700, 10, 5)
手动触发也行：
gc.collect() # 返回回收的对象数量
但这里有个坑，gc也不是万能的。
真凶：__del__方法阻止回收
凌晨两点的那个bug，我花了三个通宵才定位到。说来话长……当时项目里有个连接池类，长这样：
class Connection: def __init__(self, pool): self.pool = pool # 引用连接池 self.sock = create_socket() def __del__(self): self.pool.return_connection(self) # 问题在这！class Pool: def __init__(self): self.connections = [] def get_connection(self): conn = Connection(self) self.connections.append(conn) # 池引用连接 return conn
Connection引用Pool，Pool的connections列表引用Connection——循环了。但gc本来能处理循环，对吧？
问题出在__del__。
当gc检测到循环垃圾时，它会检查：这个循环里有没有对象定义了__del__方法？如果有，gc不敢回收。因为它不知道__del__里的代码会不会引用循环中的其他对象——万一回收了，__del__访问到已释放的内存，直接段错误。
所以gc的选择是：宁可泄漏，不可崩溃。
Connection.__del__里调了self.pool.return_connection(self)，正好引用了循环中的另一个对象。gc一看，这循环里有__del__，__del__还引用了循环伙伴，放弃回收。
内存就这么一点一点泄漏了。电表疯转，管家束手无策，副手也犯了怂。
破局：weakref和手动断链
解决引用循环，思路很简单：打破循环。
方案一：弱引用
弱引用不增加引用计数。被弱引用指着的对象，如果没人强引用了，照样回收。
import weakrefclass Connection: def __init__(self, pool): self.pool = weakref.ref(pool) # 弱引用，不增加计数 self.sock = create_socket() def __del__(self): pool = self.pool() # 取出弱引用指向的对象 if pool: # 对象可能已经被回收了 pool.return_connection(self)
用weakref.ref()替代直接引用，循环就断了。a不再"强供电"给b，b没了强引用，计数归零，灯终于能关了。
方案二：手动断链
更直接的做法——在对象不再需要时，主动断开循环引用：
class Connection: def close(self): self.sock.close() self.pool = None # 主动断开对Pool的引用
没有银弹，但weakref在大多数场景下更优雅。
侦探工具箱：怎么找到循环引用
实际项目中，循环引用往往藏得很深。几个工具帮了大忙。
gc.get_referrers() / gc.get_referents()
查看谁引用了一个对象，以及一个对象引用了谁：
import gcobj = some_objectprint(gc.get_referrers(obj))print(gc.get_referents(obj))
这俩函数相当于"顺藤摸瓜"——沿引用链上下游搜。不过返回结果比较原始，需要自己筛选。
objgraph：可视化引用图
这个更直观，直接画图：
import objgraphobjgraph.show_backrefs(obj, max_depth=5, filename='refs.png')
它会生成一张对象引用关系图，循环一目了然。当年我就是靠这个工具，才在那一坨代码里找到Connection和Pool的互相引用——图上两个节点之间的双向箭头，刺眼得很。
tracemalloc：追踪内存分配
如果还不确定哪里泄漏了，用tracemalloc看内存分配的热点：
import tracemalloctracemalloc.start()snapshot = tracemalloc.take_snapshot()top_stats = snapshot.statistics('lineno')for stat in top_stats[:10]: print(stat)
哪种对象分配最多、哪行代码吃内存，一清二楚。
gc调优：让回收别太卡
gc不是免费的。每次gc.collect()都会暂停程序——"Stop the World"，把所有线程冻住，然后慢慢扫描。
对于延迟敏感的服务，这个停顿能感受到。
几个调优思路：
调阈值：默认(700, 10, 5)偏保守。如果你的服务对象创建频繁但寿命短，可以适当提高0代阈值，减少触发频率：
gc.set_threshold(2000, 15, 10)
手动控制：在业务低峰期手动触发gc.collect()，避免高峰期被自动gc卡住。
关掉自动gc：极端场景下，可以gc.disable()完全关闭自动回收，自己在合适的时机手动collect。但风险自负——忘了收就泄漏。
禁用__del__：这是最根本的——能不用__del__就别用。用上下文管理器（with语句）替代析构逻辑，主动释放资源，比靠__del__靠谱得多。
2026年的新变量：free-threading
今年Python社区最大的变化，是3.13正式引入的free-threading模式（no-GIL）。
这对gc有什么影响？
影响不小。GIL时代，gc运行时所有线程本来就被锁着，停顿是"理所当然"的。但free-threading下，多个线程真正并行，gc要"Stop the World"就得同时暂停所有线程——这比以前难多了，停顿时间也可能更长。
CPython目前用的是一种安全的折中方案：gc时短暂暂停所有线程，扫描完毕再恢复。但这对延迟敏感的并发服务来说，是个新挑战。
目前社区的讨论方向包括：增量式gc（把一次大扫描拆成多次小扫描）、并发gc（gc线程和应用线程部分并行）。但都还在实验阶段。
如果你今年在试free-threading，建议关注一下gc停顿的指标——可能比GIL模式下更明显。
回到那个凌晨
最后我的修复方案是：把Connection.__del__改成close()方法，用with语句管理生命周期，加上weakref断开循环引用。内存曲线终于平稳了。
部署上线那天，我在监控面板前盯了两个小时，内存占用像心电图一样平稳，再没往上飘过。
后来我养成了一个习惯：每次写互相引用的类，都会多想一秒——"这两个灯，会不会互相供着电？"
……说来也巧，上个月review同事代码，又看到一个__del__里调self.manager.xxx。我把这个故事讲给他听，他沉默了几秒，默默改成了close()方法。
10个月宝宝每天需要喝多少奶粉？
