Как устроен ConcurrentHashMap в Java 8+ и почему он эффективнее synchronized Map?

Проблема synchronized Map: Collections.synchronizedMap и Hashtable берут один монитор на каждый вызов. Восемь потоков, читающих разные ключи, всё равно выстраиваются в очередь.

Устройство ConcurrentHashMap (Java 8+):

• массив корзин Node[] с volatile-доступом к элементам;
• чтение (get) — без блокировок: значения и ссылки узлов volatile, видимость обеспечена;
• вставка в пустую корзину — CAS (compare-and-set) первого узла: без блокировки, повтор при гонке;
• вставка при коллизии — synchronized на первом узле этой корзины: блокируется только она, остальные корзины доступны параллельно;
• цепочки длиннее 8 при таблице от 64 превращаются в красно-чёрные деревья;
• размер — распределённые счётчики (как LongAdder), поэтому size() приблизителен под нагрузкой;
• расширение — новые потоки, обратившиеся к карте во время resize, помогают переносить корзины.

В Java 7 использовались сегменты — 16 отдельных замков на части таблицы.

Важно для кода: отдельные операции атомарны, но «проверить, потом положить» из двух вызовов — гонка. Используют putIfAbsent, computeIfAbsent, compute, merge. null ключи и значения запрещены: get возвращает null как «нет ключа», и отличить было бы нельзя.