Были ли проблемы или баги, связанные с многопоточностью и корутинами

Что проверяют

Работали ли вы с конкурентностью в реальном проекте, а не только по документации. Интервьюеру важны симптом, способ поиска причины и системный вывод. Следом обычно спрашивают про отмену корутин и обработку исключений.

Как отвечать

Нужна своя история: какой был симптом (падение, ANR, неверные данные на экране), как воспроизвели, в чём была причина и что поменяли, чтобы не повторилось. Типичные классы таких багов:

• гонка за общее состояние: несколько корутин на Dispatchers.Default меняют один список или счётчик. Лечится Mutex, атомарным MutableStateFlow.update {} или привязкой к одному потоку через limitedParallelism(1);
• проглоченная отмена: catch (e: Exception) или runCatching ловят CancellationException, и корутина продолжает работу после закрытия экрана. Отмену нужно пробрасывать дальше;
• работа в фоне и утечки: GlobalScope вместо viewModelScope и lifecycleScope, сбор Flow без repeatOnLifecycle(Lifecycle.State.STARTED), и подписка живёт в свёрнутом приложении;
• блокировка главного потока: runBlocking или синхронный ввод-вывод на Main дают ANR. viewModelScope по умолчанию работает на Dispatchers.Main.immediate, поэтому тяжёлую работу оборачивают в withContext(Dispatchers.IO);
• исключения: в обычном Job падение одного дочернего отменяет соседей, нужен SupervisorJob или supervisorScope. CoroutineExceptionHandler, установленный в дочернюю корутину, не вызывается.

Закончите профилактикой: диспетчеры внедряются через конструктор, в тестах runTest и StandardTestDispatcher.

Если серьёзных багов не случалось, не выдумывайте. Скажите об этом и расскажите, какие из этих ошибок ловили на ревью и какие правила их предотвращают.

Где спотыкаются

Рассказывают только про withContext(Dispatchers.Main) для обновления UI. Это азбука, а не история про баг.

Считают Mutex полным аналогом synchronized. Он не реентерабельный: повторный lock() в той же корутине приводит к взаимной блокировке.

Надеются на @Volatile для общего счётчика. Он даёт видимость изменений между потоками, но не атомарность, и count++ из разных корутин всё равно теряет обновления.