HashMap Classe

Définition

[Android.Runtime.Register("java/util/HashMap", DoNotGenerateAcw=true)]
[Java.Interop.JavaTypeParameters(new System.String[] { "K", "V" })]
public class HashMap : Java.Util.AbstractMap, IDisposable, Java.Interop.IJavaPeerable, Java.IO.ISerializable, Java.Lang.ICloneable

[<Android.Runtime.Register("java/util/HashMap", DoNotGenerateAcw=true)>]
[<Java.Interop.JavaTypeParameters(new System.String[] { "K", "V" })>]
type HashMap = class
    inherit AbstractMap
    interface ISerializable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable
    interface ICloneable
    interface IMap

Héritage

Object

Object

AbstractMap

HashMap

Dérivé

Java.Util.LinkedHashMap

Attributs

RegisterAttribute JavaTypeParametersAttribute

Implémente

IJavaObject IJavaPeerable ISerializable ICloneable IMap IDisposable

Remarques

Implémentation basée sur une table de hachage de l’interface Map . Cette implémentation fournit toutes les opérations de mappage facultatives et autorise les null valeurs et la null clé. (La HashMap classe est à peu près équivalente à Hashtable, sauf qu’elle est non synchronisée et autorise les valeurs null.) Cette classe ne garantit pas l’ordre de la carte ; en particulier, elle ne garantit pas que l’ordre restera constant au fil du temps.

Cette implémentation fournit des performances à temps constant pour les opérations de base (get et put), en supposant que la fonction de hachage disperse correctement les éléments entre les compartiments. L’itération sur les vues de collection nécessite un temps proportionnel à la « capacité » de l’instance HashMap (le nombre de compartiments) plus sa taille (le nombre de mappages clé-valeur). Par conséquent, il est très important de ne pas définir la capacité initiale trop élevée (ou le facteur de charge trop faible) si les performances d’itération sont importantes.

Une instance de HashMap possède deux paramètres qui affectent ses performances : la capacité initiale et le facteur de charge. La capacité est le nombre de compartiments dans la table de hachage, et la capacité initiale est simplement la capacité au moment où la table de hachage est créée. Le facteur de charge est une mesure de la quantité totale de la table de hachage autorisée à obtenir avant que sa capacité soit automatiquement augmentée. Lorsque le nombre d’entrées dans la table de hachage dépasse le produit du facteur de charge et la capacité actuelle, la table de hachage est réhésurée (autrement dit, les structures de données internes sont reconstruites) afin que la table de hachage ait environ deux fois le nombre de compartiments.

En règle générale, le facteur de charge par défaut (.75) offre un bon compromis entre le temps et les coûts d’espace. Les valeurs plus élevées diminuent la surcharge d’espace, mais augmentent le coût de recherche (reflétées dans la plupart des opérations de la HashMap classe, y compris get et put). Le nombre attendu d’entrées dans la carte et son facteur de charge doivent être pris en compte lors de la définition de sa capacité initiale, afin de réduire le nombre d’opérations de réachage. Si la capacité initiale est supérieure au nombre maximal d’entrées divisées par le facteur de charge, aucune opération de réachage ne se produit.

Si de nombreux mappages doivent être stockés dans une HashMap instance, la création de celle-ci avec une capacité suffisamment importante permet de stocker les mappages de manière plus efficace que de laisser effectuer un réachage automatique si nécessaire pour augmenter la table. Notez que l’utilisation de nombreuses clés avec la même hashCode() méthode est un moyen sûr de ralentir les performances de n’importe quelle table de hachage. Pour améliorater l’impact, lorsque les clés sont Comparable, cette classe peut utiliser l’ordre de comparaison entre les clés pour aider à rompre les liens.

<>notez que cette implémentation n’est pas synchronisée.</strong> Si plusieurs threads accèdent simultanément à une carte de hachage et qu’au moins un des threads modifie la carte structurellement, il doit être synchronisé en externe. (Une modification structurelle est toute opération qui ajoute ou supprime un ou plusieurs mappages ; il suffit de modifier la valeur associée à une clé qu’une instance contient déjà n’est pas une modification structurelle.) Cette opération est généralement effectuée en synchronisant sur un objet qui encapsule naturellement la carte.

Si aucun objet de ce type n’existe, la carte doit être « encapsulée » à l’aide de la Collections#synchronizedMap Collections.synchronizedMap méthode. Cela est le mieux fait au moment de la création, pour empêcher l’accès non synchronisé accidentel à la carte :

Map m = Collections.synchronizedMap(new HashMap(...));

Les itérateurs retournés par toutes les « méthodes de vue de collection » de cette classe sont rapides : si la carte est modifiée structurellement à tout moment après la création de l’itérateur, à tout moment, à l’exception de la méthode de remove l’itérateur, l’itérateur lève un ConcurrentModificationException. Par conséquent, face à la modification simultanée, l’itérateur échoue rapidement et correctement, plutôt que de risquer un comportement arbitraire et non déterministe à un moment indéterminé à l’avenir.

Notez que le comportement de défaillance rapide d’un itérateur ne peut pas être garanti, en général, impossible d’apporter des garanties difficiles en présence d’une modification simultanée non synchronisée. Les itérateurs à vitesse d’échec lèvent ConcurrentModificationException un meilleur effort. Par conséquent, il serait incorrect d’écrire un programme qui dépendait de cette exception pour son exactitude : le comportement d’itérateur à échec doit être utilisé uniquement pour détecter les bogues.

Cette classe est membre de Java Collections Framework.

Ajouté dans la version 1.2.

Documentation Java pour java.util.HashMap.

Les parties de cette page sont des modifications basées sur le travail créé et partagé par le projet Android Open Source et utilisés en fonction des termes décrits dans la licence d’attribution Creative Commons 2.5.

Constructeurs

Propriétés

Méthodes

Implémentations d’interfaces explicites

Méthodes d’extension

S’applique à