Корутины

Диспетчер решает, на каком потоке выполняется корутина. Main — единственный UI-поток, трогать интерфейс можно только там. IO — большой эластичный пул для блокирующего ввода-вывода: файлы, сокеты, вызовы базы. Default — пул под CPU-нагрузку, размером в число ядер.

launch возвращает Job — запустил и забыл; если его тело бросит исключение, оно немедленно уходит родителю. async возвращает Deferred<T> с результатом и удерживает исключение до вызова await() — именно там сбой и перебрасывается.

CoroutineScope владеет Job, который становится родителем каждой запущенной в нём корутины. Это и есть структурная конкурентность: дети привязаны к времени жизни, scope дожидается их, а его отмена отменяет всех — поэтому ни одна корутина не переживает владельца и не утекает.

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

Deferred<T> — это Job, который вдобавок несёт результат. Читают его приостанавливающей await(): она освобождает поток до готовности значения, тогда как Future.get() блокирует вызывающий поток. Deferred — ребёнок своего scope и отменяется вместе с ним.

CoroutineContext — это индексированный набор элементов: обычно Job, диспетчер, CoroutineName и CoroutineExceptionHandler. Ребёнок наследует контекст родителя, но получает собственный новый Job, а всё переданное билдеру перекрывает унаследованный элемент с тем же ключом.

synchronized блокирует поток и не должен удерживаться через точку приостановки: корутина может возобновиться на другом потоке и отпустить монитор, который никогда не брала. Mutex.withLock вместо этого приостанавливается. Он не реентерабелен — вложенный захват даёт deadlock.

runBlocking блокирует вызывающий поток, пока не завершатся его тело и все дети — это мост из блокирующего кода в мир корутин, и именно он нужен в main и в тесте. Внутри кода корутин он тратит поток, ради освобождения которого существует приостановка, а на Main замораживает интерфейс.

Компилятор переписывает suspend-функцию в конечный автомат и добавляет скрытый параметр Continuation — это continuation-passing style. Каждая точка приостановки — состояние: приостановка сохраняет состояние, выходит из функции и освобождает поток, а Continuation позже возобновляет её, возможно на другом потоке.

withContext не создаёт новую корутину: он приостанавливает текущую, выполняет блок на заданном диспетчере и возобновляет её с результатом, поэтому он последователен и возвращает значение. launch же запускает конкурентного ребёнка и возвращает Job, а не результат.

GlobalScope не привязан ни к какому времени жизни, поэтому его корутины никогда не отменяются: закрытый экран продолжает грузиться, держит достижимой свою ViewModel и может писать в мёртвый UI. Замените его на scope владельца — viewModelScope, lifecycleScope, внедрённый app-scope.

Отправленная в пул задача — сирота: её никто не ждёт, отмена вызывающего её не останавливает, а её падение лежит непрочитанным в Future. Scope же делает каждую корутину потомком своей Job — scope не завершится, пока не завершатся все потомки, отмена расходится вниз по ним, а падение потомка доходит до родителя и отменяет соседей.

Немедленный await делает вызовы последовательными: первый async дожидаются раньше, чем стартовал второй, поэтому два секундных вызова идут подряд. Сначала запустите оба билдера, сохранив Deferred в переменные, и лишь потом их дождитесь.

count++ — это чтение-изменение-запись, поэтому конкурентные корутины затирают обновления друг друга. Защитите его через mutex.withLock { count++ }: захват приостанавливает корутину, а не блокирует поток пула. AtomicInteger — безлоковая и более дешёвая альтернатива.

Default крутит CPU-нагрузку, поэтому держит примерно по потоку на ядро: больше лишь добавит переключений контекста, но не пропускной способности. Поток IO же стоит заблокированным в системном вызове, а не на CPU, поэтому IO эластично растёт до многих потоков (минимум 64).

Мост строится через suspendCancellableCoroutine: отдайте колбэкам SDK CancellableContinuation, возобновляйте его значением или через resumeWithException и зарегистрируйте invokeOnCancellation { handle.cancel() }. Возобновить можно лишь раз — поздний callback игнорируйте.

viewModelScope диспетчеризует на Dispatchers.Main, а launch сам работу оттуда не уносит. Оба вызова блокирующие, а не приостанавливаемые, поэтому удерживают UI-поток. Оберните запрос в withContext(Dispatchers.IO), а разбор — в withContext(Dispatchers.Default).

load вызывается, когда мы уже на dbDispatcher, а runBlocking блокирует этот единственный поток. Внутренний withContext(dbDispatcher) ставит работу в очередь тому же запаркованному потоку — двигаться некому, это deadlock. Сделайте load функцией suspend, зовите db.load(id) напрямую и уберите runBlocking.

Напишите suspend-хелпер, принимающий вызов лямбдой: крутите попытки с отменяемым delay(backoff) между ними, умножая его и добавляя джиттер. Неретраибельную ошибку перебрасывайте сразу, а последнюю — когда попытки кончились. Весь вызов ограничьте через withTimeout.

Корутина — конструкция компилятора: suspend превращается в конечный автомат с Continuation, поэтому приостановка — это возврат, а не парковка, ценой окраски всей цепочки вызовов. Virtual thread — конструкция рантайма: обычный блокирующий код снимается со своего carrier без единой правки. Обе стоят объекта в куче, а не стека ОС, но native-кадр всё ещё пиннит virtual thread.

Закройте API Semaphore(5) и оборачивайте каждый вызов в semaphore.withPermit { … }. Захват приостанавливает корутину, когда все пять заняты, поэтому поток не блокируется, а withPermit освобождает разрешение в finally, поэтому отменённый вызывающий его возвращает.