Что такое дедлок
Что проверяют
Понимаете ли вы условия возникновения дедлока и умеете ли доказать его по трейсу, а не по догадке. В Android к этому добавляется вопрос про главный поток: большинство зависаний, которые называют дедлоком, приходят из ожидания на нём.
Как отвечать
Дедлок это круговое ожидание: поток A держит первый ресурс и ждёт второй, поток B держит второй и ждёт первый, вытеснения нет, значит оба стоят навсегда. Классически перечисляют четыре условия (взаимное исключение, удержание с ожиданием, отсутствие вытеснения, круговое ожидание), и достаточно снять любое. На практике снимают последнее: единый порядок захвата блокировок во всём коде.
Второй приём это ожидание с ограничением по времени: у ReentrantLock есть попытка захвата с таймаутом, у synchronized такой возможности нет вовсе. Третий: не держать две блокировки одновременно, сузив критическую секцию.
В корутинах вместо synchronized берут Mutex. Монитор в JVM привязан к потоку, а корутина после приостановки может продолжиться на другом потоке, и это ломает саму модель владения. Диагностика идёт по трейсу ANR, где для каждого потока видно, какой монитор он держит и какого ждёт.
Где спотыкаются
Называют дедлоком любое зависание. Голодание, живая блокировка и просто долгая работа на главном потоке для пользователя выглядят одинаково, но лечатся по-разному, и трейс различает их сразу.
Ставят synchronized вокруг приостанавливаемого вызова. В лучшем случае это блокирует поток на время ожидания сети, в худшем ломает соответствие между владельцем монитора и корутиной.
Обещают решить всё профайлером. Он показывает загрузку и аллокации, а взаимную блокировку выдаёт трейс с записями о владельце монитора. Без него объяснение остаётся гипотезой.