В каких случаях использовать @Synchronized

А, ну это про @Synchronized! Ёпта, классика жанра, как старый добрый замок на сарае. В Котлине это такая аннотация, которая делает из твоего метода этакую неприступную крепость для потоков. По сути, то же самое, что в Java synchronized блок, только нацепил на функцию — и всё, готово.

Когда это впендюрить стоит?

Ну, представь ситуацию: у тебя есть какая-нибудь переменная-счётчик, общая для всех потоков, и они все туда лезут, как голодные псы на миску. Без синхронизации будет пиздец — значения поплывут, будто их водкой запили. Вот для таких простых случаев, когда надо быстро и без затей отгородить доступ к общему ресурсу, @Synchronized — твой выбор. Идеально, когда нужно защитить один конкретный метод от того, чтобы его набросилась овердохуища потоков одновременно.

Смотри, как просто:

@Synchronized
fun updateCounter() {
    counter++
}

Всё! Теперь, когда один поток зашёл в updateCounter(), остальные будут терпеливо ждать у двери, как в очередь в единственную кабинку в баре. Никакой гонки, всё чинно-благородно.

Но тут, бля, есть подводные камни, и их надо знать:

• Для сложных дел — не годится. Если у тебя там танцы с бубном, несколько ресурсов или нужно условное ожидание — это уже не наш клиент. Тут уже надо брать в руки Mutex или другие навороченные штуки из kotlinx.coroutines.sync. @Synchronized — это как тупая кувалда, а не хирургический скальпель.
• Блокирует ВЕСЬ метод. Это главная засада. Даже если внутри метода только одна строчка критическая, а остальные десять — просто расчёты, замок будет на всём. Получается иногда, что потоки простаивают на ровном месте, как лохи. Производительность может просесть конкретно, если метод вызывают часто.

Короче, инструмент как инструмент. Для быстрого костыля на коленке — иногда норм. Для чего-то серьёзного и высоконагруженного — лучше не надо, а то будет тебе хиросима, а не многопоточность. Используй с умом, а не просто тыкай везде, где волнение ебать.