tgoop.com/Java_Iibrary/1763
Last Update:
Если HashMap позволяет null, почему ConcurrentHashMap при тех же операциях кидает NullPointerException?
В HashMap можно хранить один ключ null и любое количество значений null. В ConcurrentHashMap любое использование null (ключ или значение) вызывает NullPointerException. Разница здесь в ясности и безопасности работы в многопоточной среде.
В однопоточном HashMap, если map.get(k) возвращает null, можно уточнить через map.containsKey(k). Этот двухшаговый подход работает, потому что между вызовами никто не меняет карту.
В многопоточном окружении такой трюк ломается. Поток A может вызвать containsKey(k) и увидеть ключ. До того как он вызовет get(k), поток B может удалить эту запись. Теперь get(k) вернёт null, и поток A не сможет понять, было ли значение реально null или запись исчезла между вызовами. Двухшаговая проверка не атомарна и ненадёжна.
Атомарные методы вроде putIfAbsent, computeIfAbsent и replace тоже используют null как “отсутствие отображения”. Если бы null был допустимым значением, эти методы становились бы неоднозначными или требовали бы обёрток и дополнительных проверок, усложняя API и реализацию.
Запрещая null в ключах и значениях, ConcurrentHashMap гарантирует, что get(k) == null всегда и однозначно означает “нет отображения”. Это упрощает API, делает семантику ясной и позволяет эффективно работать в многопоточном режиме.
