> Какие проблемы с многопоточностью существуют, например race condition, data race, starvation, priority inversion, deadlock (iOS, Swift)

В мобильной разработке на iOS (Swift) многопоточность критична для производительности UI, но сопряжена с рядом классических проблем.

Race condition - это логическая ошибка, когда результат работы зависит от непредсказуемого порядка выполнения потоков. Например, два потока одновременно читают и изменяют баланс счета: без синхронизации финальный баланс может быть неверным. В Swift решается через DispatchQueue (сериализация) или NSLock.

Data race - более низкоуровневая проблема, когда один поток пишет в память, а другой одновременно читает или пишет в ту же область без синхронизации. В Swift это приводит к неопределенному поведению (crash, повреждение данных). Инструменты: Thread Sanitizer (Xcode), использование os_unfair_lock, @Atomic (через property wrappers) или actor (Swift 5.5+), который гарантирует изоляцию состояния.

Starvation - поток не получает доступа к ресурсу, потому что другие потоки постоянно его перехватывают. В iOS часто встречается при неправильном приоритете очередей. Решение: использование QoS (Quality of Service) - .userInteractive для UI, .background для фоновых задач, чтобы избежать захвата ресурсов низкоприоритетными потоками.

Priority inversion - высокоприоритетный поток ожидает ресурса, занятого низкоприоритетным, который, в свою очередь, вытесняется средним. В iOS это решается через приоритетное наследование (priority inheritance) в pthread_mutex или через os_unfair_lock, а также использованием DispatchQueue с правильным QoS.

Deadlock - два или более потоков вечно ждут друг друга, блокируя выполнение. Классический пример: поток A захватил Lock1 и ждет Lock2, поток B захватил Lock2 и ждет Lock1. В Swift избегается через иерархию блокировок, использование DispatchQueue (сериализация) вместо множественных блокировок, или применение async/await с actor, где deadlock менее вероятен из-за отсутствия явных блокировок.

На практике в iOS-разработке рекомендуется минимизировать ручное управление потоками, отдавая предпочтение DispatchQueue с сериализацией, OperationQueue с зависимостями и actor для изоляции состояния.