Perché ConcurrentHashMap impedisce chiavi e valori null?

JavaDoc di ConcurrentHashMapdice questo:

Come Hashtablema diversamente HashMap, questa classe non consente nulldi essere utilizzata come chiave o valore.

La mia domanda: perché?

2a domanda: Perché non Hashtableconsentire null?

Ho usato molte HashMaps per l'archiviazione dei dati. Ma quando ConcurrentHashMapmi sono trasformato in ho avuto diverse volte nei guai a causa di NullPointerExceptions.

Dall'autore di ConcurrentHashMapse stesso (Doug Lea) :

Il motivo principale per cui i valori null non sono consentiti in ConcurrentMaps (ConcurrentHashMaps, ConcurrentSkipListMaps) è che le ambiguità che possono essere appena tollerabili a malapena nelle mappe non simultanee non possono essere sistemate. Il principale è che se map.get(key)ritorna null, non è possibile rilevare se nullla chiave è mappata esplicitamente rispetto alla chiave non è mappata. In una mappa non simultanea, puoi verificarla tramite map.contains(key), ma in una mappa simultanea, la mappa potrebbe essere cambiata tra le chiamate.

Credo che sia, almeno in parte, per permetterti di combinare containsKeye getin una singola chiamata. Se la mappa può contenere valori null, non è possibile stabilire se getrestituisce un valore null perché non esiste una chiave per quel valore o semplicemente perché il valore era null.

Perchè questo è un problema? Perché non esiste un modo sicuro per farlo da soli. Prendi il seguente codice:

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

Poiché mè una mappa simultanea, la chiave k può essere eliminata tra le chiamate containsKeye get, facendo sì che questo snippet restituisca un valore null che non è mai stato nella tabella, piuttosto che quello desiderato KeyNotPresentException.

Normalmente lo risolveresti sincronizzando, ma con una mappa simultanea che ovviamente non funzionerà. Quindi la firma per getdoveva cambiare, e l'unico modo per farlo in un modo retrocompatibile era impedire all'utente di inserire valori null in primo luogo e continuare a usarlo come segnaposto per "chiave non trovata".

Josh Bloch progettato HashMap; Doug Lea ha progettato ConcurrentHashMap. Spero che non sia diffamatorio. In realtà penso che il problema sia che i null spesso richiedono il wrapping in modo che il vero null possa essere considerato non inizializzato. Se il codice client richiede valori null, può pagare il costo (dichiaratamente piccolo) del wrapping dei valori null stessi.

Non è possibile eseguire la sincronizzazione su null.

Modifica: questo non è esattamente il motivo per cui in questo caso. Inizialmente pensavo che ci fosse qualcosa di fantasioso nel bloccare le cose contro gli aggiornamenti simultanei o altrimenti usando il monitor degli oggetti per rilevare se qualcosa fosse stato modificato, ma dopo aver esaminato il codice sorgente sembra che mi sbagliassi - si bloccano usando un "segmento" basato su un maschera di bit dell'hash.

In quel caso, sospetto che lo abbiano fatto per copiare Hashtable, e sospetto che Hashtable lo abbia fatto perché nel mondo del database relazionale, null! = Null, quindi usare un null come chiave non ha significato.

ConcurrentHashMap è thread-safe. Ritengo che non consentire chiavi e valori null sia stato parte integrante della verifica della sicurezza dei thread.

Suppongo che il seguente frammento della documentazione dell'API fornisca un buon suggerimento: "Questa classe è completamente interoperabile con Hashtable in programmi che si basano sulla sicurezza del thread ma non sui dettagli di sincronizzazione".

Probabilmente volevano solo renderlo ConcurrentHashMapcompletamente compatibile / intercambiabile Hashtable. E poiché Hashtablenon consente chiavi e valori null.

Non credo che non consentire il valore null sia un'opzione corretta. In molti casi, vogliamo inserire una chiave con valore null nella mappa con-corrente. Tuttavia, utilizzando ConcurrentHashMap, non possiamo farlo. Suggerisco che la prossima versione di JDK possa supportarlo.