Краткий ответ

Фоновая задача может быть уничтожена сборщиком мусора до завершения, потому что event loop хранит ссылки на задачи только слабо. Поэтому для независимой фоновой работы нужно сохранить задачу в коллекции с сильными ссылками и удалить её оттуда после завершения.

Исторический контекст

Асинхронные библиотеки отделяют планирование работы от владения её результатом. asyncio должен отслеживать задачи, но само наличие задачи в event loop не должно автоматически означать, что приложение обязано удерживать её до бесконечности.

Из-за этого жизненный цикл фоновой задачи должен быть частью архитектуры приложения. Разработчик отвечает не только за запуск корутины, но и за хранение её ссылки, обработку результата и завершение.

Постановка проблемы

Вызов asyncio.create_task планирует выполнение корутины, но возвращаемый объект Task нельзя бездумно выбрасывать. Если на задачу не останется сильных ссылок, она в некоторых состояниях может быть собрана сборщиком мусора до окончания работы.

Последствиями могут стать незавершённая операция, потеря результата и предупреждение о задаче, уничтоженной в состоянии ожидания. Даже если задача обычно успевает выполниться в конкретном сценарии, полагаться на это как на гарантию нельзя.

Подробное решение

Нужно хранить фоновые задачи, например в множестве, а после завершения удалять их:

import asyncio

background = set()

async def work():
    await asyncio.sleep(1)
    print("готово")

def start_work():
    task = asyncio.create_task(work())
    background.add(task)
    task.add_done_callback(background.discard)

Множество удерживает Task сильной ссылкой. Когда задача завершается, callback удаляет её, поэтому завершённые задачи не накапливаются и не создают утечку памяти.

У задачи могут временно существовать другие ссылки: например, очередь событий или объект, который она ожидает, может удерживать связанные callback-объекты. Однако это деталь текущего состояния, а не контракт, гарантирующий время жизни задачи. Явная коллекция владения делает поведение предсказуемым.

Сохранение ссылки полезно и для контроля ошибок. Если фоновая задача завершилась исключением, приложение должно получить его через Task.result, await или специальный callback; простое запускание задачи не превращает исключение в обычный результат.

Важно отличать фоновую задачу от задачи, которую главный код ожидает через await. При ожидании сильная ссылка обычно сохраняется структурой вызывающего кода, но это не отменяет необходимости корректно обрабатывать отмену, исключения и завершение приложения.

Ситуация из практики

Сервис принимает HTTP-запрос и запускает фоновую отправку уведомления, не ожидая её завершения. Если задача создаётся без сохранения ссылки, уведомление может не отправиться полностью, а ошибка доставки останется незамеченной.

Рассматривались два варианта. Первый — сохранять задачи в общем множестве и удалять их callback-ом: это подходит для коротких независимых работ, но требует обработки исключений. Второй — передавать работу в отдельный брокер или очередь задач: это надёжнее для долгих операций и повторных попыток, но добавляет инфраструктуру и задержки.

Для коротких операций внутри одного процесса выбран первый вариант: сервис удерживает задачи, собирает их исключения и отменяет оставшиеся задачи при корректном завершении. Для критичных уведомлений используется внешняя очередь, поскольку время жизни event loop не должно определять доставку.

Что кандидаты часто упускают

Гарантирует ли сильная ссылка, что задача завершится?

Нет. Сильная ссылка защищает задачу от преждевременной сборки мусора, но не гарантирует успешное завершение. Задача может быть отменена, завершиться исключением, зависнуть на внешней операции или быть остановлена вместе с event loop.

Надёжный код отдельно определяет политику отмены, тайм-аутов и обработки исключений. Владение объектом Task — необходимое условие контроля, но не замена управлению жизненным циклом работы.

Что произойдёт с фоновыми задачами при завершении asyncio.run?

При завершении asyncio.run оставшиеся задачи обычно отменяются в рамках корректного закрытия event loop. Поэтому сохранение задачи в множестве не позволяет ей продолжить работу после завершения самого цикла событий.

Если результат должен быть гарантированно получен, приложение обязано дождаться задачи до закрытия цикла либо передать работу системе, которая живёт дольше текущего запуска процесса.

Достаточно ли удалить задачу из множества после её завершения?

Недостаточно, если при этом не обработать исключение. Удаление освобождает память, но завершившаяся с ошибкой задача всё равно может привести к сообщению о неполученном исключении.

Callback может проверить состояние задачи и вызвать result, перехватив ожидаемое исключение, либо приложение может централизованно собирать завершённые задачи. Важно не скрывать ошибки молча: для фоновой работы должны существовать журналирование, метрики или политика повторной попытки.