Python内存管理详解：从引用计数到垃圾回收与调优

我最近帮同事排查一个爬虫任务，脚本本身写得没毛病，但跑上七八个小时之后内存占用一路飙到十几个G，最后直接OOM被杀。查来查去发现既不是数据量真的那么大，也不是第三方库泄漏，问题出在一组互相引用的对象上。这让我觉得确实应该好好聊聊Python的内存管理机制——因为大多数Python开发者的认知都停留在“有垃圾回收，所以不用管内存”，真到内存暴涨的那一刻，很多人第一反应是加内存条或者重启脚本，根本没意识到虚拟机的内存管理策略才是关键。

这篇文章我会从CPython的引用计数入手，讲清楚垃圾回收到底回收了什么、分代回收又是怎么运作的、Python进程的内存为什么涨上去就不降下来，以及实际定位内存问题应该用什么工具。适合写爬虫、跑数据分析、做服务端开发的Python使用者，也适合那些已经看了不少“垃圾回收”资料，但对内存分配细节还比较模糊的进阶学习者。

1. 先回答那个最基础的问题：Python为什么不需要手动管理内存

如果你写过C或者C++，一定经历过为每一个malloc找对应的free、为每一个new找对应的delete的日子。稍微漏掉一个分支路径，内存泄漏就悄悄生了根。而Python从设计之初就决定把这块复杂度收走，让你专注写业务逻辑而不是天天数括号、对指针。

但这并不意味着Python就没有内存管理，只是管理方式从“程序员手动”变成了“运行时自动”。Python运行时会在背后维护每个对象的状态，判断一个对象什么时候不再被使用，然后把它占用的空间收回。这套机制的核心其实是一句话：每个Python对象都带着一个计数器，记录“现在有多少个地方引用了这个对象”。

这个计数器藏在每个对象的标准头部里。CPython中所有对象都共享同一个基础布局PyObject，它至少包含两个字段：一个是类型指针ob_type，告诉解释器这个对象是什么类型；另一个就是引用计数ob_refcnt，用来记录这个对象当前被谁引用了。

typedef struct _object { Py_ssize_t ob_refcnt; PyTypeObject *ob_type; } PyObject;

这个设计非常巧妙，因为它把不同对象（整数、字符串、列表、字典、类实例）统一成了同一种管理单元。无论你创建的是多么复杂的对象，虚拟机都只需要关心两件事：它的类型是什么，以及还有没有人持有它。

手动管理内存时，最常见的错误有两个：一种是提前释放了一块还在被引用的内存，导致悬垂指针；另一种是忘了释放已经没用的内存，导致泄漏。而引用计数机制在理论上能同时规避这两个问题——它不会在计数器归零前回收对象，所以没有悬垂指针的问题；一旦计数器归零，它立刻回收对象，所以也谈不上“忘了释放”。

当然，理想很丰满，现实很骨感。引用计数虽然解决了大多数场景下的内存回收问题，但它有个致命的软肋，就是处理不了循环引用。这个问题我会在后面的章节展开，垃圾回收器存在的意义也正是补齐这个短板。

简单总结一下Python的内存管理全景图：对象分配走的是内存分配器，对象释放主要靠引用计数，引用计数处理不掉的循环垃圾由分代垃圾回收器兜底。三层各司其职，缺一不可。接下来我一个一个拆开讲。

2. 引用计数：CPython回收对象的第一道闸门

2.1 计数器什么时候加一、什么时候减一

引用计数的规则说穿了就两条。引用计数加一的情况：把对象赋值给一个新变量、把对象放进列表或字典等容器、把对象作为参数传给函数、把对象作为返回值从函数里抛出来。引用计数减一的情况：变量被重新赋值指向别的对象、变量用del显式删除、容器里的对象被移除、函数运行结束局部变量销毁。

我可以给你看一个很直观的例子，用sys.getrefcount来观察某个对象的引用计数变化：

