L'ordre est-il garanti pour le retour des clés et des valeurs d'un objet LinkedHashMap?

Je sais qu'il LinkedHashMapa un ordre d'itération prévisible (ordre d'insertion). Est-ce que le Setretour par LinkedHashMap.keySet()et le Collectionretour parLinkedHashMap.values() maintiennent également cette commande?

L'interface Carte fournit trois vues de collection , qui permettent d'afficher le contenu d'une carte sous la forme d'un ensemble de clés, d'une collection de valeurs ou d'un ensemble de mappages clé-valeur. L' ordre d'une carte est défini comme l'ordre dans lequel les itérateurs sur les vues de collection de la carte renvoient leurs éléments. Certaines implémentations de carte, comme la TreeMap classe, font des garanties spécifiques quant à leur ordre; d'autres, comme la HashMapclasse, ne le font pas.

- Carte

Cette liste chaînée définit l'ordre des itérations, qui est normalement l'ordre dans lequel les clés ont été insérées dans la carte ( ordre d'insertion ).

- LinkedHashMap

Alors, oui, keySet(), values(), et entrySet()(les trois vues de mentioner) les valeurs de retour dans l'ordre des utilisations liste chaînée internes. Et oui, le JavaDoc pour Mapet le LinkedHashMapgarantir.

C'est le but de cette classe, après tout.

En regardant la source, on dirait que c'est le cas. keySet(), values()et entrySet()utilisent tous le même itérateur d'entrée en interne.

Ne vous confondez pas avec LinkedHashMap.keySet()etLinkedHashMap.entrySet() revenir ensemble et donc il ne devrait pas garantir la commande!

Setest une interface avec HashSet, TreeSetetc. étant ses implémentations. L' HashSetimplémentation de l' Setinterface ne garantit pas la commande. Mais le TreeSetfait. AussiLinkedHashSet fait .

Par conséquent, cela dépend de la manière dont Seta été implémentée LinkedHashMappour savoir si la référence Set renvoyée garantira la commande ou non. J'ai parcouru le code source de LinkedHashMap, il ressemble à ceci:

private final class KeySet extends AbstractSet<K> {...}
public abstract class AbstractSet<E> extends AbstractCollection<E> implements Set<E> {...}

Ainsi LinkedHashMap / HashMap a sa propre implémentation de SetieKeySet . Alors ne confondez pas cela avecHashSet .

En outre, l'ordre est maintenu par la manière dont les éléments sont insérés dans le seau. Regardez la addEntry(..)méthode de LinkedHashMapet comparez-la avec celle HashMapdont met en évidence la principale différence entre HashMapet LinkedHashMap.

Vous pouvez le supposer. Le Javadoc dit «ordre d'itération prévisible», et les seuls itérateurs disponibles dans une carte sont ceux pour keySet (), entrySet () et values ​​().

Donc, en l'absence de toute autre qualification, il est clairement destiné à s'appliquer à tous ces itérateurs.

AFAIK il n'est pas documenté donc vous ne pouvez pas "formellement" le supposer. Il est cependant peu probable que la mise en œuvre actuelle change.

Si vous souhaitez assurer l'ordre, vous pouvez parcourir les entrées de la carte et les insérer dans un ensemble trié avec une fonction de commande de votre choix, bien que vous paierez naturellement un coût de performance.

En regardant l'interface, il renvoie un simple Setet non un SortedSet. Il n'y a donc aucune garantie.

Avant d'assumer une garantie implicite en regardant l'implémentation (toujours une mauvaise idée) regardez également les implémentations dans toutes les autres implémentations Java :)

Vous pourriez mieux créer par exemple un TreeSet avec le keySet dans le constructeur.

Je ne pense pas que vous puissiez présumer l'ordre de keySet () et values ​​().

Je peux facilement écrire une implémentation de LinkedHashMap qui vous renvoie keySet () et values ​​() non ordonnés, tant que je m'en tiens au contrat de ces deux méthodes qui sont définies dans Map et remplacées dans HashMap.