Почему ConcurrentHashMap предотвращает нулевые ключи и значения?

В JavaDoc ConcurrentHashMapговорится следующее:

Как , Hashtableно в отличие от HashMap, этот класс никак не позволяет nullиспользовать в качестве ключа или значения.

Мой вопрос: почему?

2-й вопрос: почему не Hashtableразрешено null?

Я использовал много HashMaps для хранения данных. Но при переходе на ConcurrentHashMapнесколько раз у меня возникали проблемы из-за NullPointerExceptions.

От самого автора ConcurrentHashMap(Дуга Ли) :

Основная причина того, что значения NULL не допускаются в ConcurrentMaps (ConcurrentHashMaps, ConcurrentSkipListMaps), заключается в том, что неоднозначности, которые могут быть едва терпимыми в непараллельных картах, не могут быть учтены. Главный из них заключается в том, что если map.get(key)возвращается null, вы не можете определить, отображается ли ключ явно в nullvs, ключ не отображается. В непараллельной карте вы можете проверить это через map.contains(key), но в параллельной карта могла измениться между вызовами.

Я считаю , что это, по крайней мере частично, позволяют объединять containsKeyи getв один вызов. Если карта может содержать значения NULL, невозможно определить, getвозвращает ли значение NULL, потому что не было ключа для этого значения или просто потому, что значение было нулевым.

Почему это проблема? Потому что нет безопасного способа сделать это самостоятельно. Возьмите следующий код:

if (m.containsKey(k)) {
   return m.get(k);
} else {
   throw new KeyNotPresentException();
}

Поскольку mэто одновременное отображение, ключ к может быть удален между containsKeyи getвызовов, в результате чего этот фрагмент кода , чтобы возвратить нуль , что никогда не был в таблице, а не желаемое KeyNotPresentException.

Обычно вы решаете это путем синхронизации, но с параллельной картой это, конечно, не сработает. Следовательно, подпись для getдолжна была быть изменена, и единственный способ сделать это обратно совместимым способом - не допустить, чтобы пользователь вставлял нулевые значения в первую очередь, и продолжать использовать это как заполнитель для «ключ не найден».

Дизайн Джоша Блоха HashMap; Дизайн Дуга Ли ConcurrentHashMap. Надеюсь, это не клевета. На самом деле я думаю, что проблема в том, что нули часто требуют переноса, чтобы реальный ноль мог обозначать неинициализированный. Если клиентскому коду требуются значения NULL, он может оплатить (по общему признанию небольшую) стоимость самой упаковки NULL.

Вы не можете синхронизировать по нулю.

Изменить: это не совсем то, почему в этом случае. Сначала я подумал, что происходит что-то необычное с блокировкой чего-либо против одновременных обновлений или иным образом с использованием монитора объектов для определения того, было ли что-то изменено, но после изучения исходного кода оказалось, что я ошибался - они блокируют использование «сегмента» на основе битовая маска хеша.

В этом случае я подозреваю, что они сделали это для копирования Hashtable, и я подозреваю, что Hashtable сделал это, потому что в мире реляционных баз данных null! = Null, поэтому использование null в качестве ключа не имеет смысла.

ConcurrentHashMap является потокобезопасным. Я считаю, что запрет на использование пустых ключей и значений был частью обеспечения потоковой безопасности.

Я предполагаю, что следующий фрагмент документации API дает хороший намек: «Этот класс полностью совместим с Hashtable в программах, которые полагаются на его безопасность потоков, но не на его детали синхронизации».

Вероятно, они просто хотели сделать ConcurrentHashMapполностью совместимыми / взаимозаменяемыми Hashtable. А так Hashtableже не допускает нулевых ключей и значений ..

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