Как трактовать результат size() у ConcurrentHashMap во время одновременных изменений?
Результат size() у ConcurrentHashMap во время конкурентных изменений не является согласованным снимком карты. Он может отражать промежуточное состояние и подходит для наблюдения, но не для принятия строгих решений, требующих точного количества элементов в один логический момент.
После завершения всех параллельных изменений вызов size() возвращает актуальное количество отображений, если карта больше не изменяется.
Обычная синхронизация всей карты позволила бы получать согласованный размер, но одновременно блокировала бы независимые операции чтения и записи. ConcurrentHashMap проектировалась для высокой конкурентности: разные потоки могут работать с картой без единой глобальной блокировки на каждую операцию.
Подсчёт общего числа элементов в такой структуре сложнее, чем в однопоточной коллекции. Пока один поток добавляет запись, другой удаляет её, а третий вызывает size(), нельзя без дополнительной координации получить единый снимок всех изменений.
Предположим, программа проверяет size(), а затем решает, можно ли добавить элемент, удалить ли старейшую запись или считать кэш пустым. Между проверкой и последующей операцией другой поток может изменить карту, поэтому полученное число уже не гарантирует прежнее состояние.
Даже если само выполнение size() безопасно, это не превращает последовательность из нескольких операций в атомарную транзакцию. Ошибка возникает, когда точный результат агрегатного метода используют как условие корректности конкурентного алгоритма.
ConcurrentHashMap поддерживает счётчик элементов с учётом конкурентных обновлений. При высокой конкуренции обновления могут распределяться по внутренним счётчикам, а size() агрегирует их значение; параллельные добавления и удаления при этом могут ещё продолжаться.
Поэтому метод не обязан соответствовать одному согласованному состоянию карты, существовавшему в определённый момент времени. Документация отдельно предупреждает, что агрегатные методы, включая size(), особенно полезны для мониторинга, когда карта не изменяется, но их результат во время обновлений может быть переходным.
Это не означает, что size() возвращает произвольное число или нарушает тип int. Результат ограничен текущим представлением карты и может быть точным в конкретном запуске, но контракт не позволяет строить на нём гарантию согласованности с последующими операциями.
Метод mappingCount() возвращает long и полезен для карт, размер которых теоретически может превышать диапазон int. Однако он имеет ту же проблему согласованности во время конкурентных изменений: больший тип результата не делает операцию снимком.
Если алгоритму нужна атомарная проверка вместе с изменением, следует использовать составную операцию карты, например условную вставку или удаление, либо защищать всю последовательность общим механизмом синхронизации. Для точного согласованного снимка можно временно остановить изменения и скопировать содержимое, понимая стоимость такой координации.
В сервисе ограниченного кэша разработчик проверял size(), и если число записей достигало лимита, удалял один элемент перед добавлением нового. При нескольких потоках два потока могли одновременно увидеть допустимый размер, после чего оба добавить записи. В результате лимит временно нарушался, несмотря на потокобезопасность самой карты.
Рассматривались три варианта. Обычный HashMap с полной синхронизацией давал простой и легко проверяемый инвариант, но снижал параллелизм. Отдельный атомарный счётчик был быстрее, однако требовал согласованного обновления при каждом успешном добавлении, удалении и откате после исключений. Использование одного size() оставляло гонку и не обеспечивало лимит.
Выбрали явную координацию операции ограничения: решение о вытеснении и добавлении выполнялось под общим механизмом синхронизации, тогда как независимые операции чтения оставались конкурентными. Это устранило нарушение лимита; цена решения — сериализация только критического участка, а не всех обращений к кэшу.
size() линейризуемой операцией у ConcurrentHashMap?Нет, из контракта нельзя выводить линейризуемость результата во время параллельных обновлений. Линейризуемая операция должна выглядеть так, будто целиком произошла в одной точке времени между началом и концом вызова. Для агрегатного размера карта допускает наблюдение переходного состояния, поэтому такой гарантии нет.
Это не следует путать с потокобезопасностью метода: вызов не повреждает внутреннее состояние структуры и не требует внешней блокировки только для самого чтения размера. Но безопасность отдельного вызова не означает атомарность сценария проверить размер — изменить карту.
mappingCount() проблему неточного размера?Нет. mappingCount() отличается прежде всего возвращаемым типом: он использует long, поэтому не ограничен диапазоном int, как size(). Во время конкурентных изменений его значение также не следует трактовать как согласованный снимок.
Метод полезен для статистики и приблизительного контроля размера больших карт. Для строгого лимита или проверки инварианта требуется атомарная координация самой операции, а не только замена size() на mappingCount().
isEmpty()?isEmpty() безопасен как отдельный вызов, но не гарантирует, что карта останется пустой после его возврата. Другой поток может добавить запись сразу после проверки; аналогично, последний элемент может быть удалён параллельно с проверкой.
Поэтому isEmpty() подходит для диагностического наблюдения или цикла, который корректно допускает изменение состояния. Если пустота должна быть условием атомарного действия, нужно объединить проверку и действие в синхронизированный протокол либо использовать операцию с соответствующим условным контрактом.