做 Python 服务维护的这几年，我最怕听到的一句话不是“挂了”，而是“内存又涨了”。内存泄漏不像崩溃那样会立刻触发报警，它更像慢性病——刚上线时一切正常，跑十几个小时后内存缓慢攀升，等到 OOM 的时候，现场基本已经没救了。更让人头大的是，Python 的内存管理机制让它比 C/C++ 更容易掩盖真相：你用top看到 RSS 涨了，对象也确实删了，可内存就是不降下来。这篇文章是我在实际排障过程中反复验证过的一套方法论，核心就两点：用tracemalloc把泄漏点从分配栈里挖出来，再用对象生命周期治理的思路阻断泄漏源头。如果你正被“内存缓慢增长、怎么都定位不到归属”的问题折磨，这篇文章可以直接当成排查清单来对照。
1. 为什么说 Python 的内存泄漏比 C/C++ 更难定位
先说一个容易被误解的前提：Python 默认使用引用计数管理对象，理论上一旦一个对象没有引用，它就会被立即回收。很多朋友就是被“引用计数”这四个字误导，认为 Python 不可能泄漏，内存涨一定属于正常扩张。实际上，CPython 的内存管理分两层，这两层加在一起，产生了至少三种让你误判的情况。
1.1 引用计数回收的直观误区
引用计数确实能在多数情况下自动释放对象，但它解决不了循环引用。A 持有 B，B 又持有 A，A 和 B 的引用计数都不为 0，垃圾回收器如果不介入，这对对象就永远留在内存里。GC 能做回收，但两次回收之间有一个周期，默认阈值是每分配 700 个对象触发一次“代际检查”，也就是说即使存在循环引用，也不是立刻被回收的，会有一个滞后窗口。生产环境中常见的现象是内存呈锯齿状波动，一个高峰期过去后应该下降却没能完全降下来，反复几次之后基线整体抬高。
更麻烦的是，循环引用和__del__一起出现时，GC 会把它们视为不可回收对象，直接丢进gc.garbage列表，也就是说对象虽然在逻辑上不可达了，但内存依然被占着，而且 GC 不会再碰它了。这个问题在老代码里很常见，比如旧式的异步任务里两个管理器互相持有对方，只要其中一方定义了__del__，就基本宣告泄漏。
1.2 内存“不归还”不等于泄漏：RSS 的两种状态
第二个误判来自 CPython 的分配器。CPython 从操作系统申请内存之后，会维护一组 arena 缓存，用于小块对象的内存分配。当一个对象被释放时，内存并不会马上归还给操作系统，而是留在这些缓存里，供后续新对象复用。这意味着你用top看到 RSS 不降，不代表对象泄漏了；同理，RSS 上涨，也不代表一定有 Python 对象变多。
我自己第一次排查时犯过这个错：某个服务 RSS 涨到 4GB 不下来，我以为是请求上下文没释放，结果用gc.get_objects()一统计，活跃对象根本没增长，后来才发现是某个第三方库把大量 Numpy 数组缓存住了。这里有个比较实用的判定方式：先看gc.get_objects()返回的对象数量增长曲线，再看 tracemalloc 统计的当前分配量，两个指标都不涨而 RSS 在涨，那基本可以判定问题出在 Python 对象分配器之外，比如原生扩展模块直接申请的内存，或者 pymalloc 的 arena 缓存堆积。
1.3 “泄漏”的真正判定标准
那么到底什么才算 Python 内存泄漏？结合我的经验，判定标准应该是这样的：经过了一段时间和若干轮业务请求之后，存活对象数量或 tracemalloc 统计的现存量持续增大，并且垃圾回收之后仍无法回落到初始水平。这里的“初始水平”应该是你做了gc.collect()、tracemalloc.reset_peak()之后获得的一个稳定基线，而不是进程刚启动时的瞬间值。
我平时会用一个很小的观测脚本，记录三类数据：RSS、当前分配量、可收集对象计数（即gc.get_objects()的个数）。把它们画成曲线，如果“当前分配量”这条线呈现单调上升而不是锯齿状回归，就可以正式进入泄漏排查流程了。
| 现象 | 可能结论 | 下一步动作 |
|---|---|---|
| RSS 上涨，Python 对象数同步上涨 | Python 对象在持续积累 | 用 tracemalloc 快照对比定位分配栈 |
| RSS 上涨，Python 对象数不变 | 外部原生模块内存占用 | 用系统级工具排查原生内存 |
| RSS 下跌后仍高于基线 | arena 缓存尚未释放 | 关注对象数是否回到基线，可暂时观察 |
| tracemalloc 现存量上涨且多次 GC 后不回 | 真泄漏 | 需要定位到具体代码路径 |
2. 泄漏根因分类：不只是循环引用
很多教程一提到内存泄漏就上来讲循环引用，这其实把问题带偏了。从我见过的线上案例来看，循环引用占比没有想象中那么高，更多泄漏出在“生命周期边界没划清楚”上。下面我把常见根因按频率和数据特征拆开说。
2.1 循环引用：经典但未必是最常见的
循环引用最典型的代码长这样：
class Manager: def __init__(self): self.worker = Worker(self) class Worker: def __init__(self, manager): self.manager = manager这种互相持有如果发生在短命对象之间，还不太要紧，因为 GC 每隔若干次分配就会扫描一次，能把它回收掉。但如果这些对象的数量很大，比如你每秒创建上千个这样的双向持有对象，GC 的扫描成本会跟着上涨，回收滞后窗口也会被放大。真正的隐患还是那个组合——循环引用加__del__：
class A: def __init__(self, b): self.b = b def __del__(self): # 有些资源清理逻辑 pass class B: def __init__(self, a): self.a = a a = A(None) b = B(a) a.b = b # a 和 b 形成循环引用，且 A 定义了 __del__，GC 无法处理 del a, b # 它们会留在 gc.garbage 中，再也不被清理对于已经上线的老代码，遇到这种问题没有捷径，要么重建引用方向，要么把__del__干掉换成显式清理方法。但在新代码里，原则很简单：尽量别定义__del__，如果一定要做资源清理，用weakref.finalize或上下文管理器都比它可靠。
2.2 隐式全局引用：模块缓存与单例
这是我现实中见得最多的一种。最常见的场景是模块里有一个全局字典或lru_cache，它本意是缓存计算结果，但缓存键是用户 ID、订单号、批次号这类“取值空间无限”的数据。随着业务运行，缓存条目只增不减，内存就一路涨上去。
# 问题代码：全局缓存无上限 _result_cache = {} def get_user_profile(user_id): key = f"profile_{user_id}" if key not in _result_cache: _result_cache[key] = query_db(user_id) return _result_cache[key]稍微包装一下，问题就更隐蔽了，比如缓存里存的不只是标量，而是一整个响应对象、一帧渲染结果、一个大 DataFrame。你以为只有几十个缓存条目，实际上每个条目背后拖着几十 MB 的数据。这类泄漏的特征是：内存增长量和业务请求量线性相关，清理缓存后内存立刻回落。所以排查时如果发现跟请求量强相关，先查所有全局可变容器。
2.3 回调、闭包和事件监听：失控的生命周期
第三类泄漏在“半异步半同步”的代码里特别多。你注册了一个回调函数，回调函数本身不大，但它作为闭包把外围的一堆变量一起捕获了。比如下面这种：
def on_event(event): # 事件处理逻辑 pass # 某个长生命周期管理器持有回调 manager.add_listener(on_event) # 事件处理函数可能捕获了请求上下文或其他临时对象事件监听器的生命周期往往比业务对象长得多，对象已经处理完、理论上应该被回收，但监听器还挂在管理器上，它的生命周期被无限拉长。还有一种变体是线程：把每请求产生的临时线程放进全局 list 里的陷阱并不少见，list 一直引用着已经结束的线程对象，线程内部持有的大块数据也就一直留在内存里。这类泄漏用 tracemalloc 排查时有个典型特征——增长集中在“注册回调”“append 线程”那几行代码上。
2.4 快速定位根因的对照表
| 根因 | 典型数据特征 | 初检手段 | 治理方向 |
|---|---|---|---|
循环引用 +__del__ | gc.garbage非空，对象数锯齿上升 | 过滤gc.garbage统计类型 | 消除__del__，显式清理 |
| 无界缓存 | 内存与请求量/数据量线性相关 | 审查模块级全局字典 | 设置容量上限，用弱引用 |
| 回调/闭包持有 | tracemalloc 中大量分配集中在调用注册处 | 快照对比看回调链路 | 取消订阅、弱引用 |
| 线程/连接池失控 | 活跃线程数或连接数同步上涨 | 打印threading.enumerate() | 显式生命周期管理 |
3. tracemalloc 实战：从分配总量到调用栈定位
tracemalloc 是 CPython 官方自带的追踪模块，它最大的价值不是告诉你“内存用了多少”，而是能告诉你“这些内存是在哪个调用栈上分配的”。这一个能力，基本就能把排查时间从几天压缩到几小时。
3.1 基础用法：启动跟踪与看总量
先把最基础的两行代码记住：
import tracemalloc tracemalloc.start(25) print(tracemalloc.get_traced_memory())start(25)里的 25 是帧层数。默认是 1，也就是只记录分配代码所在的当前函数，你最好把它设得大一点，否则看到的分配栈太短，不好定位到业务入口。get_traced_memory()返回一个元组，第一项是当前分配的内存总量，第二项是运行以来的峰值。启动之后，程序里所有 Python 对象的分配都会被记录。
前提是 tracemalloc 必须在内存增长之前启动。如果你的进程已经跑了一星期才想起开 tracemalloc，那是拿不到历史数据的，只能重新部署、从启动阶段开始跟踪。所以在排查泄漏时，最标准的做法是：发布一个启动时自动开启 tracemalloc 的临时版本，运行观测周期 24 到 48 小时，采集首尾两个快照。
3.2 快照对比：找到两个时间点之间增长的那部分
真正定位泄漏靠的是快照对比，不是看总量。具体做法是：
# 运行开始一段时间后记录基准快照 snapshot_before = tracemalloc.take_snapshot() # ... 持续运行业务逻辑 ... # 结束阶段记录最新快照 snapshot_after = tracemalloc.take_snapshot() # 对比两个快照，按代码行号聚合 top_stats = snapshot_after.compare_to(snapshot_before, "lineno") print("====== 增长最多的 20 处分配 ======") for stat in list(top_stats)[:20]: if stat.size_diff > 0: print(f"{stat.traceback.format()[0]}") print(f" 内存增长: {stat.size_diff / 1024:.1f} KiB, 分配次数增长: {stat.count_diff}")这里有一个很关键的小细节：compare_to的第二个参数，我常用"lineno"，它会把分配栈按文件和行号聚合，方便看到增长集中在哪个函数。如果你想看看某个具体文件名下面的所有分配，可以用filter_traces先过滤：
from tracemalloc import Filter snapshot_after = snapshot_after.filter_traces( filters=(Filter(True, "*my_service*"),), )Filter(True, pattern)表示保留匹配的文件路径，Filter(False, pattern)表示排除。还可以直接对整个快照做snapshot.statistics("lineno")，拿到当前存量而不是增量，这在你怀疑某个模块是“无界缓存”时很有用，先看排名前几的分配点，再顺着代码找到缓存容器。
3.3 线上使用 tracemalloc 的三个注意点
tracemalloc 不是零成本的。start()之后，每一次分配都要记录调用栈，会带来明显的 CPU 和内存开销，官方文档给的经验数据是内存开销大约 1 到 2 倍。所以生产环境不要长期开着，建议走临时观测版本，观测完就关。
第二个注意点是线程。tracemalloc 会记录所有 Python 线程的分配，但不会记录非 Python 原生内存的分配，特别是 C 扩展直接通过malloc申请的内存。你如果怀疑原生扩展泄漏，它帮不上忙，得用valgrind或者heaptrack这类系统级工具配合排查。这一点对用 Numpy、PyTorch 这类库的场景尤其重要，之前一个案例里，Python 侧内存完全没有增长，实际上泄漏的是某个 C 扩展里缓存下来的原生内存，tracemalloc 一点都看不到。
第三个注意点跟快照数据量有关。在大型服务上，24 小时里产生的分配栈可能有上百万条，直接compare_to全部打印会让终端崩溃。建议先启动后在前几分钟采集一个短周期快照，确认服务本身能承受跟踪开销，再拉长观测窗口。如果快照太大，用上面说到的filter_traces把无关模块划掉，只保留自己服务的路径。
3.4 配合 GC 模块和 objgraph 一起看
有时候 tracemalloc 已经把范围缩小到一个函数了，但函数内部的缓存字典是哪个对象，还需要看引用关系。我的习惯是先用gc.get_objects()拿到全部存活对象，再按类型做计数：
import gc from collections import Counter objects = gc.get_objects() counter = Counter(type(obj).__name__ for obj in objects) print(counter.most_common(20))如果某个自定义类的实例数量异常多，说明它们被某些长周期的容器引用着。此时配合objgraph（第三方库）能画出引用链：
pip install objgraphimport objgraph import my_suspect_class objgraph.show_backrefs( objgraph.find_backref_chain(my_suspect_class.Suspect(), max_depth=8), filename="backrefs.png" )max_depth控制往上追溯的层数，引用链越深越可疑。看到引用图之后，基本就能判断是哪个全局容器“扣住”了对象不放。
4. 对象生命周期治理：让该释放的早些释放
定位到泄漏点只是治标，真正治本的是要让对象的生命周期“与业务需求一致”，该释放时就释放。我总结下来，治理方案可以归成四类。
4.1 用弱引用解除长生命周期容器的“控制”
弱引用是治理缓存和回调类泄漏最核心的手段。weakref模块的WeakValueDictionary、WeakSet这类容器，存放其中的对象不增加引用计数，当业务不再持有该对象时，即使它还在缓存字典里，也会被正常回收，对应的键会从字典里自动移除。
上面那个全局缓存的例子，改成弱引用版：
import weakref # 注意：值必须是可以弱引用的对象，普通 str、int、部分内建容器不行 _profile_cache = weakref.WeakValueDictionary() def get_user_profile(user_id): key = f"profile_{user_id}" profile = _profile_cache.get(key) if profile is None: profile = query_db(user_id) _profile_cache[key] = profile return profile注意两个限制：WeakValueDictionary的值必须是可以弱引用的对象，普通str、int、list的某些内建类型不行；另外，当对象在字典里“活着”时，它会回调通知字典移除条目，这会有一点性能开销。对性能敏感的核心链路，设计缓存时可以做成“有界 LRU + 定期清理”，本质上还是把缓存条目的生命周期限制在可控范围内。
对于事件订阅和监听器，也是一样的逻辑：能挂弱引用就尽量挂，或者至少在对象销毁时显式取消订阅。很多框架的disconnect方法就是为这个而生的，只是开发者常常忘了调用。
4.2 上下文管理器比__del__可靠得多
我前面反复提到别用__del__，这里展开说一下。__del__的调用时机模糊，它由对象的即时释放或 GC 触发，可能在任意时刻、任意线程里执行；一旦对象处于循环引用中，它甚至可能永远不被调用。更麻烦的是，解释器关闭过程中__del__还可能访问到已经不存在的模块状态，直接抛异常。
with上下文管理器把“创建—使用—释放”这个生命周期显式化，是治理资源泄漏最好的工具。如果业务对象的生命周期是明确的，比如一次会话、一次请求、一次文件处理，就把它设计成可上下文管理：
class RequestScope: def __init__(self, request_id): self.request_id = request_id self.buffer = [] def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): self.buffer.clear() # 再加上显式的资源回收/反注册逻辑 release(self.request_id) # 使用处： with RequestScope(req_id) as scope: pass写成这样之后，生命周期边界在代码层面看得清清楚楚：出了with块，要么正常清理，要么异常清理，没有第三种可能。对于实在需要用回调方式做清理的场景，weakref.finalize比__del__靠谱，它会把清理动作注册成可调用的对象，在对象被回收时执行。
4.3 关键节点引入 GC 观测，别让 GC 全自动运行
很多团队上线后根本不看 GC 的运作情况，等到出问题才手忙脚乱。这套机制其实是可以观测、可以调试的：
import gc # 打开调试开关，输出 GC 统计，保存可回收对象并打印不可回收对象细节 gc.set_debug(gc.DEBUG_LEAK) # 手动执行一次完整回收，并打印各级回收数量 print(gc.collect())DEBUG_LEAK实际是DEBUG_STATS、DEBUG_SAVEALL、DEBUG_OBJECTS和DEBUG_UNCOLLECTABLE的组合：把所有可回收对象保存到gc.garbage，同时输出每一代的统计信息。日志里如果反复出现大量相同类型的对象，大概率就是泄漏。日志本身会比较吵，定位结束后记得用gc.set_debug(0)关掉。
我常用的另一个稳定化手段是gc.freeze()：把程序启动阶段创建的、确定不会释放的基础对象“冻结”掉，之后的 GC 扫描就不需要反复检查它们，能显著减少 GC 开销，也能让gc.get_objects()这类统计更聚焦于业务阶段创建的对象。注意freeze只对调用之后的 GC 生效，而且被冻结对象不会被回收，所以只适合冻结真正的纯启动期对象。
4.4 代码层面的生命周期约定
积累了多个案例之后，我在团队里定了几条不成文的约定，在这里分享给你：
- 模块级只能放“配置型”不可变对象，禁止出现无上限的模块级缓存字典；缓存必须显式指定容量上限和淘汰策略。
- 所有一次性任务、请求、会话对象，实现上下文管理器或明确提供
close()，并在使用处收尾，禁止只靠 GC 兜底。 - 回调注册时先问一句：监听器本身的生命周期是否小于被监听对象？拿不准，就改用弱引用。
- 大对象（图片、DataFrame、响应内容）不做短期缓存，即使做，也要等业务结束后立即释放引用，不要让它被全局容器顺手接住。
5. 一次完整的泄漏排查实录：从现象到修复
前面讲了很多理论和方法，最后用一个我自己做过的完整案例串起来，方便你照着这个思路动手。
5.1 现象与初判：RSS 天天涨，Python 内部却没明显异常
背景是个内部任务调度服务，每处理一批任务要调用外部接口，接口返回体比较大，大概几百 KB。上线后第一周正常，第二周开始内存每天涨 1GB 多，到了第七天直接 OOM 重启。起初我怀疑是任务队列积压，但查了队列长度、活跃线程数都很平稳。
用gc.get_objects()看对象总数，虽然有所增长，但幅度很小，跟上千 MB 的 RSS 增量完全对不上。这个细节很关键：说明多出来的内存很可能不是“大量小对象”，而是“少数大对象”在不断积累。由于大对象通常是字符串、字节串、容器类对象，于是我把怀疑目标锁定到外部接口的响应体缓存上。
5.2 用 tracemalloc 定位：增长集中在全局响应缓存
我部署了一个临时版本，启动时加上tracemalloc.start(30)，跑了一天，取两次快照对比，很快看到增长贡献最大的前几名：
.../http_client.py:258 size=+1.21 GB count=+43000 .../task_worker.py:114 size=+180.5 MB count=+500第一处调用栈指向http_client.py里的一个_response_cache字典，赋值语句每次把response.text写进去。顺藤摸瓜找到调用方，原来是去年某个中间版本为了给重复请求做缓存，把“响应文本按请求参数拼成 key 存进模块级字典”，但线上参数几乎每个任务都不一样，缓存没有任何命中率，反而成了不断吞内存的黑洞。
5.3 修复方案与效果验证：弱引用替代全局强引用
修复不复杂，改两处：一是把_response_cache从普通 dict 改成weakref.WeakValueDictionary()，当任务执行完、响应对象不再被业务变量引用时，缓存条目自动失效；二是给真正需要缓存的核心接口（确实会重复调到的那几个）单独加一层有容量上限的 LRU 缓存。
改动上线后再观察 72 小时，内存曲线从单调上升变成了扁平化的锯齿状，GC 后能稳定回到基线。第三天做了一次压测，确认峰值内存只有原来的三分之一左右。
这里有个容易踩的坑需要单独提醒：WeakValueDictionary 本身不是银弹，如果业务代码里对同一个响应对象已经有全局强引用，换成弱引用也白搭。修复时先看清楚引用是“谁持有”，再决定是否只用弱引用缓解。
5.4 复盘：三个环节堵住同类问题
事后我拉了个简单的复盘，把问题拆成三个环节：
- 监控环节：内存类指标不能只看 RSS，还要有存活对象数和 tracemalloc 当前分配量的趋势曲线，让“内存涨了”变成一个可定位的问题描述。
- 代码环节：全局缓存的创建必须走统一封装，不允许直接在业务模块里手写全局字典；缓存条目的生命周期必须能回答“它什么时候被淘汰”。
- 发布环节：做性能测试时，除了耗时压测，还要加 24 小时以上的长期运行测试，用 tracemalloc 做首尾快照对比，专门观察内存增量。这一条尤其适合跑批类服务，很多泄漏都是长期运行测试才暴露的。
最后讲点我个人实践里的体会。排查 Python 内存泄漏，技术手段其实很固定：先看现象，再确认是不是真泄漏，然后开着 tracemalloc 跑一轮观测期，对比快照拿到分配栈，最后顺着引用链找到持有者。真正让排查变难受的往往不是工具不会用，而是对“对象生命周期”没有概念——不知道谁会持有它、它该在什么时候消失。把治理思路从“等 GC 帮我收”调整成“我明确控制它的生命周期”之后，这类问题会少掉一大半。你现在服务里的那个全局缓存，或者那个事件监听器，可能就是下一个泄漏点，趁它还早，按上面的方法自查一遍，比等 OOM 时再抢救成本低得多。
