写Python的人往往不需要像C程序员那样手动申请和释放内存，这既是这门语言的优势，也是许多问题的根源。垃圾回收把内存管理的细节藏了起来，可一旦程序出现内存持续上涨、对象迟迟不释放的情况，没有底层知识的开发者就会束手无策。本文从Python的内存架构讲起，逐步拆解引用计数、标记清除、分代回收三大机制，最后结合实战案例演示如何定位和解决内存泄漏。
一、Python内存管理的整体架构
Python的内存管理可以分为三层来看。最上层是Python对象自己的分配策略，比如小整数缓存、字符串驻留、小对象池；中间层是pymalloc分配器，专门负责小于512字节的小块内存申请；最底层则交给C标准库的malloc和mmap处理大块内存。
这套分层设计的目的很明确：Python程序运行时会疯狂创建和销毁小对象（整数、短字符串、临时元组等），如果每一次都直接调用系统级分配器，开销会非常可观。pymalloc通过arena、pool、block三级结构管理内存，把大量小块申请集中在固定大小的池子里，回收后的空间可以被反复复用，避免了频繁的系统调用。
理解这一点对排查问题很关键。很多开发者发现进程RSS内存不下降，第一反应是内存泄漏，其实很可能只是小对象池缓存的正常表现——对象已经释放，但内存块留在了池子里等待复用。判断是否真泄漏，不能只看进程内存，要看对象的存活数量。
二、引用计数：最核心的回收机制
CPython中每个对象都有一个ob_refcnt字段记录被引用的次数。引用加一、引用减一的时刻包括：变量赋值、作为参数传入函数、加入容器、变量被删除或超出作用域、容器被销毁等。一旦计数归零，对象立即被回收，内存立刻归还给分配器。
可以用sys.getrefcount观察这个行为，但要注意它本身会临时增加一次引用：
import sys a = [] print(sys.getrefcount(a)) # 输出2：变量a本身算1次，getrefcount传参临时算1次 b = a print(sys.getrefcount(a)) # 输出3：b又引用了它 del b print(sys.getrefcount(a)) # 输出2：引用解除，计数回落
引用计数的优点是实时性强、逻辑简单，对象一旦不可达马上释放，不会造成回收停顿。但它有两个致命弱点：第一，频繁维护计数有性能开销，尤其在多线程场景下需要加锁；第二，它处理不了循环引用——两个对象互相指着对方，即使外部已经没有任何入口，各自计数也永远不会归零。这就引出了第二套机制。
三、分代回收与循环引用的处理
为了解决循环引用，CPython引入了gc模块，采用标记清除加三代分代的策略。所有容器对象（list、dict、set、自定义类实例等）都会被gc跟踪。回收时，gc从根对象出发做可达性分析，把不可达的对象组整体回收，循环引用的孤岛就这样被清理掉。
分代的思想基于一条经验规律：对象越年轻，越可能早早死亡；熬过几轮回收的对象，大概率会长期存活。所以gc把对象分为0代、1代、2代，新对象进入0代，0代回收后存活的对象晋升到1代，以此类推。0代回收触发最频繁，2代回收间隔最长，这样把扫描开销集中在朝生暮死的短命对象上。
import gc, weakref
class Node:
def __init__(self):
self.partner = None
# 构造循环引用
n1, n2 = Node(), Node()
n1.partner, n2.partner = n2, n1
del n1, n2
print(gc.collect()) # 手动触发回收，返回清理的对象数量
# 用弱引用打破循环
class Node2:
def __init__(self):
self.partner = None
a, b = Node2(), Node2()
a.partner = b
b.partner = weakref.ref(a) # 弱引用不增加计数
弱引用是规避循环引用的利器，缓存场景中尤其常用。它不增加目标对象的引用计数，目标对象只被弱引用持有时依旧会被正常回收，需要时通过ref()取出，取到None说明对象已经不在了。
四、实战案例：定位一次内存泄漏
假设一个长期运行的服务，缓存模块把请求结果存进一个全局字典，键是请求参数，值是结果对象。随着时间推移内存持续增长，最终被OOM杀掉。排查这类问题的思路是：先用tracemalloc抓分配快照，对比两个时间点的差异，找出增长最快的对象类型和分配位置。
import tracemalloc, time
tracemalloc.start()
cache = {}
def handle_request(key):
if key not in cache:
cache[key] = "x" * 10000 # 模拟大结果对象
return cache[key]
for i in range(100000):
handle_request("key_%d" % i)
snapshot = tracemalloc.take_snapshot()
for stat in snapshot.statistics("lineno")[:5]:
print(stat)
上面的例子问题很明显：缓存只增不减，缺少淘汰策略。修复方式通常是引入functools.lru_cache限制容量，或者定期清理过期键。真实项目中，还要警惕另一类隐蔽泄漏：异常处理中持有 traceback、闭包意外捕获大对象、全局注册表忘了注销回调等。这类问题的共同点是对象仍然被引用着，引用计数和gc都无能为力，属于逻辑层面的泄漏。
总结一下排查清单：进程内存涨但对象数不涨，多半是小对象池的正常缓存；对象数持续增长，用tracemalloc或objgraph定位分配源头；怀疑循环引用，检查gc.garbage列表；确认不需要的循环结构，改用弱引用或显式断链。掌握这套组合拳，Python内存问题基本都能落地解决。
Python内存管理垃圾回收引用计数修改时间：2026-09-10 18:52:42