Python异步内存泄漏排查方法

Python异步开发中内存泄漏常隐匿于看似无害的代码细节：未取消的asyncio.Task会顽固持有协程帧和变量引用，导致RSS内存持续缓慢增长；async with/for因异常中断而跳过清理逻辑，使连接池、缓冲区等底层资源无法释放；滥用__del__或weakref试图自动清理异步资源反而失效，因事件循环不保证及时回收且__del__无法安全await；真正有效的排查必须深入运行时——用asyncio.all_tasks()揪出悬停任务，通过task.get_coro()和gc.get_referrers()定位残留对象与引用链，甚至手动遍历第三方库的私有属性挖掘“文档未说明”的缓冲区泄漏。内存不会凭空消失，它总在某个未被正确关闭的协程、未被 awaited 的cancel、或未被捕获异常跳过的__aexit__里悄然堆积。

asyncio.create_task() 后忘记 cancel() 导致任务悬停

未取消的 asyncio.Task 会持续持有协程帧、局部变量和闭包引用，哪怕协程已退出或 await 的对象早已销毁。典型现象是：程序空闲时 RSS 内存缓慢上涨，psutil.Process().memory_info().rss 持续增长，且 asyncio.all_tasks() 返回大量状态为 Pending 或 Running 的任务。

• 用 asyncio.create_task() 启动任务后，必须确保它有明确的生命周期管理——比如在 __aexit__、finally 块或信号处理中调用 task.cancel()
• 避免在循环里无节制地 create_task() 而不加限流或等待完成，例如：for url in urls: asyncio.create_task(fetch(url)) 应改为 await asyncio.gather(*[fetch(u) for u in urls]) 或配合 asyncio.Semaphore
• task.cancel() 不等于立即释放内存；需后续 await task（或忽略 CancelledError）让协程真正退出帧栈，否则任务仍卡在 Cancelled 状态并持引用

async with / async for 中异常跳出导致上下文未退出

异步上下文管理器（如 aiohttp.ClientSession、aiomysql.Pool）或异步迭代器（如 aiosqlite.Cursor）若在 async with 块内抛出未捕获异常，__aexit__ 可能不执行，底层连接/缓冲区/临时对象无法释放，形成间接内存泄漏。

• 所有 async with 块都应包裹在 try/except 中，或确保异常被上层捕获并允许正常退出上下文
• 不要在 async for 循环中用 break 或 return 跳出而不先 aclose() 迭代器（部分库支持，但非通用）；更稳妥的做法是用 asyncio.shield() 包裹关键清理逻辑
• 检查所用异步库是否实现了完整的 __aexit__ 清理——比如旧版 aiofiles 在异常下可能漏关文件句柄，升级到 23.2+ 更可靠

用 weakref 或 __del__ 试图“自动”清理异步资源

在协程对象、Task 或异步类实例上依赖 __del__ 或 weakref.finalize 触发 cancel() / aclose()，大概率失效。因为 asyncio 的事件循环不保证及时回收，且 __del__ 在循环引用存在时根本不会调用。

• 绝不在 __del__ 中调用 await 或任何需要事件循环的操作；它运行在任意线程，且无 event loop 上下文
• weakref.finalize 的回调是同步函数，不能直接 await，也不能安全调用 loop.create_task()（loop 可能已关闭）
• 正确做法是显式暴露 close() 或 shutdown() 方法，并由使用者负责调用——比如 FastAPI 的 lifespan 事件、Starlette 的 on_shutdown

排查时别只看 top，要 inspect 运行中的 Task 和 Refs

内存泄漏不是靠 RSS 数值猜出来的。得进进程内部看谁还活着、谁还被谁拽着。

• 用 asyncio.all_tasks(loop) 列出所有存活 Task，过滤掉 done() 为 True 的，再对剩余 Task 调用 task.get_coro() 查看其协程名和当前 cr_frame.f_locals，常能发现残留的大型数据结构（如未清空的 list 缓存、未 close 的 BytesIO）
• 用 gc.get_referrers(obj) 定位谁在引用可疑对象；注意 Task 本身会被 asyncio._ready、_scheduled 等内部队列强引用，得结合 obj.__class__ 和 type(obj) 判断是否属于业务逻辑
• 生产环境慎用 tracemalloc + asyncio，因为 tracemalloc.start(25) 会影响协程调度性能；建议在复现环境用 sys.settrace 配合 asyncio.current_task() 打点关键路径

最麻烦的泄漏往往藏在第三方异步库的私有字段里，比如某个 _buffer 属性被意外保留了 10MB 数据却没文档说明——这时候只能靠 obj.__dict__ 一层层扒，别指望日志或文档提前告诉你。

好了，本文到此结束，带大家了解了《Python异步内存泄漏排查方法》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！