LinkedHashSet Classe

Définition

[Android.Runtime.Register("java/util/LinkedHashSet", DoNotGenerateAcw=true)]
[Java.Interop.JavaTypeParameters(new System.String[] { "E" })]
public class LinkedHashSet : Java.Util.HashSet, IDisposable, Java.Util.ISequencedSet

[<Android.Runtime.Register("java/util/LinkedHashSet", DoNotGenerateAcw=true)>]
[<Java.Interop.JavaTypeParameters(new System.String[] { "E" })>]
type LinkedHashSet = class
    inherit HashSet
    interface ISerializable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable
    interface ICloneable
    interface ISequencedSet
    interface ISequencedCollection
    interface ICollection
    interface IIterable
    interface ISet

Héritage

Object

JavaObject

Object

AbstractCollection

AbstractSet

HashSet

LinkedHashSet

Attributs

RegisterAttribute JavaTypeParametersAttribute

Implémente

IJavaObject IJavaPeerable ISerializable ICloneable IIterable ICollection ISequencedCollection ISequencedSet ISet IDisposable

Remarques

Table de hachage et implémentation de liste liée de l’interface Set , avec ordre de rencontre bien défini. Cette implémentation diffère du HashSet 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 (ordre d’itération), qui est l’ordre dans lequel les éléments ont été insérés dans l’ensemble (ordre d’insertion). L’élément le moins récemment inséré (le plus âgé) est d’abord, et le plus jeune élément est le dernier. Notez que l’ordre de rencontre n’est pas affecté si un élément est réinscrit dans l’ensemble avec la add méthode. (Un élément e est réinséré dans un jeu s s’il s.add(e) est appelé quand s.contains(e) retournerait true immédiatement avant l’appel.) La vue inversée de cet ensemble est dans l’ordre opposé, avec l’élément le plus jeune apparaissant en premier et l’élément le plus âgé apparaissant en dernier. L’ordre de rencontre des éléments déjà présents dans l’ensemble peut être modifié à l’aide des méthodes et #addFirst addFirst des #addLast addLast méthodes.

Cette implémentation évite à ses clients de l’ordre non spécifié, généralement chaotique fourni par HashSet, sans entraîner l’augmentation du coût associé à TreeSet. Il peut être utilisé pour produire une copie d’un jeu qui a le même ordre que l’original, quelle que soit l’implémentation du jeu d’origine :

{@code
                void foo(Set<String> s) {
                    Set<String> copy = new LinkedHashSet<>(s);
                    ...
                }
            }

Cette technique est particulièrement utile si un module prend un ensemble 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.)

Cette classe fournit toutes les opérations facultatives Set et SequencedSet autorise les éléments Null. Comme HashSet, 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 HashSet, en raison des frais supplémentaires de maintenance de la liste liée, à une exception près : l’itération sur un LinkedHashSet temps nécessaire proportionnelle à la taille de l’ensemble, quelle que soit sa capacité. L’itération sur une HashSet valeur est susceptible d’être plus coûteuse, nécessitant un temps proportionnel à sa capacité.

Un jeu de hachage lié a deux paramètres qui affectent ses performances : la capacité initiale et le facteur de charge. Ils sont définis exactement comme pour HashSet. 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 HashSetcette 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 à un hachage lié et qu’au moins un des threads modifie l’ensemble, il <>doit</em> être synchronisé en externe. Cela s’effectue généralement en synchronisant sur un objet qui encapsule naturellement l’ensemble.

S’il n’existe aucun objet de ce type, l’ensemble doit être « encapsulé » à l’aide de la Collections#synchronizedSet Collections.synchronizedSet méthode. Cette opération est optimale au moment de la création pour empêcher l’accès non synchronisé accidentel au jeu :

Set s = Collections.synchronizedSet(new LinkedHashSet(...));

Les itérateurs retournés par la méthode de iterator cette classe sont <em>fail-fast</em> : si l’ensemble est modifié à tout moment après la création de l’itérateur, à tout moment, sauf par le biais de la propre remove méthode de 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 l’infrastructure de collections Java.

Ajouté dans la version 1.4.

Java documentation pour java.util.LinkedHashSet.

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