Est-il sûr d'obtenir les valeurs de java.util.Table de hachage à partir de plusieurs threads (pas de modification)?

Votre idiome est sûr si et seulement si la référence à la HashMap est en toute sécurité publié. Plutôt que quoi que ce soit concernant le fonctionnement interne de HashMap lui-même, sûr publication traite de la façon dont la construction de thread rend la référence à la carte visible pour les autres threads.

En gros, la seule possible, la course est ici entre la construction de la HashMap et toute la lecture de threads qui peuvent y accéder avant il est entièrement construit. La plupart de la discussion à propos de ce qui se passe à l'état de l'objet map, mais cela est sans importance puisque vous ne modifiez jamais - donc la seule partie intéressante est de savoir comment le HashMap de référence est publié.

Par exemple, imaginez que vous publier la carte comme ceci:

class SomeClass {
   public static HashMap<Object, Object> MAP;

   public synchronized static setMap(HashMap<Object, Object> m) {
     MAP = m;
   }
}

... et à un certain point setMap() est appelée avec une carte, et d'autres threads à l'aide de SomeClass.MAP pour accéder à la carte, et de vérifier la valeur null comme ceci:

HashMap<Object,Object> map = SomeClass.MAP;
if (map != null) {
  .. use the map
} else {
  .. some default behavior
}

C'est pas sûr même si elle apparaît probablement comme si il est. Le problème est qu'il n'y a pas de -passe-avant relation entre l'ensemble des SomeObject.MAP et la lecture ultérieure sur un autre thread, le thread de lecture est libre de voir une partie de construit la carte. Cela peut très bien faire rien et même dans la pratique, il fait des choses comme mettre le thread de lecture dans une boucle infinie.

