内存泄漏典型现象包括进程rss持续上涨、对象数量只增不减、gc后堆内存不回落；可用tracemalloc对比快照定位泄漏行，objgraph辅助分析引用链。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜
内存泄漏的典型现象有哪些
跑着跑着就卡死、OOM崩溃、GC频率越来越高但堆内存下不去——这些不是“机器慢”，而是内存泄漏在敲门。Python里最常被误判为“内存大”的其实是引用没释放，比如全局缓存没清理、闭包持有了不该持有的大对象、或者用weakref时忘了手动断开。
- 用
psutil.Process().memory_info().rss观察进程RSS持续上涨，且不随gc.collect()回落 - 调用
objgraph.show_growth()发现某类对象数量只增不减（如dict、list、自定义类实例） - 用
tracemalloc定位到某行json.loads()或pandas.read_csv()后内存突增且不释放
用tracemalloc快速定位泄漏源头
tracemalloc是Python标准库里最轻量也最准的内存快照工具，不用装第三方包，适合线上环境最小化介入。关键不是“看哪里分配多”，而是“对比两次快照，看哪些分配没被回收”。
- 启动时调用
tracemalloc.start(25)（25表示记录调用栈深度） - 运行可疑逻辑后，用
snapshot1 = tracemalloc.take_snapshot()拍第一张照 - 再执行一轮相同操作，再拍
snapshot2，然后top_stats = snapshot2.compare_to(snapshot1, 'lineno') - 重点关注
size_diff > 0且count_diff > 0的条目，尤其是反复出现的__init__.py或dataframe.py行号
示例输出中如果看到my_module.py:42: size=+2.1 MiB, count=+123，那就直接去查第42行——大概率是循环里新建了没销毁的pd.DataFrame或io.StringIO。
常见泄漏模式与绕过写法
很多泄漏不是代码错，而是对Python对象生命周期理解偏差。比如以为del obj就释放内存，其实只是删引用；又比如用lru_cache缓存大对象却没设maxsize，结果越积越多。
- 避免在模块级或类属性里存大字典/列表，改用函数内局部变量 + 显式
del或None赋值 - 用
pandas处理完数据后，及时del df并调用gc.collect()（尤其在循环中） - 异步场景下，
async with或async for没正确退出会导致StreamReader等资源滞留，务必检查__aexit__是否被调用 - 若用了
ctypes或C扩展，泄漏往往发生在C层，需用valgrind或ASan排查，Python层工具无效
为什么objgraph比pympler更适合初筛
objgraph不依赖C扩展，安装即用（pip install objgraph），而且它能直观显示“谁引用了谁”。当你看到某个本该被回收的对象还被Frame或function强引用着，基本就锁定了闭包或调试器残留问题。
- 先跑
objgraph.show_most_common_types(limit=20)看哪类对象异常多 - 再用
objgraph.find_backref_chain(obj, objgraph.is_proper_module, max_depth=10)追引用链 - 特别注意
frame对象里的f_locals——Jupyter或pdb调试后忘记退出，就会把整个locals字典钉在内存里
真正难的是那些跨线程、跨协程、带弱引用回调的场景，这时候tracemalloc和objgraph都只能给你起点，最终还得靠复现路径+最小化代码反推逻辑闭环。
