À l'aide de HashMap en environnement multithread
Je passais une question d'entrevue sur JavaRevisited et je vais avoir de la difficulté à comprendre cette question :
Quel est le problème avec l'aide d'une table de hachage dans un environnement multithread? Lorsque la méthode get() aller dans une boucle infinie?
À mon avis, ce n'est pas un problème pour une utilisation HashMap
à l'intérieur d'un environnement multi-thread, tant que notre demande n'est pas d'accéder à la lecture des fils qui sont la modification de la créé HashMap
, plutôt que de simplement en accédant à la table de hachage.
Donc, comme je le vois, il n'y a pas de problème dans l'application que nous le simple accès à la HashMap
dans un environnement multi-thread.
S'il vous plaît laissez-moi savoir si ma compréhension est correcte.
Oui , merci pour le tuyau , notre APplication n'a pas créer les Threads de manière explicite . nous venons d'accéder aux Données à l'intérieur de la table de hachage .
OriginalL'auteur Pawan | 2012-06-15
Vous devez vous connecter pour publier un commentaire.
Ce qui est faux est d'avoir plusieurs threads utilisent un non-synchronisé collection (vraiment tout mutable classe) sans protection. Certains si chaque thread a son propre
HashMap
instance alors ce n'est pas un problème. Il est un problème si plusieurs threads sont en ajoutant à la mêmeHashMap
instance, sans qu'il soitsynchronized
. Même si seulement 1 thread est en train de modifier unHashMap
et les autres threads sont la lecture à partir de la même carte, sans synchronisation, vous serez confronté à des problèmes.Si vous avez besoin d'utiliser la même table de hachage de l'objet dans plusieurs threads, alors vous devriez envisager d'utiliser
ConcurrentHashMap
, chaque emballage de l'accès à laHashMap
dans unsynchronized {}
bloc, ou en faisant usage de laCollections.synchronizedMap(new HashMap<...>())
construire.La
get()
va à une boucle infinie parce que l'un des fils n'a qu'un partiellement mis à jour vue de laHashMap
en mémoire et il doit y avoir une sorte de pointeur de boucle. C'est le danger de l'utilisation d'une désynchronisation de la collection avec plusieurs threads.Si par "accès" signifie "lecture", puis c'est vrai avec les qualifications. Vous devez vous assurer que:
HashMap
sont terminées avant les threads sont instanciés et le fil qui crée la carte fourches le filsHashMap
en mode lecture seule (get()
ou l'itération sans l'enlever)Si aucune de ces conditions ne sont pas remplies, alors vous aurez besoin d'utiliser un synchronisé carte à la place.
OriginalL'auteur Gray
C'est une question classique. Liste de tableaux et table de hachage ne sont pas synchronisés, alors que Vecteur et de la table de hachage. Vous devez donc utiliser la table de hachage, sauf si vous êtes très prudent de définir les mutex vous-même.
En d'autres termes, les méthodes, par ex. dans la table de hachage de s'assurer qu'aucun autre thread est de travailler avec la table de hachage à un moment donné. Si vous utilisez une table de hachage, vous auriez à le faire manuellement, en veillant à ce que vous synchroniser sur HashMap avant d'appeler la méthode.
Mise à jour: checkout @Gray commentaire. Il ressemble emballage HashMap avec les Collections.synchronizedMap(new HashMap()) est la voie à suivre maintenant.
EDIT: d'autres affiches ont répondu de la façon la mieux que j'ai fait. Ma réponse, cependant, a généré une discussion intéressante sur l'utilisation de la qui sera bientôt obsolète Vecteur, Pile à la table de hachage et de Dictionnaire des classes, donc je pars de la question ici, comme un chef pour les commentaires ci-dessous. Merci les gars!
HashTable
est obsolète et ne doit pas être utilisé. Si vous avez besoin d'un simultanées HashMap, alors vous devriez utiliser ConcurrentHashMap ouCollections.synchronizedMap(new HashMap())
.Oh, c'est intéressant, je n'avais aucune idée. Avez-vous une référence à qui? Avec la table de hachage ne pas être marqué comme obsolète, c'est venu comme une surprise. Merci!
Et puisque nous sommes à elle, est un vecteur aussi obsolète?
Ou utiliser ConcurrentHashMap qui peut être en toute sécurité itéré sans CME.
Ils sont "obsolètes" depuis l'introduction de la
Concurrent
paquet, qui introduit thread-safe collections avec une granularité plus fine queVector
ouHashTable
(réalisation de fil de sécurité à travers une sorte debig-lock
sur l'ensemble de la structure de données).OriginalL'auteur Miquel
Je suppose qu'ils signifiaient pour l'accès à une copie partagée de
HashMap
.Shared mutable state
.Puisqu'il n'est pas
synchronized
chaque thread va saisir sa copie à partir de la mémoire principale, de modifier et de le remplacer.OriginalL'auteur ssedano