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

Нет. ARC управляет временем жизни объектов, но не синхронизирует доступ к самой переменной. Одновременное чтение и переназначение общей сильной ссылки без синхронизации создаёт гонку данных, даже если операции retain/release корректно поддерживают время жизни экземпляров.

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

ARC автоматизировал ручное управление подсчёком ссылок в Objective-C и Swift: компилятор добавляет необходимые операции удержания и освобождения объектов. Его задача — определить, когда экземпляр больше не удерживается сильными ссылками, а не согласовать доступ нескольких потоков к общей памяти.

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

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

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

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

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

Нужно различать два уровня:

Время жизни объекта. Если разные потоки владеют объектом через разные корректные сильные ссылки и одновременно освобождают их, объект будет уничтожен после освобождения последней сильной ссылки.
Доступ к переменной. Чтение, присваивание и проверка общей переменной должны быть синхронизированы. ARC не делает составную операцию вроде «прочитать ссылку, выполнить действие, затем заменить ссылку» атомарной.

Безопасный вариант — защищать общее хранилище блокировкой или изолировать его актором:

final class Holder {
    private let lock = NSLock()
    private var value: NSObject?

    func replace(_ newValue: NSObject?) {
        lock.lock()
        value = newValue
        lock.unlock()
    }

    func withValue(_ body: (NSObject?) -> Void) {
        lock.lock()
        let current = value
        body(current)
        lock.unlock()
    }
}

Локальная константа current удерживает прочитанный объект сильной ссылкой на время использования, если тип и контекст требуют такого владения. Однако блокировка защищает не только ARC-ссылку, но и логическую последовательность действий; в реальном коде важно не выполнять под блокировкой долгие или повторно входящие операции.

Актор является предпочтительным решением в коде на Swift Concurrency, когда состояние можно изолировать внутри него. NSLock уместен для низкоуровневого синхронного кода, но требует строгого соблюдения правил захвата и освобождения блокировки.

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

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

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

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

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

Если ARC не синхронизирует переменную, гарантирует ли он безопасность времени жизни объекта при параллельном освобождении независимых ссылок?

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

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

Безопасно ли прочитать общую сильную ссылку, скопировать её в локальную переменную и затем использовать локальную копию?

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

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

Достаточно ли сделать ссылку let, чтобы несколько потоков могли безопасно использовать объект?

Нет. Неизменяемость самой ссылки означает, что её нельзя переназначить через данный идентификатор, но не делает автоматически потокобезопасным состояние объекта. Методы экземпляра могут изменять его свойства, а несколько потоков могут одновременно обращаться к этим свойствам.

let может устранить гонку на переназначение конкретной ссылки, но не заменяет синхронизацию изменяемого состояния объекта. Потокобезопасность должна быть обеспечена самим типом — например, через actor, lock или другой протокол доступа.