Por que o ConcurrentHashMap impede chaves e valores nulos?

O JavaDoc de ConcurrentHashMapdiz o seguinte:

De maneira semelhante, Hashtablemas diferente HashMap, essa classe não permite nullser usada como chave ou valor.

Minha pergunta: por que?

2ª pergunta: Por que não Hashtablepermite nulo?

Eu usei muitos HashMaps para armazenar dados. Mas, ao mudar para ConcurrentHashMap, fiquei várias vezes com problemas por causa de NullPointerExceptions.

Do autor de ConcurrentHashMapsi mesmo (Doug Lea) :

O principal motivo pelo qual nulos não são permitidos no ConcurrentMaps (ConcurrentHashMaps, ConcurrentSkipListMaps) é que ambiguidades que podem ser apenas toleráveis ​​em mapas não simultâneos não podem ser acomodadas. A principal é que, se map.get(key)retornar null, você não poderá detectar se nulla chave é mapeada explicitamente para a tecla vs não está mapeada. Em um mapa não concorrente, você pode verificar isso via map.contains(key), mas em um concorrente, o mapa pode ter mudado entre as chamadas.

Acredito que é, pelo menos em parte, permitir que você combine containsKeye faça getuma única ligação. Se o mapa puder conter nulos, não há como saber se getestá retornando um nulo porque não havia chave para esse valor ou apenas porque o valor era nulo.

Por que isso é um problema? Porque não há maneira segura de fazer isso sozinho. Pegue o seguinte código:

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

Como mé um mapa simultâneo, a chave k pode ser excluída entre as chamadas containsKeye get, fazendo com que esse trecho retorne um nulo que nunca estava na tabela, e não o desejado KeyNotPresentException.

Normalmente você resolveria isso sincronizando, mas com um mapa simultâneo que, obviamente, não funcionaria. Daí a assinatura paraget teve que mudar, e a única maneira de fazer isso de maneira compatível com versões anteriores era impedir o usuário inserir valores nulos em primeiro lugar e continuar usando-o como um espaço reservado para "chave não encontrada".

Josh Bloch projetou HashMap; Doug Lea projetou ConcurrentHashMap. Espero que não seja difamatório. Na verdade, acho que o problema é que os nulos geralmente exigem quebra automática para que o nulo real possa significar não inicializado. Se o código do cliente exigir nulos, ele poderá pagar o custo (reconhecidamente pequeno) de agrupar os nulos.

Você não pode sincronizar em um nulo.

Edit: Não é exatamente por isso que neste caso. Inicialmente, pensei que havia algo extravagante em bloquear as atualizações simultâneas ou usar o monitor de objetos para detectar se algo foi modificado, mas, ao examinar o código - fonte , parece que eu estava errado - eles bloqueiam usando um "segmento" baseado em um máscara de bit do hash.

Nesse caso, suspeito que eles fizeram isso para copiar o Hashtable, e suspeito que o Hashtable fez isso porque no mundo do banco de dados relacional, null! = Null, portanto, usar um null como chave não tem significado.

ConcurrentHashMap é seguro para threads. Acredito que não permitir chaves e valores nulos fazia parte de garantir que seja seguro para threads.

Acho que o seguinte trecho da documentação da API fornece uma boa dica: "Essa classe é totalmente interoperável com o Hashtable em programas que dependem da segurança do encadeamento, mas não dos detalhes da sincronização".

Eles provavelmente só queriam tornar ConcurrentHashMaptotalmente compatíveis / intercambiáveis ​​para Hashtable. E como Hashtablenão permite chaves e valores nulos.

Eu não acho que não permitir valor nulo é uma opção correta. Em muitos casos, queremos colocar uma chave com valor nulo no mapa atual. No entanto, usando ConcurrentHashMap, não podemos fazer isso. Sugiro que a próxima versão do JDK possa suportar isso.