很多写Python的朋友都有过这种经历线上服务跑了几天内存占用从几百MB一路涨到几个GB最后被运维盯上开会点名要看排查报告。我也遇到过而且不止一次。第一反应是加机器、重启进程但治标不治本。直到我开始认真啃Python内存管理机制搞明白引用计数、垃圾回收、gc模块之间的关系才真正学会用工具定位内存问题而不是靠玄学调参。这篇文章不是教科书式的原理复述而是把我踩过的坑、验证过的方法、以及如何用gc、objgraph、tracemalloc定位内存泄漏的完整链路一次写清楚。适合给正在被内存越跑越高MemoryError频繁出现折磨的开发者看也适合想系统理解Python内存的人。读完你可以直接拿里面的套路去排查自己的服务。1. 先看清内存从哪来Python里的“对象”到底放在哪里在理解引用计数之前首先要有一套内存分配的基本认知。Python里一切皆对象每个对象都对应一块内存而这块内存由Python运行时内部的私有堆private heap管理。CPython的实现中每个对象在创建时都会通过对象分配器拿到一个结构体。这个结构体是对象存在的基础它的头部至少包含两个关键信息引用计数和对象类型指针。引用计数被放在对象头里而不是散落在某个全局表中。这里我常用一个生活化类比每个Python对象就像一块挂在墙上的白板白板左上角写着一个数字表示有多少人正在使用这块白板。每次有人新建一个指向它的引用数字加一引用被销毁或放弃数字减一。当数字归零时白板就可以被摘下来清掉。这个数字就是引用计数摘下来这一步由内存分配器负责执行。你看到的每一个普通变量赋值、容器插入、函数传参本质上都在修改某块白板上的数字。有人会问为什么要把引用计数放在对象头里因为这样判断一个对象是否存活只需要读一个字段做一次原子增减操作不需要遍历堆上所有对象。这个设计在性能和简单性之间做了很好的权衡代价就是每个对象都要多一点内存额外开销也带来了后面要重点讲的循环引用缺陷。值得注意的是这种方案并不是Python语言规范强制要求的而是CPython的实现细节。PyPy等其他解释器就采用了完全不同的内存管理模型所以引用计数是Python的垃圾回收机制这个说法严格来说是不准确的更准确的表达是CPython用引用计数作为主要回收手段。1.1 Python对象的内存分配与回收入口Python在运行期会频繁申请和释放小块内存但如果每一次都直接操作系统调用性能会非常难看。所以CPython内部维护了层级化的内存池体系。小对象一般小于512字节会从私有内存池中快速分配大对象才走系统级别的内存分配。理解这点对性能调优很有用如果你在循环里频繁创建大量小对象内存池的复用效率就会成为隐形瓶颈如果你创建巨型列表或字典则更容易出现内存碎片。一个对象的生命周期大致可以分成四个阶段分配、引用、解除引用、回收。分配与回收由运行时管理引用和解除引用则是由你的代码、数据结构的操作等外部行为触发的。回收阶段又分两条路引用计数归零的对象会被立即回收没有被立即回收的容器对象则可能进入垃圾回收器的跟踪列表留待分代回收处理。这个概念是后续理解的基石。对于写C扩展的开发者这里的规则是生死线手动创建对象时必须自己管理引用计数宏该加加该减减。稍有不慎要么内存泄漏要么对象被提前释放导致悬空指针。我有一次在C扩展里漏掉了一次DECREF一个常驻队列就把内存吃掉了好几个GB事后查了三天才发现是某个循环里new出来的对象一直被续命。1.2 引用计数在什么时机发生变化说到时机这是面试里经常出现的问题也是排查问题时最需要抠的细节。以下场景会让引用计数加一将对象赋值给一个新变量比如 b a将对象作为参数传入函数注意函数内部的局部变量也持有一份引用把对象加入列表、字典、集合等容器通过global关键字或闭包在不同作用域中引用该对象。减一的场景对应为局部变量离开作用域对象从容器中移除使用del显式删除变量变量被重新赋值导致原来指向的对象失去一份引用。但要注意上述规则在CPython里并不是绝对的因为解释器存在多种引用计数优化。最典型的是小整数缓存、字符串驻留intern以及某些内部临时对象的借用引用。例如a 256 和 a 257 在CPython中的底层表现完全不同256属于小整数缓存范围通常是-5到256每次赋值拿到的都是同一个对象257则可能在每次运算时创建新的对象。这种细节会直接影响你对内存变化的判断尤其是你在写数值密集型计算时。还有一个常见的误解sys.getrefcount(obj)返回的计数不是你以为的那个值。它通常比实际外部引用数多1因为把当前调用栈传入参数这件事本身也会占用一个临时引用。所以拿这个接口做精确统计并不靠谱更适合用来观察引用计数的相对变化趋势。2. 计数归零还不够循环引用为什么必须交给标记-清除引用计数看起来完美但它有一个致命缺陷无法处理循环引用。这不是理论问题而是我在实际项目里真实踩过的坑。两个对象互相引用外部变量全部删除后它们的引用计数永远不会归零内存就永远无法释放。在长期运行的服务里这种对象会越积越多形成一条条看不见的内存孤岛。下面这段代码就是一个经典的循环引用场景class Node: def __init__(self): self.parent None self.children [] node_a Node() node_b Node() node_a.children.append(node_b) node_b.parent node_a del node_a del node_b在del之后node_a和node_b这两个实例依然互相持有引用node_a的children列表里有node_bnode_b的parent里又指回了node_a。外部已经没有引用能到达它们但每个实例的引用计数都不为0。引用计数机制等在那里却永远等不到清零的那一刻。为了处理这类对象CPython内置了垃圾回收器也就是我们常说的gc模块。它采用标记-清除加分代回收的策略。注意垃圾回收器只跟踪容器对象——凡是能够持有其他对象引用的对象比如list、dict、set、自定义类实例都会进入跟踪列表。像int、str这类无法引用其他对象的类型不参与gc跟踪因为它们的生命周期完全可以由引用计数来管理。2.1 标记-清除的具体判定逻辑标记-清除算法的核心思想可以从根集合出发考虑。什么是根集合全局变量、当前调用栈、栈帧中的局部变量、正在执行的函数参数等这些是GC能直接触达的根。整个算法分为两个阶段标记阶段从根集合出发沿着引用关系遍历所有容器对象凡是能访问到的对象都打上可达标记。清除阶段遍历整个堆把所有没有可达标记的容器对象回收掉。这里容易混淆的关键点是标记-清除并不关心对象的引用计数是多少它只关心从根出发能不能走到这个对象。因此两个互相引用的Node实例即便计数都是1只要根集合里没有它们就会被判定为不可达进而被回收。换句话说循环引用在标记-清除眼中只是一个走不到头的环环上没有根就是垃圾。还有一个细节值得展开很多人以为gc.collect()可以回收所有垃圾但实际上对象只有在被分配器和解释器正确追踪的情况下才会被回收。如果一个对象在创建后没有显式注册到GC跟踪列表或者它的类型被判定为不支持GC那么即使存在循环引用gc也无法处理。这也是为什么自定义类在元类、__slots__等方面改了太多结构后偶尔会出现gc收集不了的怪象。2.2 分代回收的阈值与触发时机分代回收基于一个在实际运行中总结出的观察新创建的对象往往很快就会被销毁而活过了若干次回收的对象存活概率会显著提高。CPython把对象分成三代第0代、第1代、第2代。每代都有独立的计数器当第0代对象的新增数量减去被清除对象的数量达到阈值默认700就会触发一次第0代回收第0代回收后存活下来的对象晋升到第1代第1代计数达到阈值默认10触发第1代回收依此类推第2代阈值默认也是10。可以使用gc.get_threshold()查看当前阈值使用gc.set_threshold()修改。手动调用gc.collect()可以立即执行全代回收但要注意频繁调用会带来不可忽略的性能开销因为它要扫描整个堆。GC不是免费的也绝不是越快越好。我补一个实操中总结出来的经验在实时性要求很高的服务里默认阈值可能在尖峰流量下带来大量卡顿。我遇到过API服务每隔一段时间停顿几十毫秒查了半天发现是第0代回收恰好集中在流量高峰。当时的处理方案是在低峰期调用gc.collect(2)执行一次完整回收减少后续各代的垃圾累积同时根据对象的实际生命周期调整各代阈值让回收频率与对象创建速率匹配。还有一个更进阶的办法是gc.freeze()它可以把启动阶段创建的、此后不会变动的大量对象冻结起来让GC在后续扫描中跳过它们这个技巧对常驻服务非常管用。3. 用gc.get_objects()和tracemalloc定位内存问题的完整链路前面说的都是原理真正干活的时候你得有工具。下面记录一次真实的排查过程。场景来自一个数据抓取服务每小时跑一批任务长期运行后内存从初始的500MB一路涨到近3GB重启后立刻恢复正常。这是一条典型的Python内存增长曲线我把排查过程拆成四步每一步都有明确目的。3.1 第一步先判断是不是真内存泄漏内存增长不一定就是泄漏也可能是缓存未清理、批量任务累积、内存碎片化、第三方库内部缓存等等。第一步永远是区分进程正常增长和真正泄漏。我用tracemalloc统计内存分配的累计情况。启动阶段调用tracemalloc.start()它是Python标准库提供的堆栈级内存追踪工具可以记录每次分配的调用堆栈。运行一段时间后用tracemalloc.take_snapshot()保存快照再用snapshot.compare_to(old_snapshot)看增量排序找出哪些调用路径创建的对象占了最多内存。同时我还会临时开启gc.set_debug(gc.DEBUG_STATS | gc.DEBUG_OBJECTS)观察垃圾回收器的工作情况看gc.collect()之后进程内存是否明显下降且能回到基线。如果回收后内存显著下降说明泄漏主体在gc可跟踪对象中如果回收后完全不下降那就要怀疑C扩展、非容器对象、第三方模块内部持有了引用。这一步的关键结论是先别急着下泄漏结论先做对照实验。在同样的任务量下一个版本跑12小时另一个版本每2小时手动调用gc.collect()比较两者内存曲线的斜率。如果无差别增长问题出在底层的持久引用或缓存如果有差别那gc可回收的垃圾占了大头循环引用嫌疑最大。3.2 第二步用gc.get_objects()和objgraph锁定目标确认泄漏在gc跟踪对象中之后我通常用objgraph辅助定位。objgraph的count()和show_most_common_types()可以让你快速看到当前进程中哪些类型的对象数量异常。不过生产环境一般不装graphviz所以我更常用纯gc模块的组合拳先调用gc.collect()强制回收一次再用gc.get_objects()取回所有仍在GC跟踪列表中的对象配合collections.Counter按类型统计数量。统计逻辑非常简单但效果却出奇地好import gc from collections import Counter gc.collect() all_objects gc.get_objects() stats Counter(type(obj).__name__ for obj in all_objects) for type_name, count in stats.most_common(20): print(type_name, count)如果gc.collect()执行之后某个自定义类的实例数量依然维持在很高的水平基本可以断定它们形成了gc无法打破的引用环或者被某些根对象持有。这时候需要利用gc.get_referrers()从某个对象向上反查谁还在引用它。例如怀疑某个任务对象泄漏就先取一个实例调用gc.get_referrers(instance)逐层往上翻引用链直到找到某个缓存字典、回调函数、事件总线把它牢牢拽住。我遇到过一种非常隐蔽的情况某个类的实例被lambda回调闭包持有lambda又被挂在全局事件总线上事件总线永不清理实例就永远活着。这种链条不用gc.get_referrers()逐层追踪基本看不出来。有一次我还发现一个框架内部的日志对象循环列表持有过去1000条日志每条日志又带着整个请求上下文对象导致每个HTTP请求都在内存里留了一个完整快照。这种问题不看引用链根本发现不了。3.3 第三步修复代码并做前后对比定位到根源后修复手段一般分三种如果是任务队列里历史结果集越积越多改为每次完成后清空或使用固定大小的有界队列。如果是循环引用尽量打破环最直接的办法是把其中一个方向的引用改成weakref.ref。如果是事件总线、回调注册表造成对象常驻则在对象生命周期结束时主动反注册或者注册时直接使用弱引用。我有一个习惯修复完成后不会立刻上线而是做一次双版本对比实验。两个版本并行跑相同的任务量每6小时记录一次RSS和gc.get_objects()里的对象数量。48小时之后如果修复版的内存曲线保持平稳另一个版本继续上涨才算真正结案。这一步非常重要因为很多修复表面有效但只是推迟了上涨时间或者把泄漏换成了另一种对象类型。只有长时间对照才能确认引用关系真正被理清。其实排查过程本质上和GC算法是同一套逻辑从根出发找可达性。你理解了标记-清除怎么判断存活就自然知道该怎么追踪引用。反过来每次排查也是对你对垃圾回收器理解的检验。4. 现实代码里最常踩的内存坑事件回调、缓存和__del__原理和排查链路都讲完了最后分享几个日常编码里高频出现的内存坑。它们都和引用计数、垃圾回收直接相关属于那种不踩一次不深刻的问题。4.1 事件回调注册表引用链的隐形黑洞很多框架的事件总线、消息订阅机制底层都在一个注册表里保存回调对象。如果你把某个监听器对象直接注册进去又不主动注销那么这个对象会一直挂在注册表上。更麻烦的是注册表本身往往被全局状态持有所以从这个对象出发沿引用链走到根集合是完全可达的。GC不会回收它内存不仅不释放还会在每次事件触发时被无谓地调用一遍。我自己的习惯是注册时尽量用弱引用或者确保对象生命周期结束前主动调用取消注册。如果一定要保持强引用就必须在对象清理方法中做反注册。在做模拟项目X的消息系统时我让监听器对象显式调用cancel()并且内部实现持有token每次处理回调前先检查token是否有效双重保险防止幽灵回调。4.2 弱引用打破环但别乱用weakref.ref允许你引用一个对象但不会增加引用计数。当被引用对象被垃圾回收后再访问弱引用会返回None。这个特性非常适合缓存场景和打破循环引用。比如你想实现一个以对象为键的缓存表不方便用强引用一直持有对象就可以用WeakKeyDictionary。但弱引用也有不少坑。第一不是所有类型都支持弱引用int、list、dict等内置类型的默认实例就不支持。如果你想对自定义类型使用弱引用类定义时需要满足条件或者显式声明相关支持属性否则会直接报错。第二使用弱引用后必须处理被引用对象已消失的情况否则会在回调里访问None引发AttributeError。第三弱引用本身也会产生管理开销不要为了微小的内存节省到处用滥用反而拖慢性能。4.3 __del__与循环引用的纠缠在类中定义析构方法要格外小心。如果对象同时处于循环引用中即使GC判定它不可达而回收也会触发析构逻辑。如果析构方法内部访问了其他可能已被回收的对象属性就可能出现莫名其妙的状态。更糟糕的写法是在析构方法里创建新的全局引用让对象复活导致GC无法再稳定回收它。我的经验很明确不要把关键资源释放寄托在析构方法上。文件句柄、锁、socket这些资源请使用with语句或try/finally显式管理。如果一定要用析构方法做清理就注意两点一是让对象尽可能远离循环引用二是保持析构逻辑简单只做不依赖外部状态的清理动作。每次定义自定义类后我都会刻意检查实例是否可能进入引用环如果有优先用弱引用或显式清理来解环。4.4 大对象、内存碎片与驻留内存最后说一个容易被忽视的问题即使你的对象都被正确回收了进程占用的物理内存也不一定下降。原因在于Python分配的内存会缓存在内存池里复用操作系统层面不会立即收回。这是一种典型的空间换时间策略所以你在任务管理器或top里看到RSS偏高并不一定代表泄漏。判断方法很简单让服务运行稳定后调用一次gc.collect()观察RSS变化。如果RSS没降但gc.get_objects()里的对象数量下降明显说明内存池缓存和碎片占了主要部分多数情况下可以接受如果对象数量并没有下降那才是需要警惕的信号。另外Python对大块内存的申请和释放通常走系统调用频繁分配和释放大对象会造成地址空间碎片化长期运行后即使内存池很干净整体内存布局也可能变得很乱。根据我个人经验与其纠结让RSS降下来不如控制对象的峰值创建量。比如数据抓取场景不要一次性把所有URL构造成对象而是分批处理不要为每个小任务都创建新的数据库连接而是复用连接池在批量计算结果时及时把中间结果写入磁盘清空内存。峰值降下来内存问题至少少一半。最后再分享一个小技巧我在常驻服务启动后会在初始化阶段调用gc.freeze()把启动过程创建的那些长期存活对象固定下来。之后每次GC扫描就不用再反复检查它们了这对缩短GC停顿时间非常有效。同时我会定期用tracemalloc保存内存快照并归档等线上出现异常时直接和基线快照对比比临时加日志高效得多。这套习惯帮我解决了不少疑难问题希望能给你带来同样的收益。