Pourquoi ConcurrentHashMap empêche-t-il les clés et valeurs nulles?

Le JavaDoc de ConcurrentHashMapdit ceci:

Comme Hashtablemais contrairement HashMap, cette classe ne permet pasnull d'être utilisée comme clé ou valeur.

Ma question: pourquoi?

2ème question: pourquoi n'autorise pas la valeur HashtableNULL?

J'ai utilisé beaucoup de HashMaps pour stocker des données. Mais lors du passage à, ConcurrentHashMapj'ai eu plusieurs fois des ennuis à cause de NullPointerExceptions.

De l'auteur de ConcurrentHashMaplui - même (Doug Lea) :

La raison principale pour laquelle les valeurs nulles ne sont pas autorisées dans ConcurrentMaps (ConcurrentHashMaps, ConcurrentSkipListMaps) est que les ambiguïtés qui peuvent être à peine tolérables dans les cartes non simultanées ne peuvent pas être prises en compte. Le principal est que si map.get(key)retourne null, vous ne pouvez pas détecter si la clé est explicitement nullmappée à vs la clé n'est pas mappée. Dans une carte non simultanée, vous pouvez vérifier cela via map.contains(key), mais dans une carte simultanée, la carte peut avoir changé entre les appels.

Je crois que c'est, au moins en partie, pour vous permettre de combiner containsKeyet geten un seul appel. Si la carte peut contenir des valeurs nulles, il n'y a aucun moyen de dire siget renvoie une valeur nulle car il n'y avait pas de clé pour cette valeur, ou simplement parce que la valeur était nulle.

Pourquoi c'est un problème? Parce qu'il n'y a pas de moyen sûr de le faire vous-même. Prenez le code suivant:

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

Puisqu'il ms'agit d'une mappe simultanée, la clé k peut être supprimée entre les appels containsKeyet get, ce qui fait que cet extrait de code renvoie une valeur null qui n'a jamais été dans la table, plutôt que celle souhaitéeKeyNotPresentException .

Normalement, vous résoudriez cela en synchronisant, mais avec une carte simultanée, cela ne fonctionnera bien sûr pas. Par conséquent, la signature pour getdevait changer, et la seule façon de le faire d'une manière rétrocompatible était d'empêcher l'utilisateur d'insérer des valeurs nulles en premier lieu, et de continuer à l'utiliser comme espace réservé pour "clé non trouvée".

Josh Bloch a conçu HashMap; Doug Lea a conçu ConcurrentHashMap. J'espère que ce n'est pas diffamatoire. En fait, je pense que le problème est que les nulls nécessitent souvent un wrapping afin que le vrai null puisse représenter non initialisé. Si le code client nécessite des valeurs nulles, il peut payer le coût (certes faible) de l'encapsulation des valeurs nulles lui-même.

Vous ne pouvez pas synchroniser sur une valeur nulle.

Edit: Ce n'est pas exactement pourquoi dans ce cas. J'ai d'abord pensé qu'il se passait quelque chose d'extraordinaire avec le verrouillage des choses contre les mises à jour simultanées ou l'utilisation du moniteur d'objets pour détecter si quelque chose avait été modifié, mais en examinant le code source il semble que j'avais tort - ils se verrouillent à l'aide d'un «segment» basé sur masque binaire du hachage.

Dans ce cas, je soupçonne qu'ils l'ont fait pour copier Hashtable, et je suppose que Hashtable l'a fait parce que dans le monde des bases de données relationnelles, null! = Null, donc utiliser un null comme clé n'a aucune signification.

ConcurrentHashMap est thread-safe. Je crois que ne pas autoriser les clés et les valeurs nulles faisait partie de la garantie de la sécurité des threads.

Je suppose que l'extrait suivant de la documentation de l'API donne un bon indice: "Cette classe est entièrement interopérable avec Hashtable dans les programmes qui reposent sur sa sécurité de thread mais pas sur ses détails de synchronisation."

Ils voulaient probablement juste rendre ConcurrentHashMapentièrement compatible / interchangeable Hashtable. Et comme Hashtablen'autorise pas les clés et valeurs nulles.

Je ne pense pas que l'interdiction de la valeur nulle soit une option correcte. Dans de nombreux cas, nous voulons mettre une clé avec une valeur nulle dans la carte concourante. Cependant, en utilisant ConcurrentHashMap, nous ne pouvons pas faire cela. Je suggère que la prochaine version de JDK puisse prendre en charge cela.