import sys a = [] print(sys.getrefcount(a)) # 2 b = a print(sys.getrefcount(a)) # 3 c = [a] print(sys.getrefcount(a)) # 4 del b print(sys.getrefcount(a)) # 3

这里有个细节容易让人困惑：为什么刚创建的空列表，sys.getrefcount(a)显示的是2而不是1？因为sys.getrefcount这个函数本身在接收参数时也会让引用计数加一，所以打印出来的数值永远比真实值多1。也就是说，上面第一行输出2，实际上说明这个列表当前只有变量a一个真正的引用。

引用计数机制带来的一个显著特性就是回收的即时性。当一个对象的引用计数降到0，CPython会立即调用它的内存释放逻辑，不需要像纯追踪式垃圾回收那样等一轮GC周期。这也是为什么你在脚本里写一个大列表，然后del掉它，用ps或任务管理器看内存会立刻降下来——当然这个说法要打折扣，因为内存分配器可能不会马上把内存还给操作系统，这是后面第4章要单独聊的事情。

2.2 引用计数在CPython底层是怎么执行的

在CPython源码里，引用计数的增减分别对应两个宏：Py_INCREF和Py_DECREF。区别在于Py_DECREF在让计数减一之后会立即检查结果是否为0，如果为0就调用对象的tp_dealloc槽位函数，真正回收对象内存。

#define Py_DECREF(op) \ do { \ PyObject *_py_decref_tmp = (PyObject *)(op); \ if (--_py_decref_tmp->ob_refcnt == 0) { \ _Py_Dealloc(_py_decref_tmp); \ } \ } while (0)

这个设计的直接后果是：对象的生命周期非常确定，一旦没人引用就立刻销毁并执行__del__方法。对有些资源型对象（比如文件句柄、socket连接）来说是个不小的优势——只要引用归零，资源即刻释放，不用等GC来“抽空”处理。

但即时性也带来了一个现实代价：CPython对每个对象的引用计数操作都需要修改ob_refcnt，而且Py_INCREF和Py_DECREF是两个高频操作，变量赋值、函数传参、容器操作，样样都碰它。这意味着额外的一笔CPU开销。这也是为什么Python解释器在多线程场景下要持有GIL（全局解释器锁）——因为引用计数不是一个原子操作，如果不加锁，两个线程同时修改同一个对象的计数器会直接导致内存损坏。

2.3 引用计数最大的软肋：循环引用

引用计数的死穴，就是循环引用。看这段代码：

class Node: def __init__(self): self.neighbor = None a = Node() b = Node() a.neighbor = b b.neighbor = a del a del b

执行完del a和del b之后，这两个Node对象从代码层面已经访问不到了。但是它们的引用计数都不是0：a被b的neighbor引用着，b被a的neighbor引用着。每个对象的计数器里“最后那1”永远消不掉，于是它们就成了内存里的“僵尸”——既没人用，也不会被回收。

如果只有两个对象还好说，实际工程里这种互相引用的链条可以很长，比如A引用B、B引用C、C又引用A，甚至A引用B、B引用C、C再引用B，一层套一层。更麻烦的是，这种循环引用往往是隐形的，代码里你根本看不出来谁和谁已经组成了一个环。

不过需要注意一个前提：只有容器类对象才有可能产生循环引用。整数、字符串、浮点数这些不可变对象没法引用别的东西，自然也就不可能构成环。能被环困住的是列表、字典、集合、类实例这些能“持有其他对象”的类型。这也解释了为什么垃圾回收器只需要对容器对象做扫描，而不是对每个对象都做一次全量可达性分析。

3. 标记清除与分代回收：专治“循环引用”的组合拳

3.1 循环引用为什么需要专门的回收机制

引用计数本身就是个“近视眼”，它只盯着自己这一亩三分地，无法判断“两个对象互相抱着但整体已经没人要了”这种局面。要收拾这种局面，就必须换一种思路：不再问“这个对象被谁引用着”，而是问“从根对象出发，到底哪些对象还能够到达”。

