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

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

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

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

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

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

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

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

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

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

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

actor Counter {
    private var value = 0

    func current() -> Int {
        value
    }
}

let counter = Counter()

Task {
    let value = await counter.current()
    print(value)
}

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

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

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

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

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

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

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

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

Всегда ли await означает фактическую приостановку задачи?

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

Можно ли заменить await на nonisolated только потому, что метод читает состояние?

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

Почему вызов метода из другого метода того же актора может обходиться без await?

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