¿Por qué ConcurrentHashMap evita claves y valores nulos?

El JavaDoc de ConcurrentHashMapdice esto:

Me gusta Hashtablepero HashMapno me gusta , esta clase no permite nullser utilizada como clave o valor.

Mi pregunta: ¿por qué?

2da pregunta: ¿Por qué no Hashtablepermite nulo?

He usado muchos HashMaps para almacenar datos. Pero al cambiar a ConcurrentHashMapMe metí en problemas varias veces debido a NullPointerExceptions.

Del autor de ConcurrentHashMapsí mismo (Doug Lea) :

La razón principal por la que no se permiten nulos en ConcurrentMaps (ConcurrentHashMaps, ConcurrentSkipListMaps) es que las ambigüedades que pueden ser apenas tolerables en mapas no concurrentes no se pueden acomodar. La principal es que si map.get(key)regresa null, no puede detectar si la clave se asigna explícitamente a nullla clave no está asignada. En un mapa no concurrente, puede verificar esto a través de map.contains(key), pero en uno concurrente, el mapa puede haber cambiado entre llamadas.

Creo que es, al menos en parte, para que pueda combinar containsKeyy geten una sola llamada. Si el mapa puede contener nulos, no hay forma de saber si getestá devolviendo un valor nulo porque no había una clave para ese valor, o simplemente porque el valor era nulo.

¿Por que eso es un problema? Porque no hay una forma segura de hacerlo tú mismo. Toma el siguiente código:

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

Como mes un mapa concurrente, la clave k puede eliminarse entre las llamadas containsKeyy get, lo que hace que este fragmento devuelva un valor nulo que nunca estuvo en la tabla, en lugar de lo deseado KeyNotPresentException.

Normalmente lo resolverías sincronizando, pero con un mapa concurrente que, por supuesto, no funcionará. Por lo tanto, la firma de gettuvo que cambiar, y la única forma de hacerlo de una manera compatible con versiones anteriores era evitar que el usuario inserte valores nulos en primer lugar, y continuar usándolo como un marcador de posición para "clave no encontrada".

Josh Bloch diseñado HashMap; Doug Lea diseñado ConcurrentHashMap. Espero que eso no sea calumnioso. En realidad, creo que el problema es que los nulos a menudo requieren envoltura para que el nulo real pueda significar sin inicializar. Si el código del cliente requiere valores nulos, entonces puede pagar el costo (ciertamente pequeño) de envolver los valores nulos.

No se puede sincronizar en un nulo.

Editar: Esto no es exactamente por qué en este caso. Inicialmente pensé que estaba ocurriendo algo interesante al bloquear cosas contra actualizaciones concurrentes o usar el monitor de objetos para detectar si algo se modificó, pero al examinar el código fuente parece que estaba equivocado: se bloquean usando un "segmento" basado en un máscara de bits del hash.

En ese caso, sospecho que lo hicieron para copiar Hashtable, y sospecho que Hashtable lo hizo porque en el mundo de la base de datos relacional, null! = Null, por lo que usar un nulo como clave no tiene sentido.

ConcurrentHashMap es seguro para subprocesos. Creo que no permitir claves y valores nulos fue parte de garantizar que sea seguro para subprocesos.

Supongo que el siguiente fragmento de la documentación de la API da una buena pista: "Esta clase es totalmente interoperable con Hashtable en programas que dependen de la seguridad de su hilo pero no de sus detalles de sincronización".

Probablemente solo querían hacer que sea ConcurrentHashMaptotalmente compatible / intercambiable Hashtable. Y como Hashtableno permite claves y valores nulos.

No creo que rechazar el valor nulo sea una opción correcta. En muchos casos, queremos poner una clave con valor nulo en el mapa actual. Sin embargo, al usar ConcurrentHashMap, no podemos hacer eso. Sugiero que la próxima versión de JDK pueda soportar eso.