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

Да. В Tokio уничтожение JoinHandle обычно отсоединяет задачу, но не отменяет её: задача продолжает выполняться, пока жив runtime и сама не завершится. При этом вызывающая сторона теряет возможность получить её результат или ошибку через этот handle.

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

Асинхронные runtime позволяют запускать множество логически независимых операций поверх ограниченного числа потоков. Для этого запуск задачи отделён от ожидания её результата: runtime владеет самой задачей, а JoinHandle предоставляет вызывающему коду способ наблюдать за ней и управлять ею.

Такая модель нужна для фоновых задач, которым не всегда требуется немедленно ждать результат. Отсоединение также позволяет явно выбирать между независимым выполнением и структурированным управлением жизненным циклом задачи.

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

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

Обратная ошибка тоже возможна: если ожидать автоматической отмены и не сохранить handle, результат задачи и её паника станут недоступны вызывающему коду. Кроме того, при остановке runtime незавершённые задачи всё равно могут быть принудительно отброшены.

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

tokio::spawn регистрирует future в runtime и возвращает JoinHandle. Уничтожение handle не уничтожает future, потому что runtime уже хранит и планирует её отдельно; handle является лишь дескриптором наблюдения и управления.

Если handle сохранить и вызвать .await, можно получить результат задачи. Для задачи с результатом типа T это обычно Result<T, JoinError>: ошибка может означать, например, панику или отмену задачи. Если handle отброшен, получить это значение или диагностировать ошибку через него уже нельзя.

Для явной остановки используется abort(). Отмена async-задачи не равна мгновенному прерыванию произвольного машинного кода: задача должна быть корректно остановлена runtime, а блокирующая синхронная операция сама по себе не становится прерываемой. Для важных операций часто нужна кооперативная отмена через токен, канал или другой сигнал завершения.

#[tokio::main]
async fn main() {
    let handle = tokio::spawn(async {
        tokio::time::sleep(std::time::Duration::from_millis(10)).await;
        println!("задача завершилась");
        42
    });

    drop(handle); // задача отсоединена, но не отменена
    tokio::time::sleep(std::time::Duration::from_millis(20)).await;
}

Здесь задача обычно успевает вывести сообщение, однако её значение 42 уже некому получить. Программа должна удерживать runtime достаточно долго; при его уничтожении незавершённые задачи прекращаются вместе с runtime.

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

HTTP-обработчик запускает фоновую отправку аудита и сразу возвращает ответ. Возможны три подхода.

Отбросить handle. Ответ не задерживается, но невозможно дождаться аудита, обработать его ошибку или гарантировать завершение до остановки сервиса.
Ожидать handle в обработчике. Ошибки контролируются, но задержка аудита добавляется к времени ответа.
Передать задачу в управляемый фоновой менеджер. Менеджер хранит handle, поддерживает сигнал завершения и ждёт задачи при graceful shutdown.

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

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

Отбрасывание JoinHandle и вызов abort() — это одно и то же?

Нет. Отбрасывание handle отсоединяет задачу и не запрашивает её отмену. abort() явно инициирует отмену, после чего ожидание handle обычно сообщает об отмене через JoinError.
Гарантирует ли отсоединённая задача выполнение до конца?

Нет. Она продолжает выполняться только пока runtime работает и планирует её. При остановке runtime незавершённая задача может быть отброшена, поэтому отсоединение не является гарантией доставки, записи или graceful shutdown.
Можно ли получить результат отсоединённой задачи другим способом?

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