En toute sécurité de publier la carte, vous devez établir un se passe-avant relation entre la l'écriture de la référence à la HashMap (c'est à dire, la publication) les lecteurs de référence (c'est à dire, de la consommation). Idéalement, il y a seulement quelques, faciles à mémoriser, des moyens de accomplir que^[1]:

1. De change de référence par l'intermédiaire d'un bien verrouillée champ (JLS 17.4.5)
2. Utilisation de l'initialiseur statique pour faire l'initialisation de magasins (JLS 12.4)
3. De change de référence par l'intermédiaire d'un champ volatile (JLS 17.4.5), ou comme la conséquence de cette règle, via le AtomicX classes
4. Initialisation de la valeur dans un champ final (JLS 17.5).

Les plus intéressantes pour votre scénario (2), (3) et (4). En particulier, (3) s'applique directement sur le code que j'ai ci-dessus: si vous transformez la déclaration de MAP à:

public static volatile HashMap<Object, Object> MAP;

puis tout est casher: les lecteurs qui voient un non-null valeur nécessairement un se passe-avant relation avec le magasin de MAP et donc de voir tous les magasins associés à la génération de la carte.

L'autre modification des méthodes de la sémantique de votre méthode, puisque les deux (2) (à l'aide de la statique initalizer) et (4) (à l'aide de final) implique que vous ne pouvez pas définir MAP dynamiquement à l'exécution. Si vous n'avez pas besoin pour le faire, alors il suffit de déclarer MAP comme un static final HashMap<> et vous êtes garanti de publication.

Dans la pratique, les règles sont simples pour un accès sécurisé à de "ne jamais modifié objets":

Si vous êtes à la publication d'un objet qui n'est pas intrinsèquement immuable (comme dans tous les domaines, a déclaré final) et:

• Vous pouvez déjà créer l'objet qui sera attribué au moment de la déclaration^a: il suffit d'utiliser un final champ (y compris static final pour les membres statiques).
• Vous souhaitez affecter à l'objet plus tard, après la référence est déjà visible: l'utilisation d'un champ volatile^b.

Que c'est!

Dans la pratique, il est très efficace. L'utilisation d'un static final champ, par exemple, permet à la JVM d'assumer la valeur est inchangée pour la vie du programme et de l'optimiser fortement. L'utilisation d'un final champ de membre permet plus architectures à lire le champ d'une manière équivalente à un champ normal de lire et de ne pas inhiber d'autres optimisations^c.

Enfin, l'utilisation de volatile ne avoir un certain impact: pas de matériel de barrière est nécessaire sur de nombreuses architectures (tels que les x86, en particulier celles qui ne permettent pas de lit pour passer lit), mais certains d'optimisation et de réorganisation ne peut pas se produire au moment de la compilation - mais cet effet est généralement de petite taille. En échange, vous obtenez en fait plus que ce que vous avez demandé - non seulement vous pouvez en toute sécurité de publier un HashMap, vous pouvez stocker autant de plus pour ne pas modifiés HashMaps que vous le souhaitez à la même référence, et soyez assuré que tous les lecteurs verront une façon sécuritaire carte publiée.

Pour plus de détails sanglants, reportez-vous à Shipilev ou cette FAQ par Manson et Goetz.

---

[1] Directement citant shipilev.

---

^a Qui a l'air compliqué, mais ce que je veux dire, c'est que vous pouvez attribuer la référence au moment de la construction, soit au point de déclaration ou dans le constructeur (membre de champs) ou d'initialiseur statique (champs statiques).

^b en option, vous pouvez utiliser un synchronized méthode get/set, ou un AtomicReference ou quelque chose, mais nous parlons de la durée de travail minimale que vous pouvez faire.

c sur Certaines architectures, avec de très faibles modèles de mémoire (je suis à la recherche d' vous, Alpha) peut exiger un certain type de lecture de la barrière avant un final lire - mais ils sont très rares aujourd'hui.

Les lectures sont à l'abri d'une synchronisation point de vue, mais pas d'un point de vue de la mémoire. C'est quelque chose qui est très mal compris parmi les développeurs Java, y compris ici sur Stackoverflow. (Observer la notation de cette réponse de la preuve.)

Si vous avez d'autres threads en cours d'exécution, ils ne peuvent pas voir une copie mise à jour de la table de hachage si il n'y a pas de mémoire d'écrire du thread courant. Mémoire écrit se produire à travers l'utilisation de la synchronisation ou de la volatilité des mots-clés, ou par l'intermédiaire d'utilisations de certaines java simultanéité des constructions.

Voir Brian Goetz de l'article sur le nouveau Modèle Mémoire Java pour plus de détails.

L'on remarque est que, dans certaines circonstances, un get() à partir d'une désynchronisation du HashMap peut provoquer une boucle infinie. Cela peut se produire si un concurrent à mettre() provoque une resucée de la Carte.

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

Selon http://www.ibm.com/developerworks/java/library/j-jtp03304/ # Initialisation de la sécurité, vous pouvez faire votre HashMap un champ final et après le constructeur finitions, il serait en toute sécurité publié.

...
En vertu du nouveau modèle de mémoire, il y a quelque chose de semblable à un passe-avant la relation entre l'écriture d'un champ final dans un constructeur et la charge initiale d'une référence partagée à cet objet dans un autre thread.
...

Être averti que, même en single-threaded code, le remplacement d'un ConcurrentHashMap avec une table de hachage peut-être pas sûr. ConcurrentHashMap interdit la valeur null comme une clé ou une valeur. HashMap ne pas les interdire (ne demandez pas).

Donc dans la situation peu probable que votre code existant peut ajouter une valeur null à la collecte lors de l'installation (sans doute dans un cas d'échec d'un certain type), en remplacement de la collection, comme décrit va changer le comportement fonctionnel.

Cela dit, à condition de ne rien faire d'autre simultanées lit à partir d'une table de hachage sont en sécurité.

[Edit: par "concurrent lit", je veux dire qu'il n'y a pas les modifications concurrentes.

D'autres réponses expliquer comment s'en assurer. Une façon est de faire la carte immuable, mais il n'est pas nécessaire. Par exemple, le JSR133 modèle de mémoire définit explicitement le démarrage d'un thread pour être une des actions synchronisées, ce qui signifie que les modifications apportées dans Un thread avant qu'il ne commence thread B sont visibles dans le fil B.

Mon intention n'est pas en contradiction avec celles des réponses plus détaillées à propos de la Java du Modèle de Mémoire. Cette réponse est destinée à souligner que même en dehors de problèmes de concurrence, il y a au moins une API différence entre ConcurrentHashMap et de la table de hachage, ce qui pourrait saborder même un single-threaded programme qui a remplacé l'un avec l'autre.]

Si l'initialisation et le tout est synchronisé vous enregistrer.

Code suivant est sauver parce que le chargeur de classe de prendre soin de la synchronisation:

public static final HashMap<String, String> map = new HashMap<>();
static {
  map.put("A","A");

}

Code suivant est de sauvegarder, car l'écriture de la volatilité va prendre soin de la synchronisation.

class Foo {
  volatile HashMap<String, String> map;
  public void init() {
    final HashMap<String, String> tmp = new HashMap<>();
    tmp.put("A","A");
    //writing to volatile has to be after the modification of the map
    this.map = tmp;
  }
}

Cela fonctionnera également si le membre est une variable final à cause finale est aussi volatile. Et si la méthode est un constructeur.