tracemalloc 模块是 Python 标准库自带的内存追踪工具，适合在开发或测试环境定位 Python 对象导致的内存泄漏，不建议直接在高负载生产环境长期开启。
先说结论：tracemalloc 能通过记录内存分配堆栈来定位泄漏代码行，但会带来性能开销，仅建议在复现场景下短期使用。
- 先定位：确认内存增长是否由 Python 对象引起，排除 C 扩展库或系统缓存干扰。
- 先做：在代码入口导入 tracemalloc 并启动追踪，在关键逻辑前后拍摄快照。
- 再验证：修复引用后观察进程 RSS 内存是否稳定，确认无持续增长。
命令速用版
以下代码片段可直接嵌入脚本开头和检查点，用于快速抓取内存占用最高的前 10 行代码。
import tracemalloc
tracemalloc.start()
# ... 运行你的业务逻辑 ...
snapshot = tracemalloc.take_snapshot()
top_stats = snapshot.statistics('lineno')
print("[ Top 10 ]")
for stat in top_stats[:10]:
print(stat)
为什么会这样
Python 内存泄漏通常是因为对象被意外引用导致垃圾回收器无法释放内存。
tracemalloc 模块通过钩子记录每个内存块的分配位置（文件名和行号），当对象未被释放时，这些记录会累积。它不追踪 C 语言层面分配的内存，只追踪 Python 解释器管理的堆内存。
分步处理
按以下步骤操作可定位具体泄漏代码行，每步完成后需检查输出结果。
步骤 1：启动追踪
在脚本入口或疑似泄漏模块初始化前调用 tracemalloc.start()。若需追踪局部变量，可设置 tracemalloc.start(nframes=5) 增加堆栈深度。
步骤 2：拍摄快照
在业务逻辑开始前拍摄基准快照 snapshot1 = tracemalloc.take_snapshot()，在逻辑结束后拍摄对比快照 snapshot2 = tracemalloc.take_snapshot()。
步骤 3：对比差异
使用 top_stats = snapshot2.compare_to(snapshot1, 'lineno') 获取差异。按 'size' 排序可找到占用增长最大的代码行。
步骤 4：分析引用
检查输出中排名靠前的文件行号，确认是否存在全局列表累积、未关闭的文件句柄或循环引用。
怎么验证是否生效
修复代码后，需通过操作系统级监控确认进程内存不再持续增长。
在 Linux 上使用 top -p <pid> 观察 RES 列，或在代码中使用 psutil.Process().memory_info().rss 定期打印。若运行多次循环后 RSS 数值波动平稳而非单向上升，则泄漏已修复。
常见坑
使用 tracemalloc 时需注意以下限制，避免误判或性能事故。
- 性能开销：开启后会显著降低运行速度并增加内存占用，禁止在高性能要求的生产接口中长期开启。
- C 扩展盲区：numpy 等底层库分配的内存可能不会显示在追踪结果中，需结合其他工具排查。
- 线程安全：虽然模块支持多线程，但在高并发下取快照可能引起锁竞争，建议在单线程或低并发时段执行。
常见问题
tracemalloc 能用于生产环境吗？
不建议长期开启，仅建议在测试环境或生产环境临时调试时短期使用，因为会带来显著性能损耗。
为什么有些内存占用 tracemalloc 没显示？
因为 tracemalloc 只追踪 Python 对象内存，C 扩展库直接申请的内存不在追踪范围内。
如何减少 tracemalloc 自身的内存占用？
调用 start 时限制 nframes 参数，或仅追踪特定线程，用完立即调用 tracemalloc.stop() 释放资源。
参考来源
- Python 官方文档，tracemalloc — Trace memory allocations，https://docs.python.org/3/library/tracemalloc.html