这就是追踪式垃圾回收的基本思想。所谓“根对象”，包括当前栈上的局部变量、全局变量、内置模块等一切真正还被代码持有引用的地方。从根出发，凡是被引用的对象都算可达；反过来，从任何根都走不到的对象，即使引用计数不为0，也是实际意义上的垃圾。

CPython里的gc模块就是来实现这个追踪过程的。它维护着一个容器对象链表，专门记录那些“可能构成循环”的容器对象。当触发回收时，gc模块会扫描这片区域，做一次标记-清除操作。

3.2 标记-清除到底在做什么

标记-清除分成两个阶段。

标记阶段：从根对象出发，沿着引用关系图遍历，能到达的对象打上“可达”标记。这里有个容易误解的点——Python的gc模块标记的不是“从根出发可以生成的全局对象图”，而是“当前被gc跟踪的容器对象之间的引用关系图”。因为普通对象如果引用计数正常工作，早就被回收了，压根不需要gc进场。

清除阶段：gc把那些未被标记的对象判定为垃圾，直接回收。这样循环引用的死结就被解开了——两个Node对象虽然互相引用，但从根出发谁也够不到，所以一起被标记为不可达，一起进回收站。

这里藏着一个技术细节：标记阶段用的是三色标记法（白色代表未访问、灰色代表已访问但邻居未处理、黑色代表已访问且邻居已处理）。这个算法能避免引用环导致的递归死循环，因为每个对象只会被处理一次。

3.3 分代回收：既然GC有用，为什么要分成三代

如果每次GC都对所有容器对象做一次全量扫描，那随着程序内存占用上升，扫描耗时会越来越不可控。但观察实际运行的程序你会发现，绝大多数对象都是“朝生夕死”——创建出来没多久就没用了，真正能活很久的是少数。于是CPython采用了一个很简单的启发式策略：按存活时间把对象分成三代，越年轻的对象越频繁地被扫描，越年老的对象扫描频率越低。

默认情况下，Python用gc.get_threshold()可以查看到三代回收的阈值：

import gc print(gc.get_threshold()) # 输出 (700, 10, 10)

注意这两个10的意义不太一样。完整说法是：

• 当新创建的对象数量减去0代回收时释放的对象数量，超过700时，触发一次0代回收。
• 当0代回收次数累计到10次时，触发一次1代回收。
• 当1代回收次数累计到10次时，触发一次2代回收。

你可以这样理解：0代是“新手村”，新创建的容器对象都先放到这里。0代每次回收后幸存下来的对象，升入1代；1代回收后幸存的对象，升入2代。2代是“养老院”，回收频率最低，里面的对象都是经过多轮淘汰的“老兵”。

这套策略之所以高效，是因为它把扫描的注意力和时间花在了“最可能产生垃圾”的年轻代，而老年代对象一般要么是长期存活的长生命周期对象（比如缓存、单例），要么虽然最终也会死但死亡频率很低，不值得频繁扫描。

3.4 分代回收触发的时机

分代回收的触发条件除了上述阈值之外，还受一个叫做gc.set_threshold的“调节机制”影响。CPython会用每一代的实际回收效果动态微调下一次回收的触发阈值，避免某些极端情况下回收过于频繁或者过于稀疏。

实操中你还可以手动干预回收时机。比如在长时间运行的脚本里，你可以定期调用gc.collect()强制做一次回收。如果不想让Python的垃圾回收器在关键时刻干扰程序，也可以gc.disable()暂时关闭自动回收，等高峰期过了再手动gc.collect()。但我不建议普通业务代码这么干，因为一旦关闭自动回收，循环引用的垃圾就会积攒到内存里，最终大概率比GC的少量开销更危险。

3.5 __del__方法和循环引用为什么是历史难题

这里必须提一个古老的“坑”，也是Python老程序员们津津乐道的话题：循环引用中如果某个对象定义了__del__方法，Python 3.3之前是无法回收它的。

原因在于__del__方法给了对象一个“复活”的机会。对象在回收前要执行__del__，但__del__里万一又把对象引用给了别的变量呢？这个对象的引用计数就又大于0了，GC没法安全地释放它。稳妥起见，旧版本Python会把这些对象丢进一个gc.garbage列表里，留给开发者手工处理。

Python 3.4引入了PEP 442，从语言层面解决了一部分问题：现在即使对象定义了__del__，在大多数情况下也能被正确回收，因为解释器会先安全地执行__del__，然后再进行最终清理。但在__del__中复活对象仍然是非常不推荐的行为，它比循环引用本身更容易制造诡异的内存问题。我的建议很简单：除非你明确知道自己在做什么，否则不要在类里写__del__，用with或try/finally来管理资源才是正确姿势。

4. 内存分配器：Python对象在堆里到底是怎么存放的

4.1 为什么Python进程的内存涨上去就不降下来

很多开发者都遇到过这个问题：脚本占用了1G内存，处理完数据后del掉大变量，用系统监控看，内存还是停留在1G附近。于是第一反应是“有内存泄漏”。但实际上，这很可能不是泄漏，只是Python的内存分配器把内存“藏”起来了。

CPython内部内置了一个名为pymalloc的内存分配器，专门负责管理小块内存的分配与释放。它和系统层malloc的区别在于：Python对象的创建和销毁非常频繁，如果每个小对象都直接向操作系统申请内存、再逐个归还，性能会非常差。所以pymalloc做了一层缓存，对象释放后，内存块不立即还给操作系统，而是留在内存池里供后续新对象复用。

这就是内存“不降”的真相——不是你的程序还在占用，而是内存池提前囤了一批“二手房”，下次创建同尺寸对象时直接搬进去住，不用重新向系统申请。

4.2 内存池的三级结构

pymalloc的经典结构分为三层。最底层是arena，它是一块较大的连续内存区域（通常是64KB），由系统malloc一次性分配。中间层是pool，每个pool被划分为若干个大小相同的block。block是实际分配出去的最小单位。

CPython把内存池按块大小分成不同的“尺寸类别”（size class），比如8字节、16字节、24字节……直到512字节。如果一个对象的大小小于等于512字节，pymalloc就会从对应的尺寸池里挑一个空闲block来分配；大于512字节的直接交给系统malloc处理。

import sys # 查看不同对象的真实内存占用 print(sys.getsizeof([])) # 40/56，视64位版本而定 print(sys.getsizeof({})) # 64 print(sys.getsizeof([1,2,3])) # 88

所以在CPython里，一个空列表并不真的“空”，它有个头部结构体，占几十个字节；当列表扩容时，会一口气多分配一些容量来摊薄重新分配的成本。这些都是内存池在背后操作的对象块。

4.3 内存池的存在对GC是好事还是坏事

这里有个容易混淆的点：内存池和垃圾回收是两码事。GC负责判断哪些对象“逻辑上已死”，而内存池负责管理“物理上怎么复用这些内存块”。一个对象被GC回收，并不代表它的内存立刻回到操作系统手里——它可能只是回到内存池的空闲链表里，等着下一个对象来认领。

这个设计带来的好处是分配速度快、碎片少；坏处是你从外部看到的进程内存占用曲线是只升难降的。即便业务上已经没有多少存活对象，进程的RSS（常驻内存集）也可能维持在一个高位。很多人在这一步误判为泄漏，然后开始瞎折腾加内存、重启服务，其实完全没必要。

如果你的服务对内存占用峰值特别敏感，可以用PYTHONMALLOC=malloc环境变量绕过pymalloc，直接把所有分配交给系统的malloc。代价是Python对象的创建和销毁变慢，所以一般只有在内存调优或定位问题时才这么干。

PYTHONMALLOC=malloc python my_script.py

这个环境变量还可以配debug，比如PYTHONMALLOC=debug会开启分配器调试模式，能检测到内存越界、重复释放等C语言层面的内存错误，对排查某些C扩展引起的问题很有帮助。

5. 实战：用gc模块和可视化工具定位内存泄漏

5.1 先学会用gc模块观察回收状态

gc模块是排查内存问题最趁手的底牌，可惜很多人只会gc.collect()这一招。其实它提供的观测手段非常丰富，我列个表给你：

实际排查时可以这样用：

import gc # 看看当前三代里各有多少被追踪的容器对象 print(gc.get_count()) # 强制回收所有代 collected = gc.collect() print(f"本次回收了 {collected} 个对象")

如果gc.collect()前后gc.get_count()几乎没有变化，说明循环引用垃圾积累其实不多。真正要警惕的是gc.get_objects()里出现大量预期之外的长生命周期对象。

5.2 用一个模拟场景复现循环引用泄漏

我写一个典型的“伪泄漏”示例：业务里定义了一个带循环引用的结构，并且对象一直被某个全局列表间接持有，导致GC永远清不掉。

import gc import objgraph class Task: def __init__(self): self.batch = None class Batch: def __init__(self): self.tasks = [] # 模拟持续创建，但因为某些原因这些Batch/Task互相引用 active = [] for _ in range(10000): batch = Batch() for _ in range(3): task = Task() task.batch = batch batch.tasks.append(task) active.append(batch) # 假设业务完成后，将active清空 del active gc.collect() # 看现在内存里还剩多少Task/Batch print("Task实例数:", len(objgraph.by_type('Task'))) print("Batch实例数:", len(objgraph.by_type('Batch')))

注意这里我手动调用了gc.collect()，如果一切正常，Task和Batch都应该被回收，输出应当为0。但如果因为这些对象被某个全局缓存或闭包意外引用着，它们的数量就会居高不下。objgraph在这里能直接告诉你某个类型在内存里有多少实例，这是判断泄漏类型分布的最快手段。

5.3 objgraph和pympler怎么用

objgraph这个第三方库是Python内存排查的“照妖镜”。它有几个核心功能特别适合定位泄漏源。一个是objgraph.show_most_common_types()，直接打印当前进程里对象数量最多的类型，一眼就能看出有没有异常对象堆积。另一个是objgraph.find_backref_chain(obj, max_depth)，能找出是谁在最底层持有这个对象，把链条可视化出来。

安装很简单：

pip install objgraph

使用示例：

import objgraph objgraph.show_most_common_types(limit=15)

如果你需要图形化的引用链，objgraph.show_refs([obj], max_depth=3, filename='refs.png')可以在本地生成一张引用关系图。这不依赖graphviz也能在大部分环境下跑通，调试时非常直观。

pympler则更偏统计。它有个summary模块，能够按类型统计内存占用情况并生成概要；还有个tracker模块，可以对两次快照之间的对象变化做对比，找出到底新增了哪些对象。

from pympler import summary, muppy all_objects = muppy.get_objects() summ = summary.summarize(all_objects) summary.print_(summ)

这套对比思路很像拍照前后对比——启动时拍一张，跑一段业务后再拍一张，差异部分就是泄漏嫌疑区。相比直接看单个对象大小，这种方式对大对象泄漏的定位更快。

5.4 tracemalloc：盯住内存分配的调用栈

如果你的问题是“内存持续增长，但不知道是谁分配的”，那么tracemalloc是首选。它是Python标准库，会记录每个内存分配发生的Python调用栈，能精确到文件行号。

import tracemalloc tracemalloc.start(10) # 你的业务代码，比如读文件、处理数据、构建结果 data = [bytearray(1024 * 1024) for _ in range(100)] snapshot = tracemalloc.take_snapshot() top_stats = snapshot.statistics('lineno') for stat in top_stats[:10]: print(stat)

