> Какие способы борьбы с data race существуют (iOS, Swift)

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

Основные способы борьбы с data race в iOS: синхронизация через serial queue, concurrent queue с барьерами, NSLock, os_unfair_lock, атомарные свойства (не гарантируют безопасность в Swift), actor из Swift Concurrency, а также изоляция данных через value semantics и immutable structures. Выбор зависит от контекста: для простых случаев - serial queue или lock, для сложных - actor. Главное - исключить одновременный доступ к mutable state из нескольких потоков.

Подробное объяснение

Data race возникает, когда два или более потока одновременно обращаются к одной ячейке памяти, и хотя бы один из них выполняет запись. В Swift это undefined behavior, который приводит к непредсказуемым результатам, крашам и трудноуловимым багам.

Основные стратегии борьбы:

1. Serial DispatchQueue - самый простой способ: все обращения к mutable state выполняются на одной очереди, что гарантирует последовательный доступ. Минус - потенциальные блокировки и ограниченная производительность.

2. Concurrent queue + barrier - позволяет параллельное чтение, но запись выполняется с барьером, который блокирует все остальные операции. Это даёт лучший performance для read-heavy сценариев.

3. NSLock / os_unfair_lock - классические блокировки. os_unfair_lock более эффективен и не страдает от priority inversion, как NSLock. Требуют аккуратного управления, легко забыть разблокировать.

4. Атомарные свойства (atomic) - в Objective-C гарантируют атомарность getter/setter, но в Swift это не работает для обычных свойств. Даже в ObjC атомарность не защищает от составных операций (например, check-then-act).

5. Actor (Swift 5.5+) - языковой механизм, который изолирует mutable state и гарантирует безопасный доступ через async/await. Компилятор проверяет доступ на этапе компиляции. Это современный и предпочтительный способ для нового кода.

6. Value semantics + immutable structures - если данные не изменяются после создания, data race невозможен. Использование struct, let, copy-on-write коллекций.

7. ThreadSanitizer (TSan) - не способ борьбы, но инструмент обнаружения. Запускается в Xcode и помогает найти data race на этапе тестирования.

На практике

Для iOS-разработчика выбор зависит от ситуации:

• UI-обновления - всегда на main queue, не требуют дополнительной синхронизации.
• Кэши, in-memory хранилища - часто используют concurrent queue с barrier или actor.
• Сетевые ответы, обработка данных - предпочтителен actor, так как компилятор помогает избежать ошибок.
• Legacy code - часто приходится мигрировать с NSLock на actor, но это требует рефакторинга.

Важно помнить, что синхронизация - это trade-off между безопасностью и производительностью. Избыточная синхронизация может привести к deadlock или снижению скорости. Также стоит учитывать, что некоторые подходы (например, atomic) дают ложное чувство безопасности.

Пример кода

SWIFT
// 1. Serial queue
final class CounterSerial {
    private let queue = DispatchQueue(label: "counter.serial")
    private var _value = 0
    var value: Int {
        queue.sync { _value }
    }
    func increment() {
        queue.sync { _value += 1 }
    }
}

// 2. Concurrent queue + barrier
final class CounterBarrier {
    private let queue = DispatchQueue(label: "counter.barrier", attributes: .concurrent)
    private var _value = 0
    var value: Int {
        queue.sync { _value }
    }
    func increment() {
        queue.async(flags: .barrier) { self._value += 1 }
    }
}

// 3. Actor
actor CounterActor {
    private var value = 0
    func increment() {
        value += 1
    }
    func getValue() -> Int {
        value
    }
}

Как отвечать на собеседовании

Начните с определения data race, затем перечислите основные способы. Для senior-позиции важно показать понимание trade-off: когда какой подход уместен, какие проблемы могут возникнуть (deadlock, priority inversion, performance). Упомяните, что в современном Swift предпочтителен actor, но в legacy-коде часто встречаются lock и queue. Также стоит упомянуть TSan как инструмент обнаружения. Если спросят про конкретный сценарий - предложите решение и объясните, почему выбрали именно его.

Что проверяет интервьюер

Интервьюер оценивает:

• Понимание фундаментальной проблемы (что такое data race и почему он опасен).
• Знание инструментов синхронизации в iOS-экосистеме.
• Умение выбирать подходящий механизм под задачу.
• Понимание ограничений и побочных эффектов каждого подхода.
• Знание современных возможностей Swift (actor, Sendable, async/await).
• Способность объяснить trade-off между производительностью и безопасностью.

Типичные ошибки

• Утверждение, что atomic в Swift решает проблему - это не так.
• Предложение использовать только один способ без учёта контекста.
• Игнорирование проблемы deadlock при использовании lock.
• Непонимание, что serial queue не защищает от data race, если доступ идёт извне через другие механизмы.
• Забывают упомянуть, что синхронизация не заменяет правильное проектирование (immutable data, value semantics).
• Путаница между data race и race condition - это разные вещи, хотя часто встречаются вместе.