Почему коллекции в Swift не являются потокобезопасными?

Потокобезопасность коллекций в Swift: архитектурный выбор и его причины

Коллекции в Swift (такие как Array, Dictionary, Set) изначально не являются потокобезопасными по архитектурным и философским соображениям языка. Это означает, что одновременное чтение и изменение одной коллекции из нескольких потоков без дополнительной синхронизации может привести к неопределённому поведению, повреждению данных или падению приложения.

Основные причины отсутствия потокобезопасности

1. Принцип производительности и минимальных накладных расходов Swift был разработан как высокопроизводительный язык, где стандартные коллекции оптимизированы для скорости в однопоточных контекстах. Добавление внутренней синхронизации (например, мьютексов или семафоров) привело бы к:

• Накладным расходам на каждый доступ (блокировки, проверки)
• Снижению производительности даже в однопоточных сценариях
• Непредсказуемому времени выполнения операций

// Пример опасного многопоточного использования
var unsafeArray = [1, 2, 3]

DispatchQueue.concurrentPerform(iterations: 100) { index in
    // ❌ Опасная операция без синхронизации
    unsafeArray.append(index)
    // Возможны: повреждение структуры, дублирование элементов, падение
}

2. Явный контроль над синхронизацией Разработчики Swift считают, что управление многопоточностью должно быть явным и контролируемым программистом, а не скрытым внутри библиотек. Это позволяет:

• Выбирать наиболее подходящий механизм синхронизации (DispatchQueue, NSLock, actors)
• Оптимизировать синхронизацию для конкретных паттернов доступа
• Избегать неявных блокировок, которые могут вызвать deadlock

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

• Array может выполнять reallocation памяти при расширении
• Dictionary использует хеш-таблицы с возможными коллизиями
• Операции типа remove или insert изменяют внутренние указатели

// Реализация потокобезопасного массива с использованием DispatchQueue
class ThreadSafeArray<T> {
    private var storage = [T]()
    private let accessQueue = DispatchQueue(label: "sync.queue", attributes: .concurrent)
    
    func append(_ element: T) {
        accessQueue.async(flags: .barrier) {
            storage.append(element)
        }
    }
    
    var elements: [T] {
        return accessQueue.sync { storage }
    }
}

Механизмы для обеспечения потокобезопасности

Для безопасной работы с коллекциями в многопоточном окружении Swift предлагает:

1. Использование барьерных очередей (DispatchQueue barriers)

let concurrentQueue = DispatchQueue(label: "com.example", attributes: .concurrent)
var sharedDictionary = [String: Int]()

// Безопасное изменение с барьером
concurrentQueue.async(flags: .barrier) {
    sharedDictionary["key"] = 42
}

// Безопасное чтение
concurrentQueue.sync {
    let value = sharedDictionary["key"]
}

2. Применение Actors (в Swift 5.5+)

actor SharedDataActor {
    private var dataArray = [Double]()
    
    func addValue(_ value: Double) {
        dataArray.append(value)
    }
    
    func getValues() -> [Double] {
        return dataArray
    }
}

// Использование actor гарантирует потокобезопасность
let actorInstance = SharedDataActor()
Task {
    await actorInstance.addValue(3.14)
}

3. Старые подходы: NSLock, семафоры

var protectedSet = Set<String>()
let lock = NSLock()

lock.lock()
protectedSet.insert("newItem")
lock.unlock()

Практические рекомендации

• Для чтения в нескольких потоках и изменения в одном часто достаточно простых барьерных очередей
• Для сложных сценариев с частыми изменениями из многих потоков рассмотрите actors или специализированные структуры (NSCache для Dictionary)
• Копирование коллекций перед передачей в другой поток может быть безопасной альтернативой
• Не забывайте, что даже @MainActor не делает коллекции автоматически потокобезопасными — он лишь гарантирует выполнение на главном потоке

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