Python asyncio 任务完成后对象还不释放：从协程帧定位引用链

先给结论：Python asyncio 任务完成后，业务对象仍未释放，通常不是“垃圾回收坏了”，而是还有一条强引用没有断。最常见的持有者是仍被保存的 Task、暂停中的协程帧、任务结果或异常回溯，以及保存任务的业务容器。移动一个 await 只改变了协程何时挂起和哪些局部变量仍在帧里，不等于产生了稳定的内存管理规则。

排查时要把“Task 会不会被事件循环回收”和“业务对象是否还可达”分成两条线。下面按复现、观察、收口推进。

先区分 Task 消失与业务对象存活

asyncio.create_task() 会把协程包装成 Task 并调度执行，但官方文档特别提醒：事件循环只保留对 Task 的弱引用。也就是说，后台任务如果没有别的强引用，可能在完成前消失；这和任务内部创建的业务对象是否释放，是两个不同问题。

一条更实用的静态关系是：事件循环指向 Task，Task 关联协程帧，帧中的局部变量指向业务对象；Task 完成后还可能保存返回值或异常，而返回值也可能继续指向业务对象。图1把这几个边界放在一起，排查时先问“哪条线是强引用”，再问“对象什么时候离开作用域”。

用最小复现确认 await 改变了哪条引用链

不要先在完整服务里反复调用 gc.collect()。可以用弱引用只观察对象是否仍可达，并刻意保留任务变量：

import asyncio
import gc
import weakref

class Payload:
    pass

async def worker(hold):
    payload = Payload()
    hold.append(weakref.ref(payload))
    await asyncio.sleep(0)
    return payload

async def main():
    hold = []
    task = asyncio.create_task(worker(hold))
    await task
    gc.collect()
    print("task done:", task.done())
    print("alive with task:", hold[0]() is not None)
    task_result = task.result()
    del task_result, task
    gc.collect()
    print("alive after task release:", hold[0]() is not None)

asyncio.run(main())

这个实验的重点不是固定输出，而是逐个删除强引用后再观察。只要 task.result() 仍指向 Payload，任务对象就可能成为持有链的一部分。把 await asyncio.sleep(0) 移到局部变量创建前后，也可以比较暂停点是否让某个局部变量跨过挂起边界；但结果会受实现、优化和其他引用影响，不能把一次差异直接写成语言保证。

从协程帧与 Task 结果反查持有者

当任务还在等待 I/O 或定时器时，先检查协程对象的 cr_frame，再看 f_locals：

coro = task.get_coro()
frame = getattr(coro, "cr_frame", None)
if frame is not None:
    print(frame.f_code.co_name)
    print(sorted(frame.f_locals))

if task.done():
    if task.cancelled():
        print("cancelled")
    else:
        try:
            print("result type:", type(task.result()).__name__)
        except BaseException as exc:
            print("exception type:", type(exc).__name__)

print("referrers:", len(gc.get_referrers(target)))

cr_frame 适合观察“暂停时还留着什么”；任务完成后，协程帧可能已经清理，不能因为看不到帧就断言没有引用。此时转向 task.result()、task.exception() 和 add_done_callback() 注册的回调。异常对象还可能带着 traceback，traceback 又会关联执行帧，所以失败任务比成功任务更容易出现意外持有。

gc.get_referrers() 只能作为定位线索：调试器、临时变量和列表本身也会制造引用。每次打印后删除诊断变量，必要时在独立的最小进程中重复，避免“为了检查对象而把对象留下”。

收口生命周期：清理容器、回调和异常

修复的方向不是“强行让 GC 更积极”，而是让所有权明确。需要等待并传播异常的并发工作优先放进 asyncio.TaskGroup；它会在上下文退出时等待任务，并在子任务失败时取消兄弟任务。真正的后台任务若必须脱离当前请求，可放入集合，并用完成回调移除：

background = set()

def start(coro):
    task = asyncio.create_task(coro)
    background.add(task)
    task.add_done_callback(background.discard)
    return task

如果不需要返回大对象，就不要把它作为 Task 结果返回；如果任务失败，及时读取异常并记录必要信息，避免 traceback 长期挂在自定义错误集合里。请求结束时也要清理请求级列表、缓存和回调闭包。

最后做一次边界复盘：对象在“暂停态”存活，重点看帧和局部变量；在“完成态”存活，重点看结果、异常、回调和外部容器；只有这些都断开后，才有必要继续检查全局缓存、线程局部变量或第三方库。

相关问题

为什么只保存 coroutine 不够？ coroutine 对象本身不是已调度的 Task。要并发运行，需要 create_task() 或其他调度 API，并按生命周期保存 Task 引用。

TaskGroup 会自动释放返回对象吗？它负责结构化等待和异常传播，不会替你清空外部容器、缓存或调用方保存的结果。所有权仍需由业务代码设计。

看到对象还活着就该调用 gc.collect 吗？不应把它当修复手段。先用弱引用和持有者线索找出强引用，确认引用断开后再用 GC 做实验性观察。