psutil是第一道防线，用于监控Python进程RSS内存是否持续增长；tracemalloc定位具体代码行级内存分配；objgraph分析对象引用关系以发现未释放原因。三者分层配合实现生产环境高效泄漏排查。
直接上手就能用，不需要改代码、不依赖生产环境重启——关键在于分层选工具：系统级先筛异常进程，Python进程内再精确定位泄漏点。
用 psutil 搭建轻量级内存增长告警
这是第一道防线，适合长期运行的服务。它不侵入业务逻辑，只监控 RSS 是否持续爬升。
-
psutil.Process().memory_info().rss返回的是真实物理内存占用（单位字节），比virtual_memory()更可靠 - 每 30 秒采样一次，若连续 5 次增长 >20MB，就该触发快照了——避免把缓存抖动误判为泄漏
- 别只看百分比：
%MEM在容器里会失真；RSS 绝对值 + 增长斜率才是判断依据 - 示例片段：
import psutil, time
proc = psutil.Process()
while True:
rss = proc.memory_info().rss / 1024 / 1024 # MB
print(f"[{time.strftime('%H:%M:%S')}] RSS: {rss:.1f} MB")
time.sleep(30)启用 tracemalloc 定位具体哪行代码在疯狂分配
Python 标准库自带，开销低、精度高，但必须在程序启动时就开启，否则漏掉早期分配。
- 调用
tracemalloc.start(25)表示记录最多 25 层调用栈，少于 10 层可能找不到源头 -
take_snapshot()后用statistics('lineno')看行号级分配，不是函数名——list.append这种操作会暴露在调用它的那行 - 两次快照用
compare_to()才能看出“新增”分配，单次快照只反映峰值 - 注意：它不追踪 C 扩展分配（如 NumPy 数组底层内存），这类得靠
objgraph或memory_profiler
用 objgraph 查找“不该活这么久”的对象
当 tracemalloc 显示某类对象分配量大，但你不确定为何没被回收时，就轮到它出场。
立即学习“Python免费学习笔记（深入）”；
- 先跑
objgraph.show_most_common_types(limit=20)，看哪些类型数量异常多（比如几千个dict或未关闭的socket） - 挑一个可疑对象用
objgraph.find_backref_chain(obj, objgraph.is_proper_module, max_depth=10)往上找谁一直强引用着它 - 常见陷阱：模块级字典缓存、信号回调注册后没注销、日志 handler 持有 request 对象
- 安装只需
pip install objgraph，但它依赖graphviz才能画图；纯终端分析时，跳过绘图只用链路分析即可
生产环境慎用 memory_profiler 和 valgrind
它们有用，但代价明确：前者会拖慢程序 3–5 倍，后者根本不能直接跑 Python 解释器（得 wrap 成 C 级别）。
-
@profile装饰器只建议加在怀疑出问题的函数上，别全局启用；用python -m memory_profiler script.py比行内装饰更可控 -
valgrind --tool=memcheck --leak-check=full python -c "import your_module"只适用于极简复现场景；真实服务会因 GIL 和解释器内部结构报大量误报 - 真正生产可用的组合是：
psutil告警 → 自动触发tracemalloc快照 → 导出.snapshot文件离线用objgraph分析
最易被忽略的一点：所有 Python 内存工具都看不到 C 扩展分配的内存（如 PyTorch tensor、Pandas DataFrame 底层 buffer），遇到 RSS 持续涨但 Python 工具无异常，要立刻转向 /proc/<pid>/smaps</pid> 查 Private_Dirty 和 AnonHugePages 字段。
