聊Python内存管理不少朋友的第一反应是解释器自己管的事跟我有什么关系。这个想法我以前也有直到线上服务出现内存只涨不降、跑两天就OOM的时候才意识到垃圾回收和引用计数这些机制如果只会背概念、不理解背后的实际行为排查问题完全是无从下手的。这篇文章围绕Python内存管理机制中的两大支柱——垃圾回收与引用计数——展开我会从引用计数如何决定对象的生与死讲到循环引用如何绕过引用计数、倒逼垃圾回收器接管再把分代回收的触发阈值、内存池的小对象分配、弱引用、常见泄漏场景一次讲透。适合正在入门Python但想深入理解的读者更推荐给已经写过一段时间代码、遇到过内存暴涨但排查无门的同学。收藏之后按文中思路在本地跑一遍比看十遍文档都有用。1. 先搭一张全景图引用计数、GC、内存池各管哪一段很多人把Python的内存管理笼统理解为垃圾回收实际上一套完整的内存体系至少拆成三层对象生命周期的判定、死亡对象的回收、内存块的物理申请与释放。第一层是引用计数它回答的是这个对象还有没有人用。Python里每个对象都在头部维护一个ob_refcnt字段记录当前有多少地方引用了它。被引用一次就加一引用失效就减一减到零就立即释放内存。这个机制是Python内存管理的默认地基绝大多数对象都是靠它完成回收的。第二层是垃圾回收器它专门处理引用计数解决不了的循环引用。比如两个对象互相持有对方外部引用全部解掉之后两者的引用计数都停留在1谁也不会归零这时候就需要GC去扫描对象图找出那些明明不可达却还活着的对象并清理掉。第三层是内存分配器也就是pymalloc、free list、小整数缓存这些底层设施。它们负责把从操作系统拿来的内存组织成小块快速分给对象使用并且在对象死亡后尽量复用内存减少系统调用带来的开销。展开说说为什么循环引用会漏网引用计数的原始设计完美覆盖线性引用A引用B、B引用CA被删掉之后B、C的引用链条逐层断裂引用计数逐层归零内存自然释放。但一旦出现A引用B、B也引用A这种环形结构断裂链条就卡住了。两个对象的refcnt都至少为1引用计数认为还有人用实际却是两个孤儿互抱取暖。这正是GC存在的核心原因。这三层分工明确对应到日常排查里也就有了三个排查方向想看某个对象是否被意外持有查引用计数怀疑有循环引用看gc模块的对象图想理解内存为什么会不断膨胀不还给系统研究内存池和缓存机制。理解了这三层后面所有代码和调优技巧就都有了参照系。2. 引用计数机制对象的生与死全靠一个计数器2.1ob_refcnt是怎么变来变去的Python对象头部的ob_refcnt字段是引用计数的物理载体。对一个普通对象来说下面这些操作都会让计数加一赋值给变量、追加进列表、放进字典、作为参数传入函数、在函数执行期间被局部变量临时引用。对应的减一操作也很明确变量被重新赋值、对象被del、容器被清空或删除、函数返回后局部变量销毁。你可能听过sys.getrefcount()这个函数可以查看引用计数但用的时候要小心它返回的结果一定比你直觉中的引用次数多出1。原因是getrefcount本身把对象作为参数传入了函数函数内部在参数传递的一瞬间又产生了一次临时引用。所以实际引用数要减去这1才算当前代码里真实的引用个数。看个直观例子import sys a [1, 2, 3] print(sys.getrefcount(a)) # 2a本身1次 getrefcount参数传递1次 b a print(sys.getrefcount(a)) # 3a本身1次 b引用1次 参数传递1次 c [a, a] print(sys.getrefcount(a)) # 5多出来的2次来自c列表里的两个引用这个例子把引用计数的每一次可见引用拆解得很清楚。理解这个之后你再看对象生命周期就会自然想到只要计数不为零对象就永远活着哪怕逻辑上已经没人需要它。2.2 引用计数归零的瞬间发生了什么当一个对象的引用计数由1降到0Python会立刻调用tp_dealloc槽位函数完成对象本身的资源释放。像自定义类就释放实例属性和底层结构像file对象就关闭句柄像dict就先释放内部表项再释放结构本身。这一连串操作是同步的、确定的因此引用计数天然有即时回收的优势不像其他语言那样要等GC线程某个周期来跑一趟。普通场景下这个机制非常高效。局部变量用完即走、临时对象随创建随回收内存使用曲线是平滑的。很多人说Python慢其中一部分锅其实是对象频繁创建销毁带来的损耗比如在循环里拼字符串、反复创建临时列表但这是设计取舍的结果不是引用计数本身的锅。不过即时回收也有让程序员意外的时刻如果一个对象实现了__del__方法那么回收时__del__被调用里面如果做了耗时操作或抛了异常程序会很难排查尤其在循环引用场景下问题会被放大。这一块我在第五章会详细讲坑。2.3 循环引用引用计数唯一的软肋引用计数对循环引用无能为力这是设计使然。构造一个经典场景看下class Node: def __init__(self): self.neighbor None a Node() b Node() a.neighbor b b.neighbor a del a del b删除a、b之后a还持有b的引用b还持有a的引用两个节点的引用计数都是1但没有外部路径能到达它们。它们成了随时都在消耗内存的活僵尸。单看这个微型例子无伤大雅但如果是一个大对象的网络结构比如一个复杂的图模型、互相嵌套的树节点、事件处理器与监听器互相引用这样的僵尸集群就会持续占用内存最终表现为程序内存一路走高、不回收。这正是垃圾回收器必须存在的理由——它就是为引用计数兜底而生的。3. 分代垃圾回收怎么找出那些还活着的僵尸对象3.1 为什么不是一次扫描所有对象理论上可以每次GC都扫描全部存活对象但对象越多开销越大而且绝大多数对象都是朝生暮死全面扫描大部分对象是浪费。Python因此采用分代回收策略把对象按存活时间分成三代0代、1代、2代。新创建的对象进0代0代中经过一轮回收仍然存活的对象晋升为1代1代中再存活的对象晋升为2代。代的数值越大被扫描的频率越低因为设计假设是活的时间越长越可能继续活下去。这个思路和Java、Go等语言的年轻代/老年代有异曲同工之处但Python的实现更轻量而且和引用计数互补引用计数已经回收掉了绝大多数短期对象进GC视野的本身就少分代又进一步把扫描范围缩小到可能已经存活了一段时间的对象上GC的整体负担很低。3.2 触发的三把尺子gc.get_threshold()看到底什么时机跑代码里可以通过gc.get_threshold()查看当前分代阈值默认值通常是(700, 10, 10)。含义是第0代对象数超过700时触发一次0代收集每次0代收集后第1代的计数器加1当这个计数器累计到10触发一次1代收集每次1代收集后第2代的计数器加1累计到10触发一次2代收集用一个表格把阈值机制拆清楚分代阈值参数触发条件扫描范围0代700新建对象数减去回收对象数达到700只扫描0代对象1代10每完成10次0代收集累计触发1次扫描0代和1代2代10每完成10次1代收集累计触发1次扫描0代、1代、2代全部实际操作中0代回收非常频繁每次消耗极小1代和2代回收间隔逐渐拉长每次消耗逐渐增大。所以不要听到GC就紧张绝大多数进程大部分时间只在进行0代收集开销微乎其微。3.3 标记-清除从根出发给对象图涂色分代回收用的核心算法是标记-清除。先把所有可达对象从根开始遍历一遍并标记为存活根包括当前调用栈、全局变量、正在执行的帧、模块引用等遍历完没被标记的对象就是不可达对象统一清除。Python的实现里GC把自己能看到的容器对象list、dict、set、tuple、自定义类实例等记录下来形成一个双向链表0代回收时就针对0代链表里的对象做标记。遍历是图遍历所以无需递归栈太深而是用内部栈迭代处理。这里有个隐藏细节GC只扫描可能包含引用的容器对象像整数、短字符串这类PyObject不参与环检测因为它们无法持有指向别的对象的引用不能形成闭环。所以GC对象链表里装的全是容器扫描规模被进一步压缩。3.4 触发时机其实可以控制gc.disable()要慎用gc.disable()可以直接停掉分代回收但绝对不要把关掉GC当成性能优化的默认手段。关闭之后循环引用对象将永远没人清理一旦程序里存在环形结构内存泄漏会肉眼可见地加速。某些性能敏感的批处理场景可以在确认没有循环引用的前提下游走极限但多数业务场景毫无必要。正确做法是选择性触发。比如一个短平快的脚本对象生命周期极短跑完即退关不关GC无所谓再比如一个长期运行的服务定期在低峰期调用gc.collect()做一次主动清理比依赖GC自动调度更可控。我习惯在处理大量临时对象、明显感觉内存曲线升高后主动调一次gc.collect()观察曲线回落这是一种非常实用的运维手段。4. 底层内存分配为什么回收了内存进程却还占着那么大4.1 pymalloc与512字节的分水岭很多人在任务管理器里看Python进程占用内存很高于是怀疑对象没被释放。其实对象确实释放了但是Python不会把每一块内存都立刻归还给操作系统而是自己留着复用。这条复用链路上最关键的是pymalloc分配器。Python的通用对象分配规则是小于512字节的对象走pymalloc自己管理的内存池大于等于512字节的对象直接由系统级malloc分配。pymalloc把内存池切成固定大小的block按8、16、24……一直到512字节的规格分类。分配一个小的int对象实际是从对应规格的pool里取一个block释放时再把block归还pool。pool全部空闲时会尝试返回给arena但arena本身也可能仍然保存在解释器内部缓存里不会立刻还给OS。4.2 free list缓存常见类型对象的回收站free list机制让某些类型在对象释放后保留一份缓存。比如list对象被del之后它在底层申请的那块元素存储空间可能不会被完全释放而是进入一个空闲链表供下一次创建list时直接复用。dict、tuple、set等核心容器都有类似逻辑。这个机制的直接效果是内存被冻结在进程内部的空闲链表里进程实际占有的RSS没有下降但业务代码里确实已经没有任何对象引用它们。换句话说你看到的内存占用高不一定等于泄漏也可能是空闲缓存。要验证这一点可以用tracemalloc看内存快照或者在释放大对象后观察gc.collect()和二次分配的效果。如果内存始终不降则可以检查是否有对象真的还被全局容器引用着而非怀疑缓存。4.3 小整数缓存与字符串驻留is判断的幕后黑手Python对-5到256之间的整数做了缓存所有代码里出现的这些整数都是同一个单例对象。字符串驻留机制也类似一些短字符串会被复用同一个对象。这就导致了一个经典的面试迷题a 256 b 256 print(a is b) # True x 257 y 257 print(x is y) # 大概率False实际运行结果并不绝对但大多数情况下256相同对象、257不同对象。核心原因是小整数被缓存257每次创建都可能产生新对象。业务代码里千万不要依赖这个特性做判断is只用于判断单例对象比如None、枚举值值比较一律用。5. 泄漏排查实战用工具找到那个不该活着的对象5.1gc模块的体检三件套排查循环引用时gc模块是最直观的工具。接口不多但非常实用。下面这段代码模拟了一个典型的循环引用泄漏并用gc.get_objects()找出残留对象import gc class Leaky: pass def make_cycle(): a Leaky() b Leaky() a.other b b.other a for _ in range(1000): make_cycle() print(gc.get_count()) # 查看当前各代对象计数 print(len(gc.get_objects())) # 当前被GC跟踪的总对象数 gc.collect() # 手动触发一次完整回收 print(len(gc.get_objects())) # 回收后剩余对象数gc.get_count()返回(0代计数, 1代计数, 2代计数)用来看GC是否积累了太多对象。gc.get_objects()列出所有被GC跟踪的对象数量异常大就说明可能有东西没被正确回收。一个更实用的小技巧是把gc.set_debug(gc.DEBUG_LEAK)开起来这样被判定为无法回收的对象会打印详细信息尤其是定义了__del__的循环引用对象。5.2 用tracemalloc定位内存增长点tracemalloc适合定位生产环境哪些代码行正在持续吃内存。它按Python代码的调用链记录内存分配不需要第三方库import tracemalloc tracemalloc.start() # 这里跑你的业务代码比如反复处理大列表 data [[i for i in range(10000)] for _ in range(100)] snapshot tracemalloc.take_snapshot() top_stats snapshot.statistics(lineno) for stat in top_stats[:10]: print(stat)输出会写明具体文件、行号、分配块数、内存大小。我在实际项目里靠这个工具定位到过一次缓存dict无限膨胀的问题——某个模块把每次请求结果都塞进一个模块级字典字典越积越大而代码里完全看不出异常。tracemalloc的快照对比功能还能比较两个时间点的差异是最适合做增量分析的利器。5.3objgraph直观画出谁在引用谁objgraph是一个第三方库能画对象引用图排查复杂循环引用特别好用。核心用法import objgraph objgraph.show_refs([your_object], filenamerefs.png) objgraph.show_backrefs([your_object], filenamebackrefs.png)show_refs展示对象指向了谁show_backrefs展示谁指向了这个对象。排查为什么大对象回收不了时show_backrefs非常有用能直接看到对象被哪些全局变量、缓存、事件回调引用着。有一次线上问题查出数据类被一个长时间存活的closure隐式引用就是用backrefs一眼看出来的。5.4 常见泄漏场景速查表泄漏场景深层原因解决思路模块级dict缓存无限增长缓存无淘汰策略对象一直被全局引用加过期时间、限容、改用weakref闭包意外持有大对象闭包捕获的变量生命周期被延长用默认参数传递需要的数据避免闭包引用__del__ 循环引用有__del__的对象在循环引用中无法被GC完整回收避免在__del__重写逻辑或用弱引用事件监听器被全局注册监听器一旦注册就持有对象引用注销逻辑缺失确保对象销毁时主动解绑事件大列表循环遍历残留生成器或迭代器未被关闭保留了栈帧和局部变量用with、try/finally确保迭代器关闭排查这类问题有一个通用的思维框架先确定对象类型再用gc.get_referrers(obj)反向找引用源最后用objgraph可视化。不要一开始就用psutil看进程内存那个只能粗略确认现象定位不了代码位置。6. 优化内存的通用套路让对象按预期死去6.1 用对容器__slots__能省大量内存吗能。默认的类实例用一个内部dict存属性这个dict本身开销不小。加了__slots__之后实例用固定长度数组存属性不再需要dict一个百万级实例的场景可以省下可观内存同时属性访问会更快。class Point: __slots__ (x, y) def __init__(self, x, y): self.x x self.y y但__slots__有代价不能动态添加新属性继承时要谨慎。适合数据类、结构体、实体对象这种字段固定的场景不适合做通用基类。6.2 大量临时对象如何处理性能尽量减少循环内部的临时对象创建。例如用生成器表达式代替列表推导式逐项处理能节省一整块列表内存在大循环里拼接字符串换成join。这些属于代码层面的经典优化和GC配合起来效果显著——临时对象少了引用计数归零的析构也少了GC压力随之下降。同时要避免把一个超大对象一直引用住。比如处理一个100万条记录的文件千万不要一口气读进list再遍历应当逐行读取、逐批处理、及时释放。配合之前讲的free list缓存机制及时释放能让内存复用率提高进程整体峰值会低很多。6.3 弱引用给缓存一个不挡路的选择弱引用是一种不增加引用计数的引用。被弱引用指向的对象仍然可能被正常回收回收之后弱引用对象自动变成None。这在缓存场景中特别有价值import weakref class CacheItem: pass item CacheItem() r weakref.ref(item) print(r()) # 对象还活着返回对象本身 del item print(r()) # 对象已被回收返回None弱引用不是银弹它不能替代所有缓存设计但它非常适合可有可无有则复用无则重建的场景。比如大型配置文件缓存、工具类单例缓存用弱引用能避免缓存本身残害了无用的对象这个反模式。6.4 主动GC的合理姿势gc.collect()不是什么时候都该调。频繁调用会增加额外开销白白消耗CPU。合理场景如下创建了大量临时数据结构然后又删掉比如批量任务处理前后长时间空闲服务刚启动完大型初始化主动清一次已知业务峰值后低峰期触发一次完整回收实际操作中我用一段定时任务每分钟调一次gc.collect()观察内存曲线是否能回落这比单纯看OS内存更能判断是否存在真实泄漏。如果主动gc.collect()后内存马上下去了那大多只是回收不及时如果主动回收后内存纹丝不动极可能有对象被全局引用链绑着还是得回到引用分析和tracemalloc定位。7. 经验之谈真正踩过的坑和最后一条建议我在实际项目里最常见的误判是内存涨了就是泄漏。排查过几次后才发现相当一部分是free list缓存和arena没归还导致的现象对象本身早没了。判断泄漏前一定先手动gc.collect()一次观察立刻的效果再决定要不要深入分析引用链。另一条经验是关于__del__的。我遇到过自定义类写了__del__里面打印日志结果对象和另一个对象互相引用GC后__del__被延迟到回收那一刻执行日志顺序全乱还出现异常。后来我干脆不在业务类里写__del__资源释放全部用显式的close()方法配合with语句管理代码清晰也不干扰GC的判断。最后分享一个我常给的排查小技巧在代码里临时加一个定时任务每五秒打印一次gc.get_count()和len(gc.get_objects())。如果get_objects()数量持续直线上升不用想别的一定有对象在被GC跟踪的容器链表里堆积。这个信号比任何监控图表都来得直接能让你在用户感知到卡顿之前就定位到问题。内存管理不是读完这篇文章就能彻底搞定的但把引用计数、分代GC、内存池、弱引用这些点串起来再配合顺手可用的排查工具你面对内存问题时的底气和操作效率会完全不一样。