Je veux des éclaircissements sur les différences entre Hashtable et Hashmap à Java 8.
Hashtable à mes connaissances fonctionne de la même manière à un hashmap mais est threadsafe et n'autorise pas les clés ou les valeurs nulles. Je suis conscient que Java 8 met à jour la classe HASHMAP afin que lorsqu'il y a une collision, plutôt que de créer une liste liée d'éléments avec le même code de hachage dans le seau, il crée un arbre.
Est-ce aussi le cas avec hashtable? Et l'arbre est-il la méthode de stockage par défaut même avant une collision? (Comme dans, lorsque le premier élément adapté à un seau est placé là-bas, c'est juste une racine d'arbre sans succursales.)
Aussi, comment Java s'assure-t-il qu'une haquetable est threadsafe? Crée-t-il un Quant lorsque deux threads essaient d'accéder simultanément à un morceau de données?
3 Réponses :
de haruptable Java Docs :
Dans le cas d'une "collision de hachage", un seul godet stocke plusieurs Entrées, qui doivent être recherchées de manière séquentielle
La réponse de la première question est "non". Il ne crée pas d'arbre.
sur le mécanisme threadsafe, HASHTABLE utilise une synchronisation simple sur chaque méthode de lecture \ écriture. Si vous êtes préoccupé par la sécurité des performances et des threads, vous feriez mieux de regarder Concourshashmap .
Cette réponse sera très spécifique à la mise en œuvre actuelle trouvée dans le JDK, donc gardez cela à l'esprit.
Je suis conscient que Java 8 met à jour la classe HASHMAP afin que lorsqu'il y a une collision, plutôt que de créer une liste liée d'éléments avec le même code de hachage dans le godet, il crée un arbre.
Est-ce aussi le cas avec hashtable?
non. La hache ne sera jamais une table de listes liées. Java Devs n'a pas mis à jour la haquetable pour ce cas d'utilisation. Cela devrait également préciser que vous ne devriez probablement pas utiliser Hashtable de toute façon.
et est l'arborescence la méthode de stockage par défaut même avant une collision?
Encore une fois, c'est à Java 8, à compter d'aujourd'hui, mais non, ce n'est pas le comportement par défaut. Une fois que la saisie du godet frappe 8 éléments liés Le hashmap tourne la liste liée à un arbre binaire.
Aussi, comment Java s'assure-t-il qu'une haquetable est threadsafe? Crée-t-il un que deux threads essaient d'accéder simultanément à un morceau de données?
En faisant chaque méthode synchronisée, ce qui signifie que chaque thread va faire la queue sur la méthode pendant laquelle un autre thread accède actuellement à n'importe quelle méthode de la haquetable. Cela provoque assez de problèmes si vous voulez faire des choses comme des puts atomiques ou des calculs atomiques.
Si vous vouliez une carte de fil de sécurité, utilisez toujours Concourshashmap, jamais Hashable.
Point de contenu mineur: à la plupart des gens, "file d'attente" signifie rester en ligne et être servi de premier arrivé - premier servi, mais c'est Pas le cas pour synchronisé , donc utiliser le mot" file d'attente "est trompeur.
C'est un point raisonnable, mais j'utilise la file d'attente de la même manière que le abstractQuouseSynchronizer fait, qui prend en charge les acquisitions de verrouillage équitables et injustes.
Si ce n'est pas le premier arrivé d'abord, comment les moniteurs déterminent-ils les threads obtenus à la priorité?
Ils ne le font pas. Cela fait partie du problème avec des acquisitions de verrouillage injustes, forcées sur vous par le mot-clé synchronisé. Si vous souhaitez que l'acquisition équitable est appliquée, vous voudriez utiliser nouveau reentrantlock (true) où true définit le verrou pour être "Fair".
La mise en garde Bien que cette acquisition de verrouillage injuste fonctionne généralement mieux que la foire. Donc, il devrait y avoir une raison technique pour laquelle vous avez besoin de serrures équitables.
Alors le moniteur choisit-il de manière arbitraire que le thread a accès aux données suivantes?
Vous pouvez aussi bien supposer que cela fait.
@Johnvint ... et il y a 64 entrées
Est-ce aussi le cas avec Hashtable?
NO.
et est l'arborescence la méthode de stockage par défaut même avant une collision? (Comme dans, lorsque le premier élément adapté à un seau est placé là-bas, c'est juste une racine d'arbre sans succursales.)
non. La classe
hashmap a une constante nomméeTRELIFY_THRESHOLD(valeur 8).Javadoc dit "Le seuil de comptage de la poubelle pour l'utilisation d'un arbre plutôt que de la liste pour une corbeille. Les bacs sont convertis en arbres lors de l'ajout d'un élément à une poubelle avec au moins ces nombreux nœuds" .
Aussi, comment Java s'assure-t-il qu'une haquetable est threadsafe?
Le Javadoc de
Hashtableexplicite dit: "Contrairement aux nouvelles implémentations de la collection, HASHTABLE estsynchronisée " . Crée-t-il un Quant lorsque deux threads essaient d'accéder simultanément à un morceau de données?
NO.
Sur le thread-Safety, du Javadoc pour HASHTABLE: "Contrairement aux nouvelles implémentations de la collection, {@code hashtable} est synchronisé.".
Ne ressemble pas à cela: hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes / ...