python内存只涨不降主因是强引用未释放，可用tracemalloc拍快照对比定位分配热点，objgraph查引用链，修复需切断强引用（如lru缓存、weakref、显式del、with管理pil资源）。
Python 数据处理中出现内存只涨不降，大概率不是 GC 失效，而是对象被某个“看不见的变量”一直强引用着——比如全局列表、类属性、闭包捕获、未注销的回调，或者 PIL / NumPy 对象内部持有的大缓冲区。
tracemalloc 定位增长源头：别猜，直接看哪行在疯狂分配
先确认是不是真泄漏：用 top 或 ps aux --sort=-%mem 观察进程 RSS 是否随处理量线性上涨。如果是，立刻启用 tracemalloc。
关键操作不是“全程开启”，而是“拍快照对比”：
- 在数据处理循环前调用
tracemalloc.take_snapshot()记为snapshot1 - 跑完几轮（比如 100 条记录）后，再拍一次
snapshot2 - 用
snapshot2.compare_to(snapshot1, 'lineno')查差异最大的前 10 行
常见陷阱：
-
tracemalloc.start()必须在所有业务代码之前调用，否则漏掉初始化分配 - 不要在循环里反复
take_snapshot()—— 开销大，且快照太多难比对 - 输出里的
size是累计分配量，count是分配次数；优先盯size持续变大的行
objgraph 找出“谁在拽着它不放”：查引用链比读代码快十倍
一旦知道是 MyDataProcessor 或 PIL.Image 类型暴涨，下一步就是问：“为什么没被回收？”
用 objgraph 直接看引用关系：
-
objgraph.show_most_common_types(limit=20)确认哪些类型数量异常多 -
objgraph.by_type('PIL.Image')拿到实例列表，挑前几个做分析 -
objgraph.show_backrefs([img], max_depth=3, filename='backref.png')生成图，打开就看到谁 hold 着它
典型发现：
- 全局缓存字典（如
CACHE = {}）没设maxsize或 TTL - 类的
self._cache属性在实例生命周期内不断追加，但实例本身被其他地方长期持有 - 闭包里捕获了大数组或 DataFrame，而闭包又被注册成回调（比如
threading.Timer或事件监听器）
gc.collect() + gc.garbage 不是万能解药：小心 __del__ 和弱引用误用
手动触发 gc.collect() 有时能让内存回落，但这只是表象。如果回落不彻底，说明有对象卡在 gc.garbage 里 —— 这些是 GC 发现但无法清理的循环引用孤儿。
检查方法：
- 执行
gc.collect()后，打印len(gc.garbage) - 若 > 0，遍历
gc.garbage看类型：print(type(x))
高危信号：
- 对象定义了
__del__方法 → GC 放弃回收，直接扔进gc.garbage，永不释放 - 用了
weakref.ref但忘了调用ref()解引用，导致弱引用对象本身成了新泄漏点 - NumPy 数组的
.base引用父数组，而父数组被全局变量持有
修复必须切断强引用链：LRU、weakref、显式 del 缺一不可
定位到引用源后，修复不是“加个 gc.collect()”，而是精准切断强引用：
- 全局缓存一律换成
@lru_cache(maxsize=128)或functools.lru_cache，禁用无限增长的dict - 父子对象互相引用时，子对象用
weakref.ref(parent)存 parent，避免循环 - 处理完大对象（如
PIL.Image、numpy.ndarray）后，显式del img并确认无其他变量指向它 - 使用
with管理资源（如Image.open()），或确保.close()被调用 —— PIL 图像不 close，底层像素缓冲区不会释放
最容易被忽略的是：PIL 的 Image.open() 返回对象内部持有一个未释放的文件句柄和解码缓冲区，仅靠 GC 无法释放；必须 img.close() 或用 with Image.open(...) as img:。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
