Что такое ConcurrentHashMap

До появления ConcurrentHashMap потокобезопасность словарей достигалась двумя путями:

🟢 Junior Level

1. Что такое `ConcurrentHashMap`

ConcurrentHashMap — это высокопроизводительная потокобезопасная реализация интерфейса ConcurrentMap (расширяющего Map), спроектированная специально для многопоточных сред с высокой степенью конкуренции (High Concurrency).

До появления ConcurrentHashMap потокобезопасность словарей достигалась двумя путями:

Устаревшим классом Hashtable (Java 1.0).
Оберткой Collections.synchronizedMap(new HashMap<>()) (Java 1.2).

Оба эти подхода используют грубую глобальную блокировку (Coarse-Grained Lock) на уровне всего объекта. В результате любой поток, выполняющий чтение get(), блокирует всех остальных писателей и читателей. Это создает бутылочное горлышко и катастрофически снижает производительность многоядерных систем.

ConcurrentHashMap решает эту проблему:

Операции чтения (get) выполняются абсолютно без блокировок (Lock-Free).
Операции записи (put, remove) блокируют только одну конкретную корзину (бакет), не мешая потокам параллельно модифицировать другие бакеты.

// Инициализация потокобезопасной мапы:
Map<String, Integer> concurrentMap = new ConcurrentHashMap<>();

// Множество потоков могут одновременно писать и читать без внешних synchronized-блоков:
concurrentMap.put("alpha", 1);
concurrentMap.computeIfAbsent("beta", k -> 2);

2. Сравнительная таблица реализаций

Критерий	`HashMap`	`Collections.synchronizedMap`	`ConcurrentHashMap`
Потокобезопасность	❌ Нет	✅ Да (один монитор)	✅ Да (мелкогранулярная)
Блокировка чтения	Нет	Блокирует всю мапу	Lock-Free (без блокировок)
Блокировка записи	Нет	Блокирует всю мапу	Блокирует только бакет
Поддержка `null`	Key: ✅, Val: ✅	Key: ✅, Val: ✅	Key: ❌, Val: ❌ (NPE)
Итераторы	Fail-Fast (`CME`)	Fail-Fast (требует `sync`)	Weakly Consistent (нет `CME`)

🟡 Middle Level

1. Почему `ConcurrentHashMap` категорически запрещает `null`?

Попытка передать null в качестве ключа или значения в ConcurrentHashMap немедленно выбрасывает NullPointerException:

map.put(null, 100);  // NullPointerException!
map.put("key", null); // NullPointerException!

Архитектурное обоснование автора класса (Даг Ли / Doug Lea): В однопоточной HashMap результат map.get(key) == null можно однозначно разрешить проверкой map.containsKey(key): если containsKey вернул true, значит значение действительно равно null.

В многопоточной среде такой подход приводит к критической гонке (Race Condition):

// В многопоточной среде этот код не имеет смысла:
if (map.get(key) == null) {
    // В этот момент другой поток мог успеть вставить ключ или удалить его!
    if (map.containsKey(key)) {
        // Мы не можем доверять этой проверке
    }
}

Чтобы исключить эту двусмысленность («значение отсутствует» или «значение равно null»), Даг Ли принял фундаментальное решение: null в качестве ключей и значений в конкурентных коллекциях запрещен.

2. Атомарные составные операции (Compound Actions)

Главная опасность при работе с потокобезопасными коллекциями — иллюзия безопасности составных действий (Check-Then-Act):

// ❌ АНТИПАТТЕРН: гонка между двумя вызовами!
if (!map.containsKey("counter")) {
    map.put("counter", 1); // Другой поток мог вклиниться между проверкой и вставкой!
}

// ✅ ПРАВИЛЬНО: атомарные методы ConcurrentMap
map.putIfAbsent("counter", 1);

// ✅ Атомарное обновление через лямбду (Java 8+):
map.compute("counter", (k, v) -> (v == null) ? 1 : v + 1);

// ✅ Идеальный потокобезопасный счетчик через merge:
map.merge("counter", 1, Integer::sum);

3. Слабосогласованные итераторы (Weakly Consistent Iterators)

Итераторы ConcurrentHashMap не выбрасывают ConcurrentModificationException:

Они называются Weakly Consistent (слабосогласованными).
Они отражают состояние коллекции на момент создания итератора и гарантированно проходят по всем элементам, существовавшим на тот момент.
Они могут (но не обязаны) увидеть изменения, совершенные параллельными потоками после создания итератора.
Они никогда не дублируют элементы и не падают при параллельных модификациях.

🔴 Senior Level

1. Архитектура подсчета размера: `CounterCell` и `mappingCount()`

В высоконагруженной системе обычное поле volatile int size стало бы непреодолимым барьером для масштабирования: каждое обновление любого бакета требовало бы атомарной модификации одной переменной, порождая постоянную инвалидацию кэш-линий процессора (Cache Coherence Traffic).

Вместо этого ConcurrentHashMap использует подход, аналогичный LongAdder:

