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

async-задача не делает синхронный вызов автоматически неблокирующим. Если внутри неё выполняется операция вроде ожидания файлового дескриптора, синхронного сетевого запроса или Thread.sleep, поток, на котором исполняется задача, остаётся занят. При нехватке потоков в общем пуле другие задачи могут долго не получать времени выполнения.

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

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

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

Это помогает ограничивать количество потоков и снижает стоимость конкурентности. Однако модель предполагает, что код добровольно уступает выполнение через неблокирующие операции; синхронный блокирующий вызов нарушает это предположение.

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

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

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

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

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

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

Минимальное сравнение:

import Foundation

func wrongDelay() async {
    Thread.sleep(forTimeInterval: 2) // блокирует поток
}

func rightDelay() async {
    try? await Task.sleep(nanoseconds: 2_000_000_000) // приостанавливает задачу
}

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

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

Такой адаптер имеет ограничения. Отмена Swift-задачи не обязана прервать уже выполняющийся системный блокирующий вызов, поэтому нужно отдельно продумать тайм-ауты, закрытие ресурса и безопасное игнорирование результата после отмены.

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

В приложении синхронный SDK обращался к локальной базе данных и иногда блокировал вызов на несколько секунд. Сначала вызов поместили в Task.detached, но задержки сохранились: detached-задача всё равно занимала поток общего пула, а также усложнила контроль изоляции и передачу данных.

Второй вариант — выполнять вызов непосредственно в async-функции. Он был проще, но создавал риск блокировки потоков приложения и особенно опасен при случайном вызове с главным актором.

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

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

Освобождает ли любой await поток?

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

Устраняет ли проблему запуск блокирующего вызова в Task.detached?

Нет. Task.detached не наследует контекст родительской задачи, включая некоторые значения task-local и изоляцию, но обычно всё равно исполняется инфраструктурой Swift Concurrency. Блокирующий вызов продолжит занимать поток; detached-задача лишь изменит контекст запуска и может дополнительно усложнить безопасность данных.

Можно ли компенсировать блокирующие вызовы созданием большего числа задач?

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