输出会是这样的格式：

/path/to/script.py:6: size=100 MiB, count=100, average=1 MiB

直接告诉你分配发生在哪一行，分配了几次，累计多大。对于追查“哪个函数偷偷把内存吃掉了”的场景，这比先用objgraph然后人肉找调用链快得多。

我在实际排查中通常组合用这三件套：tracemalloc找分配源头，objgraph看对象类型分布和引用链，gc.get_referrers查“到底是谁还拿着这个对象”。三者组合下来，绝大多数内存问题都能在半小时内定位到根因。

6. 写代码时最容易踩的内存坑及应对习惯

6.1 坑一：为临时结果构建了超大的全局容器

这是爬虫和数据处理代码里最眼熟的坑。很多人喜欢把抓到的所有数据先塞进一个全局列表，最后再统一分析。数据量小的时候没感觉，数据量一大，几个G的内存瞬间就没了。

正确的姿势是尽可能地用迭代器或生成器，处理完一条丢一条，不要用一个中间列表把所有结果都囤起来。比如用requests流式读取接口响应、用pandas分块读取CSV，数据边读边处理，内存占用就能保持在一个稳定水位。

# 不推荐：把所有数据加载进内存 all_data = [transform(item) for item in huge_iterable] # 推荐：流式处理 def process_stream(items): for item in items: yield heavy_transform(item) for result in process_stream(huge_iterable): save(result)

6.2 坑二：类变量、默认参数和闭包意外持有长生命周期引用

这三个位置往往能“神不知鬼不觉”地把对象生命周期拉长。类变量是典型的例子——只要类本身活着，类变量就永远不走；默认参数在函数定义时就被创建，如果默认参数是个可变对象，所有调用共享同一份；闭包则会把外层变量牢牢拽住，哪怕外层函数已经返回。

# 反面教材：默认参数持有可变对象 def append_item(item, cache=[]): cache.append(item) return cache # 每次调用都在同一个缓存列表里追加 print(append_item(1)) # [1] print(append_item(2)) # [1, 2]

这些设计在某些场景下有它的用途，但如果这个列表内存链接着大对象，基本就等于写了个隐形的内存持有者。排查泄漏时，记得检查这些“无意识的引用持有点”。

6.3 坑三：缓存永远只增不减

业务代码里很容易出现各种缓存：字典缓存查询结果、列表缓存历史数据、装饰器缓存函数输出。缓存本身是为了省开销，但如果不加容量上限，它本质就是一个缓慢膨胀的内存仓。

在写缓存之前先问自己三句话：这个缓存需要多大？什么时候失效？如果超过上限怎么办？实际工程中，我推荐优先使用functools.lru_cache，它自带最大容量淘汰策略；如果业务需要更复杂的淘汰规则，可以基于OrderedDict自己实现一个简单的LRU，或者直接用Redis这类外部缓存中间件。尽量别只写一个app_cache = {}然后永不清理。

6.4 坑四：以为del了变量就等于释放了内存

del只是让引用计数减一，不等于立刻把内存还给操作系统——前面讲过内存池会缓存空闲块。而且在函数内部del局部变量通常没有多少意义，因为函数返回时所有局部变量本来就会被销毁。

但在一种情况下del很有用：持有超大对象的场景。比如你把一个几百MB的DataFrame放在某个变量里，业务跑完了还需要继续用这个函数，那提前del并调用gc.collect()，能加速内存复用，也能降低进程峰值内存。

def process_in_batches() -> None: for i in range(100): df = load_huge_df(i) result = compute(df) save(result) del df # 降低峰值内存，让下一轮迭代可以有更多空闲池可用

6.5 什么时候该用weakref

weakref是专门为“想引用对象、但不想影响对象生命周期”的场景设计的。最典型的场景就是缓存——希望能在对象仍存活时拿到它，但又希望它在没有强引用时能被正常回收。

