能,但需程序启动早期启用且避免gc干扰;它只追踪Python对象分配栈,不覆盖C扩展内存,需用compare_to()差分分析并过滤噪音。
能,但有前提:必须在程序启动早期就启用,且不能被 gc.disable() 或频繁的 gc.collect() 干扰。它记录的是 Python 对象的内存分配调用栈,不是底层 malloc 行为,所以对 C 扩展(如 NumPy 数组底层内存、某些 Cython 模块)不敏感——这类内存不会出现在 tracemalloc.get_traced_memory() 的统计里。
常见误判场景:
dict),并非该函数本身有泄漏tracemalloc.take_snapshot() 就直接比对,结果全是累计值,看不出增量变化tracemalloc 默认只跟踪当前线程,需显式设 tracemalloc.start(10, True) 启用跨线程追踪)关键不在“谁占得多”,而在“谁比上次多”。要连续采集快照并做差分比较:
import tracemalloctracemalloc.start(25) # 保存 25 层调用栈
... 运行一段业务逻辑 ...
snapshot1 = tracemalloc.take_snapshot()
... 再运行一次相同逻辑(或持续运行一段时间) ...
snapshot2 = tracemalloc.take_snapshot()
只看新增分配(按 size_diff 降序)
top_stats = snapshot2.compare_to(snapshot1, 'lineno') for stat in top_stats[:10]: print(stat)
注意参数 'lineno':它把相同文件+行号的分配合并,比 'filename' 更精准;若用 'traceback',输出会极长,仅调试极端情况时启用。
容易忽略的细节:
compare_to() 返回的 stat.size_diff 是字节差值,负数表示这次变少了(比如对象被释放),但 tracemalloc 不保证释放一定被捕捉(尤其循环引用未及时 gc)size_diff 失真,建议中间加 gc.collect() 强制清理(但别在热循环里滥用)默认情况下,所有 Python 分配都会被记录,包括 logging 格式化字符串、str.format() 中间对象、列表推导式临时容器等。这些噪音会让真实问题被淹没。
推荐做法是结合 filter 和代码标记:
tracemalloc.Filter(False, '/lib/python*/logging/*.py')
# TRACEMALLOC_START,然后用正则从 stat.traceback.format() 中提取含该标记的调用栈str 对象,tracemalloc 会如实记录示例过滤:
filters = [
tracemalloc
.Filter(False, ''),
tracemalloc.Filter(False, '/logging/'),
tracemalloc.Filter(True, 'myapp/'), # 只保留自己代码
]
tracemalloc.start(10, filters=filters) psutil.Process().memory_info().rss 给你进程总物理内存,但无法告诉你哪行 Python 代码导致;memory_profiler 的 @profile 装饰器适合单函数分析,但开销大(每行都插桩),且对异步、多线程支持弱。
tracemalloc 的不可替代性在于:
memory_profiler 的 50%+;foo.py:42,而不是笼统的 “in 但它不解决“为什么对象没被释放”——那得配合 gc.get_referrers() 或 objgraph 查引用链。tracemalloc 告诉你“谁申请了”,后续动作得你自己跟。