LinkedHashMap Classe

Définition

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

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

Héritage

Object

JavaObject

Object

AbstractMap

HashMap

LinkedHashMap

Attributs

RegisterAttribute JavaTypeParametersAttribute

Implémente

IJavaObject IJavaPeerable IMap ISequencedMap IDisposable

Remarques

Table de hachage et implémentation de liste liée de l’interface Map , avec ordre de rencontre bien défini. Cette implémentation diffère du HashMap fait qu’elle conserve une liste doublement liée qui s’exécute via toutes ses entrées. Cette liste liée définit l’ordre de rencontre (l’ordre d’itération), qui est normalement l’ordre dans lequel les clés ont été insérées dans la carte (ordre d’insertion). L’entrée la moins récemment insérée (l’aîné) est d’abord, et l’entrée la plus jeune est la dernière. Notez que l’ordre de rencontre n’est pas affecté si une clé est réinsérée dans la carte avec la put méthode. (Une clé k est réinsérée dans une carte m si m.put(k, v) elle est appelée quand m.containsKey(k) retournerait true immédiatement avant l’appel.) La vue inversée de cette carte est dans l’ordre opposé, avec l’entrée la plus jeune apparaissant en premier et l’entrée la plus ancienne apparaissant en dernier. L’ordre de rencontre des entrées déjà dans la carte peut être modifié à l’aide des méthodes et #putFirst putFirst des #putLast putLast méthodes.

Cette implémentation évite à ses clients les commandes non spécifiées, généralement chaotiques fournies par HashMap (et Hashtable), sans entraîner l’augmentation du coût associé à TreeMap. Il peut être utilisé pour produire une copie d’une carte qui a le même ordre que l’original, quelle que soit l’implémentation de la carte d’origine :

{@code
                void foo(Map<String, Integer> m) {
                    Map<String, Integer> copy = new LinkedHashMap<>(m);
                    ...
                }
            }

Cette technique est particulièrement utile si un module prend une carte sur l’entrée, le copie et retourne ultérieurement les résultats dont l’ordre est déterminé par celui de la copie. (Les clients apprécient généralement d’avoir des choses retournées dans le même ordre qu’ils ont été présentés.)

Un spécial #LinkedHashMap(int,float,boolean) constructor est fourni pour créer une carte de hachage liée dont l’ordre de rencontre est l’ordre dans lequel ses entrées ont été consultées pour la dernière fois, du moins récemment accessible à la dernière fois (ordre d’accès). Ce type de carte est bien adapté à la création de caches LRU. L’appel du put, putIfAbsentgetgetOrDefaultcomputecomputeIfAbsentou computeIfPresentmerge des méthodes entraîne un accès à l’entrée correspondante (en supposant qu’elle existe une fois l’appel terminé). Les replace méthodes entraînent uniquement un accès à l’entrée si la valeur est remplacée. La putAll méthode génère un accès d’entrée pour chaque mappage dans la carte spécifiée, dans l’ordre dans lequel les mappages clé-valeur sont fournis par l’itérateur de jeu d’entrées de la carte spécifié. Aucune autre méthode ne génère d’accès aux entrées. L’appel de ces méthodes sur la vue inversée génère des accès aux entrées sur la carte de stockage. Notez que dans l’affichage inversé, un accès à une entrée le déplace en premier dans l’ordre de rencontre. Les méthodes de positionnement explicite telles que putFirst ou lastEntry, sur la carte ou sur sa vue inversée, effectuent l’opération de positionnement et ne génèrent pas d’accès d’entrée. Les opérations sur les keySetvues et valuesentrySetles vues ou sur leurs équivalents séquencés n’affectent pas l’ordre de rencontre de la carte de stockage.

La #removeEldestEntry(Map.Entry) méthode peut être remplacée pour imposer une stratégie pour supprimer automatiquement les mappages obsolètes lorsque de nouveaux mappages sont ajoutés à la carte. Sinon, étant donné que l’entrée « aînée » est la première entrée dans l’ordre de rencontre, les programmes peuvent inspecter et supprimer des mappages obsolètes à l’aide #firstEntry firstEntry des méthodes et #pollFirstEntry pollFirstEntry des méthodes.

Cette classe fournit toutes les opérations facultatives Map et SequencedMap autorise les éléments Null. Comme HashMap, il fournit des performances à temps constant pour les opérations de base (addcontainsetremove), en supposant que la fonction de hachage disperse correctement les éléments entre les compartiments. Les performances sont susceptibles d’être légèrement inférieures à celles de HashMap, en raison des frais supplémentaires de maintenance de la liste liée, à une exception près : itération sur les vues de collection d’un LinkedHashMap temps nécessaire proportionnelle à la taille de la carte, quelle que soit sa capacité. L’itération sur une HashMap valeur est susceptible d’être plus coûteuse, nécessitant un temps proportionnel à sa capacité.

Une carte de hachage liée a deux paramètres qui affectent ses performances : la capacité initiale et le facteur de charge. Ils sont définis exactement comme pour HashMap. Notez toutefois que la pénalité de choix d’une valeur excessivement élevée pour la capacité initiale est moins grave pour cette classe que pour HashMapcette classe, car les temps d’itération pour cette classe ne sont pas affectés par la capacité.

< >notez que cette implémentation n’est pas synchronisée.</strong> Si plusieurs threads accèdent simultanément à une carte de hachage lié et qu’au moins un des threads modifie la carte structurellement, il <doit></em> être synchronisé en externe. 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 LinkedHashMap(...));

Une modification structurelle est toute opération qui ajoute ou supprime un ou plusieurs mappages ou, dans le cas de mappages de hachage liés ordonnés par accès, affecte l’ordre d’itération. Dans les mappages de hachage liés ordonnés par insertion, la modification de la valeur associée à une clé déjà contenue dans la carte n’est pas une modification structurelle. <forte>dans les mappages de hachage liés ordonnés par accès, l’interrogation de la carte est get une modification structurelle. </strong>)

Les itérateurs retournés par la iterator méthode des collections retournées par toutes les méthodes de vue de collection de cette classe sont <em>fail-fast</em> : si la carte est structurellement modifiée à tout moment après la création de l’itérateur, à tout moment, sauf par le biais 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.

Les fractionneurs retournés par la méthode de fractionnement des collections retournées par toutes les méthodes de vue de collection de cette classe sont <em>late-binding</em>, <em>fail-fast</em>, et également rapport.Spliterator#ORDERED <em>Remarque</em> : l’implémentation de ces séparateurs dans Android Combien (niveaux d’API 24 et 25) utilise l’ordre incorrect (incohérent avec les itérateurs, qui utilisent l’ordre correct), malgré la création de rapports Spliterator#ORDERED. Vous pouvez utiliser les fragments de code suivants pour obtenir un fractionneur ordonné correctement au niveau de l’API 24 et 25 : <ul><li>Pour une vue c = lhm.keySet()collection, c = lhm.entrySet() ou c = lhm.values(), utilisez java.util.Spliterators.spliterator(c, c.spliterator().characteristics()) plutôt c.spliterator()que . <li>Au lieu de c.stream() ou c.parallelStream(), utilisez java.util.stream.StreamSupport.stream(spliterator, false) pour construire un (nonparallel) java.util.stream.Stream à partir d’un Spliteratortel . </ul> Notez que ces solutions de contournement sont suggérées uniquement lorsqu’il lhm s’agit d’un LinkedHashMap.

Cette classe est membre de Java Collections Framework.

Ajouté dans la version 1.4.

Documentation Java pour java.util.LinkedHashMap.

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.