Базовый счетчик baseCount.
Массив страйпированных ячеек CounterCell[] counterCells.
Если поток встречает конкуренцию при CAS-инкременте baseCount, он переключается на свою ячейку в counterCells по системному хэшу потока.
Метод size() суммирует baseCount и значения всех активных ячеек. Результат является оценочным (приблизительным на наносекунду вызова).

// Для коллекций, где число записей может превысить Integer.MAX_VALUE (2 млрд):
long totalMappings = map.mappingCount(); // Предпочтительнее size()

2. Ловушки метода `computeIfAbsent()`: взаимные блокировки (Deadlocks)

Хотя метод computeIfAbsent() чрезвычайно удобен, его неосторожное использование в highload может заморозить приложение:

// ❌ ЛОВУШКА 1: Блокирующие вызовы внутри лямбды
map.computeIfAbsent("token", k -> {
    return httpClient.fetchRemoteToken(); // ОПАСНО! Держит блокировку на бакете секундами!
});

Во время выполнения переданной лямбды бакет заблокирован по монитору его головного узла. Все остальные потоки, пытающиеся обратиться к любому ключу из этого же бакета, повисают в состоянии BLOCKED.

// ❌ ЛОВУШКА 2: Взаимная блокировка (Deadlock)
Map<Integer, Integer> map = new ConcurrentHashMap<>();
map.computeIfAbsent(1, k1 -> {
    // Попытка вычислить другой ключ, попадающий в тот же или соседний бакет:
    return map.computeIfAbsent(2, k2 -> 42); // ГАРАНТИРОВАННЫЙ DEADLOCK!
});

🎯 Шпаргалка для интервью

30-секундный ответ (Elevator Pitch)

«ConcurrentHashMap — это промышленная потокобезопасная хэш-таблица, оптимизированная для параллельной работы множества потоков. В отличие от Hashtable и Collections.synchronizedMap, использующих блокировку всего объекта, ConcurrentHashMap реализует чтение без блокировок (Lock-Free через volatile) и блокирует только заголовок конкретного бакета при записи (synchronized(head) в Java 8+). Коллекция категорически запрещает null для ключей и значений ради исключения неоднозначности в многопоточности, использует слабосогласованные итераторы без ConcurrentModificationException и масштабируемый счетчик размера на базе CounterCell».

3 каверзных вопроса на интервью с ответами

1. Почему `ConcurrentHashMap.size()` не возвращает абсолютно точное значение в каждый момент времени?

Ответ: В распределенной параллельной среде зафиксировать мгновенный размер структуры без блокировки всех пишущих потоков физически невозможно. Подсчет размера складывает базовое поле baseCount и ячейки CounterCell[]. Пока процессор суммирует ячейки, параллельные потоки продолжают вставлять и удалять элементы. Поэтому возвращаемое значение size() является срезом состояния (Weakly Consistent), достаточным для мониторинга, но не предназначенным для строгой транзакционной логики.

2. Зачем разработчики запретили `null` в `ConcurrentHashMap`, если обычный `HashMap` отлично работает с `null`?

Ответ: По контракту Map.get(k) возвращает null, если ключ отсутствует. Если бы значение null было разрешено, результат get(k) == null имел бы два объяснения: «ключа нет» или «ключ есть, но значение null». В однопоточном коде это решается вызовом containsKey(k). В конкурентной среде между вызовами get() и containsKey() другой поток может удалить ключ, превратив результат проверки в ложь (Race Condition). Запрет null устраняет этот класс ошибок.

3. В чём разница между архитектурой `ConcurrentHashMap` в Java 7 и Java 8+?

Ответ:

В Java 7 использовалось сегментирование (Segment-Level Locking): мапа делилась на фиксированное число сегментов (по умолчанию 16), каждый из которых наследовал ReentrantLock. Потоки могли параллельно модифицировать разные сегменты, но внутри одного сегмента блокировались.
В Java 8+ от сегментов полностью отказались в пользу гранулярности на уровне бакета (Node-Level Locking). Если бакет пуст, нода вставляется через атомарный CAS без блокировок. Если бакет занят, захватывается монитор только первого элемента бакета (synchronized(node)). Это снизило оверхед по памяти и подняло уровень параллелизма до количества непустых бакетов.

Типичные ошибки и Red Flags

❌ Утверждение, что ConcurrentHashMap блокирует сегменты в современных версиях: Сегменты остались в прошлом с выходом Java 8 в 2014 году.
❌ Выполнение тяжелых внешних операций (I/O, сетевые вызовы) внутри computeIfAbsent: Приводит к исчерпанию пула потоков из-за блокировки бакета.
❌ Попытка положить null: Завершится немедленным NullPointerException.
❌ Использование конструкции if (!map.containsKey) map.put вместо putIfAbsent: Потеря потокобезопасности из-за неатомарного составного действия.

🟢 Junior Level

1. Что такое ConcurrentHashMap

2. Сравнительная таблица реализаций

🟡 Middle Level

1. Почему ConcurrentHashMap категорически запрещает null?