Почему в Kotlin нет ключевого слова synchronized как в Java?

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

Не поверите ли вы формулировке вопроса на слово. Такого ключевого слова в Kotlin действительно нет, но синхронизация никуда не делась, и собеседующий смотрит, понимаете ли вы, почему она вынесена из языка в библиотеку.

Как отвечать

Причина не в том, что монитор устарел, а в устройстве языка: Kotlin многоплатформенный, и то, что существует только на JVM, живёт не в грамматике, а в JVM-части стандартной библиотеки. Поэтому вместо ключевого слова есть встраиваемая функция synchronized(lock) { ... } и аннотация @Synchronized, которая помечает метод тем же флагом байткода, что и Java. Результат получается такой же, возможностей не теряется.

private val lock = Any()

fun add(x: Int) = synchronized(lock) { total += x }

Дальше сказать, что в корутинах блокирующий монитор не подходит: он удерживает поток целиком, а поток в корутинном коде это дефицитный ресурс. Для взаимного исключения между корутинами есть Mutex из kotlinx.coroutines, и брать его принято через withLock, а не парой lock и unlock, чтобы не потерять разблокировку на исключении.

Полезно назвать выбор по ситуации: короткая правка общего поля это synchronized или атомик; защита ресурса в suspend-коде это Mutex; строгая сериализация обращений к состоянию это однопоточный диспетчер или приём с каналом, куда складываются команды.

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

Говорят, что Mutex безопаснее и избавляет от взаимоблокировок. Не избавляет: он не реентерабельный, и повторный захват из уже захватившего кода виснет навсегда, тогда как монитор JVM реентерабельный и повторный вход спокойно разрешает.

Второе: считают, что withContext(Dispatchers.Default) защищает от гонок. Это пул из нескольких потоков, он ничего не сериализует. Ограничение одним потоком даёт только однопоточный диспетчер.

Третье: пытаются совместить монитор и приостановку. Монитор JVM привязан к потоку: захватил один, отпустить обязан он же. Корутина после возобновления может продолжиться на другом потоке, поэтому такая пара не сходится в принципе, и ради этого случая Mutex и существует.