Работали ли вы с многопоточностью

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

Реальный опыт: знаете ли вы, где именно возникают гонки, и чем пользовались, кроме synchronized.

Как отвечать

Рамка и конкретный случай.

> «Да, на сервисе выгрузок. Обработка шла последовательно и занимала сорок минут, перевёл на пул из ExecutorService с ограничением по числу задач, стало восемь. По дороге поймал гонку: общий HashMap со счётчиками портился при параллельной записи, заменил на ConcurrentHashMap с merge».

Что стоит назвать по существу:

• где проблема: разделяемое изменяемое состояние. Нет общего состояния, нет гонки;
• инструменты: ExecutorService и пулы вместо ручного создания потоков, CompletableFuture для композиции, ConcurrentHashMap, AtomicInteger и LongAdder вместо блокировок на счётчиках, ReentrantLock там, где нужен таймаут или прерывание;
• память: volatile даёт видимость, но не атомарность; synchronized даёт и то и другое;
• типичные беды: гонка, взаимная блокировка (лечится единым порядком захвата), голодание, ложное разделение строки кэша;
• современное: виртуальные потоки в Java 21 меняют экономику блокирующего ввода-вывода, но не отменяют ни одной проблемы с общим состоянием.

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

Отвечают «работал», но не могут назвать ни одной пойманной гонки.

Считают volatile заменой синхронизации.

Создают потоки вручную вместо пула.

Не знают, что HashMap при параллельной записи не просто теряет данные, а может испортить структуру.