Est-il possible d'obtenir des valeurs d'une table de hachage java.util.HashMap à partir de plusieurs threads (sans modification) ?

Question

Il arrive qu'une carte soit construite et qu'une fois initialisée, elle ne soit plus jamais modifiée. Elle sera cependant accessible (via get(key) uniquement) à partir de plusieurs threads. Est-il sûr d'utiliser un java.util.HashMap de cette manière ?

(Actuellement, j'utilise volontiers un java.util.concurrent.ConcurrentHashMap Je n'ai pas de besoin mesuré d'améliorer la performance, mais je suis simplement curieux de savoir si un simple HashMap suffirait. Cette question est donc pas "Il ne s'agit pas non plus d'une question de performance. La question est plutôt : "Est-ce que ce serait sûr ?")

Answer 1

Jeremy Manson, le dieu du modèle de mémoire Java, a publié un blog en trois parties sur ce sujet. En effet, vous posez essentiellement la question suivante : "Est-il possible d'accéder en toute sécurité à une table de hachage immuable ? Mais vous devez répondre au prédicat de cette question qui est : "Mon HashMap est-il immuable ? La réponse pourrait vous surprendre : Java dispose d'un ensemble de règles relativement complexes pour déterminer l'immutabilité.

Pour plus d'informations sur le sujet, lisez les articles de blog de Jeremy :

Première partie sur l'immutabilité en Java : http://jeremymanson.blogspot.com/2008/04/immutability-in-java.html

Partie 2 sur l'immutabilité en Java : http://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-2.html

Partie 3 sur l'immutabilité en Java : http://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-3.html

Answer 2

Les lectures sont sûres du point de vue de la synchronisation, mais pas du point de vue de la mémoire. C'est un point qui est largement mal compris par les développeurs Java, y compris ici sur Stackoverflow. (Observez l'évaluation de cette réponse pour preuve).

Si d'autres threads sont en cours d'exécution, il se peut qu'ils ne voient pas une copie mise à jour de la table de hachage si aucune écriture mémoire n'est effectuée par le thread en cours. Les écritures en mémoire se produisent par l'utilisation des mots-clés synchronized ou volatile, ou par l'utilisation de certaines constructions de concurrence Java.

Voir Article de Brian Goetz sur le nouveau modèle de mémoire Java pour plus de détails.

Answer 3

Après quelques recherches supplémentaires, j'ai trouvé ceci dans la rubrique doc java (souligné par moi) :

Notez que cette mise en œuvre n'est pas synchronisée. I accèdent simultanément à une table de hachage, et qu'au moins au moins un des threads modifie la structure de la structurellement la carte, celle-ci doit être synchronisée de manière externe. ( est toute opération qui ajoute ou supprime ajoute ou supprime un ou plusieurs mappings ; le simple changement de la valeur associée à une à une clé qu'une instance contient déjà n'est pas une modification structurelle).

Cela semble impliquer qu'il sera sûr, en supposant que l'inverse de l'énoncé soit vrai.

Answer 4

Il est à noter que dans certaines circonstances, un get() à partir d'une HashMap non synchronisée peut provoquer une boucle infinie. Cela peut se produire si un put() concurrent provoque un rehash de la Map.

http://lightbody.net/blog/2005/07/hashmapget_can_cause_an_infini.html

Answer 5

Il y a cependant un élément important. Il est sûr d'accéder à la carte, mais en général il n'est pas garanti que tous les threads verront exactement le même état (et donc les mêmes valeurs) de la HashMap. Cela peut se produire sur les systèmes multiprocesseurs où les modifications apportées à la table de hachage par un thread (par exemple, celui qui l'a remplie) peuvent rester dans le cache de ce processeur et ne seront pas vues par les threads s'exécutant sur d'autres processeurs, jusqu'à ce qu'une opération de clôture de la mémoire soit effectuée pour assurer la cohérence du cache. La spécification du langage Java est explicite à ce sujet : la solution consiste à acquérir un verrou (synchronisé (...)) qui déclenche une opération de clôture de la mémoire. Ainsi, si vous êtes sûr qu'après avoir rempli la table de hachage, chacun des threads acquiert TOUT verrou, il est possible d'accéder à la table de hachage à partir de n'importe quel thread jusqu'à ce que la table de hachage soit à nouveau modifiée.