Что входит в пакет java.util.concurrent

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

Знаете ли вы инструменты пакета по назначению, а не списком, и можете ли выбрать нужный под задачу. Следом обычно спрашивают, как устроен ConcurrentHashMap, чем CountDownLatch отличается от CyclicBarrier или почему Executors.newFixedThreadPool бывает опасен.

Как отвечать

Разложите пакет на группы:

• исполнители: Executor, ExecutorService, ScheduledExecutorService, реализации ThreadPoolExecutor и ForkJoinPool, фабрика Executors. С Java 21 есть Executors.newVirtualThreadPerTaskExecutor() для виртуальных потоков;
• задачи и результаты: Callable возвращает значение и может бросить checked-исключение, Future даёт блокирующий get(), CompletableFuture строит цепочки thenApply, thenCompose, allOf без блокировки;
• синхронизаторы: CountDownLatch (одноразовый счётчик), CyclicBarrier (переиспользуемая точка встречи), Semaphore (лимит одновременных доступов), Phaser, Exchanger;
• коллекции: ConcurrentHashMap, ConcurrentSkipListMap, CopyOnWriteArrayList, ConcurrentLinkedQueue и семейство BlockingQueue;
• подпакеты: locks (ReentrantLock, ReentrantReadWriteLock, StampedLock) и atomic (AtomicInteger, AtomicReference, LongAdder).

Покажите, что понимаете поведение. ConcurrentHashMap с Java 8 не использует сегменты, а работает через CAS и блокировку отдельной корзины, поэтому чтение почти не блокируется. CopyOnWriteArrayList копирует массив при каждой записи и подходит только для редких изменений.

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

Считают, что потокобезопасная коллекция делает атомарной любую логику. if (!map.containsKey(k)) map.put(k, v) на ConcurrentHashMap остаётся гонкой, нужны putIfAbsent, computeIfAbsent или merge.

Не знают, что newFixedThreadPool использует неограниченную LinkedBlockingQueue, а newCachedThreadPool создаёт потоки без верхней границы. Под нагрузкой первое заканчивается OutOfMemoryError, второе тысячами потоков. В проде пул собирают через ThreadPoolExecutor с ограниченной очередью и политикой отказа.

Забывают вызвать shutdown() и не знают, что исключение из задачи в submit() молча оседает в Future до вызова get().