Всегда ли c MainQueue попадают задачи на MainThread?

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

Не всегда. Хотя в подавляющем большинстве случаев отправка задачи на DispatchQueue.main приводит к её выполнению на главном потоке (Main Thread), существуют специфические и, как правило, нежелательные сценарии, где это соответствие нарушается. Важно понимать разницу между очередью (Queue) и потоком (Thread).

Основные понятия: Очередь vs Поток

• DispatchQueue.main (Главная очередь) — это последовательная (serial) очередь, управляемая системой (GCD — Grand Central Dispatch). Все задачи, добавленные в эту очередь, выполняются строго друг за другом, в порядке их поступления (FIFO).
• Main Thread (Главный поток) — это конкретный поток выполнения (pthread_t), созданный системой при запуске приложения. На нём работает основной RunLoop, который обрабатывает события пользовательского интерфейса, таймеры и другие источники ввода.

Стандартный контракт iOS/macOS таков: система связывает (targets) главную очередь именно с главным потоком. Любая работа, отправленная на DispatchQueue.main, в конечном итоге будет выполнена на этом одном, конкретном потоке.

Сценарии, когда соответствие нарушается

Однако, есть исключительные ситуации, которые разработчик может создать преднамеренно или случайно.

1. Вызов из не-main контекста с использованием DispatchQueue.main.sync

Синхронный вызов (sync) из фонового потока на главной очереди — это стандартная и корректная операция. Она блокирует текущий фоновый поток до тех пор, пока задача не будет выполнена на главном потоке. Соответствие здесь сохраняется.

Опасность возникает, если сделать sync на главной очереди ИЗ САМОГО ГЛАВНОГО ПОТОКА.

// ❗ ОПАСНЫЙ КОД — приведёт к deadlock или неопределённому поведению
DispatchQueue.main.sync {
    // Эта задача попытается выполниться на текущем потоке,
    // но так как мы уже на главном потоке и очередь main заблокирована,
    // произойдёт взаимная блокировка (deadlock).
    print("Этот код, скорее всего, не выполнится")
}

В этом случае система сталкивается с невозможностью выполнить контракт "очередь -> поток", потому что требуемый поток уже занят ожиданием этой же задачи. Это приводит к дедлоку (в большинстве случаев) или, в некоторых сложных сценариях с вложенными циклами выполнения, система может принять нестандартные меры.

2. Ручное создание потока и привязка к нему MainQueue (очень редкий хак)

Теоретически, используя низкоуровневые API (pthread и манипуляции с runloop), можно создать новый поток, сделать на нём RunLoop.main активным и вручную "переназначить" на него диспетчеризацию задач из DispatchQueue.main. Это крайне сложная, нетипичная и практически никогда не используемая на практике операция, которая ломает архитектурные предположения системы.

// ПСЕВДОКОД, иллюстрирующий идею (НЕ ИСПОЛЬЗУЙТЕ в продакшене)
func hijackMainQueue() {
    let newThread = Thread {
        // Активируем главный цикл выполнения на этом НОВОМ потоке
        RunLoop.main.run()
    }
    newThread.start()
    // После этого задачи с DispatchQueue.main могут начать
    // выполняться на этом новом потоке, а не на исходном Main Thread.
}

Важно: Такие действия полностью нарушают работу фреймворков UIKit/AppKit, которые жёстко завязаны на изначальный главный поток для обновления UI.

3. Особые системные состояния или баги

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

Почему это различие важно на практике?

1. UI-обновления: Все операции с элементами интерфейса должны выполняться на главном потоке. Использование DispatchQueue.main.async — это стандартный и безопасный способ гарантировать это.
2. Предотвращение дедлоков: Понимание механизма предотвращает ошибки с sync, описанные выше.
3. Отладка: В стеке вызовов (backtrace) во время отладки вы видите потоки, а не очереди. Задача из DispatchQueue.main будет находиться в стеке главного потока, что помогает в диагностике.

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

• Для обновления UI всегда используйте DispatchQueue.main.async { }. Это гарантирует выполнение кода на правильном потоке.
• Избегайте DispatchQueue.main.sync, если только вы не уверены на 100%, что вызываете НЕ с главного потока. Чаще всего в этом нет необходимости.
• Помните, что проверка Thread.isMainThread внутри блока, отправленного на DispatchQueue.main, почти всегда вернёт true. Исключения — это критические ошибки в архитектуре вашего приложения.

Вывод

Соответствие DispatchQueue.main -> Main Thread является архитектурным гарантом iOS/macOS, который нарушается только в крайних, часто ошибочных, ситуациях. Для разработчика правило простое: используйте DispatchQueue.main.async для работы с UI, и система выполнит ваш код там, где нужно — на главном потоке. Понимание же тонкостей необходимо для глубокой отладки и избегания редких, но критических ошибок.