Dlaczego ConcurrentHashMap zapobiega pustym kluczom i wartościom?

JavaDoc ConcurrentHashMapmówi tak:

Podobnie jak, Hashtableale w przeciwieństwie do HashMaptej klasy, ta klasa nie pozwala nullna użycie jako klucza lub wartości.

Moje pytanie: dlaczego?

Drugie pytanie: Dlaczego nie Hashtablezezwala na null?

Używałem wielu HashMap do przechowywania danych. Ale przy zmianie na ConcurrentHashMapkilka razy miałem kłopoty z powodu wyjątków NullPointerExceptions.

Od samego autora ConcurrentHashMap(Doug Lea) :

Głównym powodem, dla którego wartości null nie są dozwolone w ConcurrentMaps (ConcurrentHashMaps, ConcurrentSkipListMaps), jest to, że nie można uwzględnić niejednoznaczności, które mogą być ledwo tolerowane w mapach innych niż współbieżne. Głównym z nich jest to, że jeśli map.get(key)powróci null, nie można wykryć, czy klucz jawnie mapuje się, nulla klucz nie jest mapowany. Na mapie, która nie jest współbieżna, możesz to sprawdzić za pośrednictwem map.contains(key), ale w przypadku mapy współbieżnej mapa mogła się zmieniać między wywołaniami.

Uważam, że przynajmniej częściowo umożliwia to połączenie containsKeyi getutworzenie jednej rozmowy. Jeśli mapa może przechowywać wartości null, nie ma sposobu, aby stwierdzić, czy getzwraca wartość null, ponieważ nie było klucza dla tej wartości, czy tylko dlatego, że wartość była pusta.

Dlaczego to jest problemem? Ponieważ nie ma na to bezpiecznego sposobu. Weź następujący kod:

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

Ponieważ mjest to mapa współbieżna, klucz k może zostać usunięty między wywołaniami containsKeyi get, powodując, że ten fragment kodu zwraca wartość null, której nigdy nie było w tabeli, zamiast pożądanego KeyNotPresentException.

Zwykle można to rozwiązać przez synchronizację, ale z mapą współbieżną to oczywiście nie zadziała. W związku z tym podpis for getmusiał się zmienić, a jedynym sposobem, aby to zrobić w sposób zgodny z poprzednimi wersjami, było uniemożliwienie użytkownikowi wstawiania wartości null w pierwszej kolejności i dalsze używanie tego jako symbolu zastępczego dla „klucza nie znaleziono”.

Josh Bloch zaprojektował HashMap; Zaprojektował Doug Lea ConcurrentHashMap. Mam nadzieję, że to nie jest zniesławiające. Właściwie myślę, że problem polega na tym, że wartości null często wymagają zawijania, aby prawdziwy null mógł oznaczać niezainicjowany. Jeśli kod klienta wymaga wartości null, może zapłacić (co prawda niewielki) koszt pakowania wartości null.

Nie możesz synchronizować wartości null.

Edycja: w tym przypadku nie jest to dokładnie powód. Początkowo myślałem, że dzieje się coś wymyślnego z blokowaniem rzeczy przed równoczesnymi aktualizacjami lub w inny sposób korzystaniem z monitora obiektów do wykrywania, czy coś zostało zmodyfikowane, ale po zbadaniu kodu źródłowego wydaje się, że się myliłem - blokują używając „segmentu” opartego na maska ​​bitowa skrótu.

W takim przypadku podejrzewam, że zrobili to, aby skopiować Hashtable, i podejrzewam, że Hashtable to zrobił, ponieważ w świecie relacyjnych baz danych null! = Null, więc użycie null jako klucza nie ma żadnego znaczenia.

ConcurrentHashMap jest bezpieczna wątkowo. Uważam, że niedopuszczenie pustych kluczy i wartości było częścią upewnienia się, że jest bezpieczny dla wątków.

Wydaje mi się, że poniższy fragment dokumentacji API daje dobrą wskazówkę: „Ta klasa jest w pełni interoperacyjna z Hashtable w programach, które polegają na bezpieczeństwie wątków, ale nie na szczegółach synchronizacji”.

Prawdopodobnie chcieli tylko, aby w ConcurrentHashMappełni kompatybilny / wymienny z Hashtable. A ponieważ Hashtablenie zezwala na puste klucze i wartości.

Nie sądzę, aby odrzucenie wartości null było właściwą opcją. W wielu przypadkach chcemy umieścić klucz z wartością null w mapie współbieżnej. Jednak używając ConcurrentHashMap, nie możemy tego zrobić. Sugeruję, że nadchodząca wersja JDK może to wspierać.