python异步任务泄漏排查需依次检查：一、未await的协程对象；二、未取消的pending task；三、第三方库未关闭的资源；四、未完成的future与未取消的回调；五、协程栈循环引用。
如果您的 Python 应用在长时间运行后内存持续增长或协程数量异常增加，可能是异步任务未被正确清理导致的任务泄漏。以下是排查此类问题的常用思路：
一、检查未 await 的协程对象
直接调用协程函数（如 my_coro()）而不使用 await 或 asyncio.create_task() 会生成一个未被调度的协程对象，该对象若未被显式销毁或引用释放，将长期驻留内存。
1、在代码中搜索所有协程函数调用位置，确认是否遗漏 await 关键字。
2、使用 sys.getrefcount() 检查可疑协程对象的引用计数是否异常偏高。
立即学习“Python免费学习笔记（深入）”；
3、在关键路径添加日志，打印 coro.cr_running 和 coro.cr_awaited 属性状态，识别已创建但未启动或未完成的协程。
二、定位未取消的 pending Task
通过 asyncio.all_tasks() 获取当前事件循环中所有活跃 Task，可发现已提交但长期处于 pending 状态、未被 await 或 cancel 的任务，这类 Task 会持续持有其协程栈和局部变量引用，造成内存与资源泄漏。
1、在程序关键节点插入调试代码：for t in asyncio.all_tasks(): if not t.done() and not t.cancelled(): print(f"Pending task: {t}")。
2、使用 task.get_coro() 获取底层协程，进一步调用 cr_frame.f_locals 分析其持有的大对象引用。
3、对已确认无需继续执行的 pending Task，主动调用 t.cancel() 并随后 await asyncio.gather(*pending_tasks, return_exceptions=True) 确保清理完成。
三、审查第三方异步库的资源生命周期
部分异步库（如 aiohttp、aiomysql、redis-py 的 async 版本）内部维护连接池或后台心跳 Task，若未按文档要求显式调用 close() 或 aclose()，其关联的 Task 和 socket 句柄可能持续存在。
1、检查所有异步客户端实例化位置，确认是否在作用域结束前调用了对应的异步关闭方法。
2、使用 tracemalloc 结合 asyncio.get_event_loop().get_debug() 启用事件循环调试模式，捕获未关闭资源的创建堆栈。
3、在应用退出前统一执行 await client.aclose() 或 await session.close()，而非仅依赖析构函数。
四、监控事件循环中残留的 Future 与 Callback
手动创建的 asyncio.Future 或通过 loop.call_soon()、loop.call_later() 注册的回调，若未被 set_result/set_exception 或未被取消，会导致其绑定的闭包和上下文长期无法回收。
1、遍历 asyncio.Task.all_tasks() 和 loop._scheduled（需启用 debug 模式）查看未触发的定时回调。
2、检查所有 loop.create_future() 调用点，确认每个 Future 均有明确的完成路径且无条件分支遗漏。
3、对注册的延迟回调，保存其返回的 Handle 对象，并在不再需要时调用 handle.cancel()。
五、分析 GC 无法回收的循环引用协程栈
当协程内部捕获了自身所在类实例、或通过闭包持有了外层异步函数的帧对象，可能形成跨协程的循环引用，导致垃圾回收器无法及时释放内存。
1、启用 gc.set_debug(gc.DEBUG_SAVEALL)，在疑似泄漏后调用 gc.collect() 并检查 gc.garbage 中是否包含 types.CoroutineType 实例。
2、使用 objgraph.show_backrefs() 绘制可疑协程对象的引用图，定位强引用来源。
3、重构高风险协程逻辑，避免在 async def 内部直接引用长生命周期对象，改用弱引用或显式传参解耦。
