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

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

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

Модель async/await появилась как более структурированный способ описывать операции, которые могут ждать результат, по сравнению с вложенными callback-функциями. Она позволяет компилятору и среде выполнения управлять продолжением задачи после ожидания, не блокируя поток.

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

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

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

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

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

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

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

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

func immediate() async -> Int {
    42
}

actor Cache {
    var value = 7
    func read() -> Int { value }
}

func load(from cache: Cache) async -> Int {
    let first = await immediate()
    let second = await cache.read()
    return first + second
}

immediate объявлена как async, но может вернуть результат без приостановки. Для cache.read нужен await, потому что доступ к состоянию актора потенциально требует перехода через его изоляцию; фактическая пауза и смена потока при этом не гарантируются.

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

Сервис получает данные из памяти и при промахе обращается к сети. Разработчик измеряет время от начала функции до первого await и предполагает, что после этой точки функция всегда выполняется на другом потоке. Это приводит к неверному профилированию и попыткам вручную переключать очереди.

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

Корректное решение — оставить асинхронный вызов и воспринимать await как потенциальную точку уступки управления, а не как обязательный переключатель потока. Фактическое поведение проверяют измерениями и анализом изоляции, а не количеством операторов await; это сохраняет управляемость отмены и не блокирует исполнители.

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

Гарантирует ли await продолжение на том же потоке?

Нет. После приостановки задача возобновляется на подходящем исполнителе согласно правилам изоляции и планирования. Для обычной не изолированной async-функции сохранение исходного потока не является гарантией.

Можно ли считать код до и после await одной неделимой критической секцией?

Нет. Между этими участками задача может приостановиться, а состояние изолированного объекта может измениться другими задачами. Если операция должна быть атомарной, её нужно целиком организовать внутри подходящей изоляции; простой await такую атомарность не сохраняет.

Что изменится, если async-функция сегодня завершается сразу, а завтра начнёт ждать сеть?

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