import weakref class Cache: def __init__(self): self._data = weakref.WeakValueDictionary() def put(self, key, value): self._data[key] = value def get(self, key): return self._data.get(key)

WeakValueDictionary的底层原理就是：当目标对象的强引用全部消失后，字典里的条目自动消失。这个特性在管理大量生命周期不定的对象时非常省力，但要记住它有几个限制，比如值对象必须是可弱引用的（绝大多数类实例可以，但某些内建类型如list、dict默认不行），而且弱引用不会阻止对象被回收，所以get可能随时返回None。

6.6 提前调优的建议：分代阈值该改吗

gc.set_threshold(700, 10, 10)默认值对绝大多数程序是够用的。什么情况下需要调整？如果你发现程序里会批量创建大量容器对象、然后又批量放弃它们，可以适当调低0代阈值，让GC更灵敏地回收年轻代；如果程序里容器对象数量特别大，而且大部分寿命很长，可以调高阈值，降低GC扫描频率。

但我得提醒一句：在没看过GC扫描耗时的情况下，不建议凭感觉调。先开gc.DEBUG_STATS看看每代回收的耗时和吞吐：

import gc gc.set_debug(gc.DEBUG_STATS) # 然后跑业务

输出会显示各代回收的耗时与增量，据此再决定阈值往哪个方向调。盲目把阈值调到很大，可能让循环引用垃圾在年轻代沉积过多，导致某次GC一次性工作太多，反而卡顿。

6.7 从内存泄漏角度看：该不该考虑PyPy或其他运行时

CPython的引用计数+分代回收是组合拳，但如果你跑的是PyPy，垃圾回收器就完全是另一套设计了。PyPy采用的GC策略更接近JVM那种纯追踪式回收，能处理循环引用，但对短生命周期对象的响应速度不如CPython的引用计数那么及时。如果你主要跑的是长任务脚本、批处理、计算密集型任务，PyPy可能让内存占用更平稳；但如果你写的是强调低延迟的服务端应用，CPython的即时回收特性可能更合适。

对于绝大多数场景，我不建议为了“内存管理更好”这一点就切换解释器，因为你还要考虑C扩展兼容性欠佳等代价。

7. 最后再分享几个关于内存调优的实操心得

排查内存问题这几年，我最大的体会是：先确认是不是真泄漏，再动手改代码。很多人看到内存曲线一路向上就慌了，直接上各种“优化”方案，结果改了个寂寞。最正确的第一步永远是做诊断：用tracemalloc定位增长来源，用gc.get_count()确认循环垃圾是否在堆积，用objgraph看对象类型的分布。只有数据说明确有问题，才谈得上修复。

另外一个容易被忽略的点是：内存监控最好做“相对值”而不是“绝对值”。单纯看进程RSS没有意义，因为内存池缓存、缓冲区、操作系统页缓存都会让数值虚高。你要关心的是在无外部干扰、业务负载稳定的情况下，内存是不是随业务周期“一轮比一轮高”。如果是，那说明有跨业务周期存活的引用；如果每轮结束后都回落到同一水位，那只是正常的分配器缓存行为而已。

顺带说个跟Python版本有关的小建议：能用新版本就用新版本。CPython每个大版本几乎都会优化内存管理细节，比如3.4的PEP 442解决__del__与循环引用的冲突、3.8开始优化了整数的内部表示、3.11对对象布局和内存分配器做了大量微调。同一段代码，从3.8跑到3.12，内存占用可能就能下降个10%到20%。如果你还坚守在3.6或者3.7，内存问题会更频繁地找上门来。

如果读到这里，你已经在自己的项目里找到了内存异常的根源，那这篇文章的目的就达到了。从引用计数到分代回收，从内存池到排查工具，这些机制本质上就是在回答一个问题：你的对象到底被谁握着，什么时候才愿意松手。把这个脉络理清，大部分内存问题都难不倒你。