Чому ConcurrentHashMap запобігає нульовим ключам і значенням?

JavaDoc ConcurrentHashMapговорить про це:

Як Hashtableі на відміну від HashMapцього, цей клас не дозволяє nullвикористовуватись як ключ або значення.

Моє запитання: Чому?

2-е питання: Чому не Hashtableдозволити нуль?

Я використовував багато HashMaps для зберігання даних. Але при переході до ConcurrentHashMapмене кілька разів потрапляли проблеми через NullPointerExceptions.

Від самого автора ConcurrentHashMap(Дуг Леа) :

Основна причина того, що нулі заборонені в ConcurrentMaps (ConcurrentHashMaps, ConcurrentSkipListMaps), полягає в тому, що двозначності, які можуть бути ледь терпимими в картах, що не є одночасними, не можуть бути розміщені. Основна з них полягає в тому, що якщо map.get(key)повертається null, ви не можете виявити, чи ключ явно відображається в nullпорівнянні з ключем, не відображається. У несумісній карті ви можете перевірити це за допомогою map.contains(key), але в паралельній карті карта може змінитися між викликами.

Я вважаю , що це, принаймні частково, дозволяють об'єднувати containsKeyі getв один виклик. Якщо карта може містити нулі, немає способу визначити, чи getповертає нуль, тому що для цього значення не було ключа або просто тому, що значення було нульовим.

Чому це проблема? Тому що немає безпечного способу зробити це самостійно. Візьміть наступний код:

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

Оскільки mце паралельна карта, ключ k може бути видалений між викликами containsKeyта getвикликами, внаслідок чого цей фрагмент повертає нуль, який ніколи не був у таблиці, а не бажаний KeyNotPresentException.

Зазвичай ви вирішите це шляхом синхронізації, але з одночасною картою, що, звичайно, не буде працювати. Отже, підпис для getдовелося змінити, і єдиним способом зробити це за допомогою сумісного ззаду способу було запобігти користувачеві вводити в першу чергу нульові значення та продовжувати використовувати це як заповнювач для "ключа не знайдено".

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

Неможливо синхронізувати на нулі.

Редагувати: Це не зовсім так у цьому випадку. Спочатку я думав, що відбувається щось фантазійне з блокуванням речей проти одночасних оновлень або іншим способом використання монітора Об'єктів, щоб виявити, чи щось було змінено, але після вивчення вихідного коду виявляється, я помилявся - вони блокують за допомогою "сегмента" на основі бітмаска хешу.

У цьому випадку я підозрюю, що вони зробили це для копіювання Hashtable, і я підозрюю, що Hashtable це зробив, оскільки у світі реляційних баз даних null! = Null, тому використання null як ключа не має значення.

ConcurrentHashMap є безпечним для потоків. Я вважаю, що заборона нульових ключів і значень була частиною того, щоб переконатися в безпеці потоку.

Я думаю, що наступний фрагмент документації API дає хороший натяк: "Цей клас повністю взаємодіє з Hashtable в програмах, які покладаються на його безпеку потоку, але не на його дані про синхронізацію."

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

Я не думаю, що заборона нульового значення є правильним варіантом. У багатьох випадках ми хочемо ввести ключ з нульовим значенням на поточну карту. Однак, використовуючи ConcurrentHashMap, ми не можемо цього зробити. Я вважаю, що наступна версія JDK може це підтримати.