那个深夜，我的Python程序偷偷把内存吃光了

凌晨两点，监控告警把我吵醒——线上服务内存占用97%。

我看了一眼代码，每个对象用完都设了None，引用计数应该归零了啊……怎么内存就是不肯还？

这感觉就像——你把房间的灯一盏盏关了，电表还在疯转。哪来的暗耗？

后来我才搞明白：房间里有两个灯，互相给对方供着电，你关哪盏都关不掉。

这就是Python引用循环。今天就把这个坑，从头到尾翻一遍。

---

引用计数：那个靠谱但不完美的管家

Python内存管理，主力是引用计数。简单粗暴：一个对象被几个人指着，计数器就记几。没人指了，立刻回收。

import sys a = [1, 2, 3] print(sys.getrefcount(a))  # 2（a本身 + getrefcount的参数引用） del a  # 计数归零，内存释放

大部分时候，这位管家靠谱得很。对象一没引用，秒回收，不用等，不用猜。

但它有个致命盲区。

两个灯互相供电

来看这段代码：

class Node:  def __init__(self):  self.friend = None  a = Node() b = Node() a.friend = b  # a引用b b.friend = a  # b引用a  del a del b

没有。

a和b的引用计数都没归零——因为它们互相指着对方。你删了变量名，但对象之间的引用链还在。管家看了一眼计数器：嗯，还大于0，不能收。

这就是引用循环。A引用B，B引用A，形成一个死结。引用计数拿它毫无办法。

回到那个比喻：两个灯互相供电，你关了开关，灯还亮着。电从对方那来回流，根本断不掉。

而我在凌晨两点遇到的，正是这种死结。只不过当时的代码，藏得更深。

---

gc模块：专门来拆死结的

Python当然知道引用计数有这个缺陷，所以配了个副手：gc模块，用标记-清除算法专门处理引用循环。

原理不复杂：从根对象（全局变量、栈上的局部变量等）出发，沿引用链遍历，能到达的对象标记为"活"的，到达不了的，那就是循环垃圾，收掉。

还有个分代回收机制。对象活得越久，越不容易是垃圾，gc就少检查它。Python把对象分三代，新生代检查最频繁，老生代偶尔扫一次。

import gc  print(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 weakref  class 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 gc  obj = some_object print(gc.get_referrers(obj)) print(gc.get_referents(obj))

这俩函数相当于"顺藤摸瓜"——沿引用链上下游搜。不过返回结果比较原始，需要自己筛选。

objgraph：可视化引用图

这个更直观，直接画图：

import objgraph  objgraph.show_backrefs(obj, max_depth=5, filename='refs.png')

它会生成一张对象引用关系图，循环一目了然。当年我就是靠这个工具，才在那一坨代码里找到Connection和Pool的互相引用——图上两个节点之间的双向箭头，刺眼得很。

tracemalloc：追踪内存分配

如果还不确定哪里泄漏了，用tracemalloc看内存分配的热点：

import tracemalloc  tracemalloc.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()方法。