90

I understand that the Set returned from a Map's keySet() method does not guarantee any particular order.

My question is, does it guarantee the same order over multiple iterations. For example

Map<K,V> map = getMap();

for( K k : map.keySet() )
{
}

...

for( K k : map.keySet() )
{
}

In the above code, assuming that the map is not modified, will the iteration over the keySets be in the same order. Using Sun's jdk15 it does iterate in the same order, but before I depend on this behavior, I'd like to know if all JDKs will do the same.

EDIT

I see from the answers that I cannot depend on it. Too bad. I was hoping to get away with not having to build some new Collection to guarantee my ordering. My code needed to iterate through, do some logic, and then iterate through again with the same ordering. I'll just create a new ArrayList from the keySet which will guarantee order.

karoberts
  • 9,828
  • 4
  • 39
  • 39
  • 2
    Do you control which Map implementation is returned from getMap() method? – Andrey Adamovich Dec 10 '09 at 17:54
  • 2
    You certainly _can_ get consistent ordering without creating your own collection. See SortedMap as others have mentioned. So if your getMap() method returns SortedMap instead, callers will know to expect consistent ordering. – PSpeed Dec 11 '09 at 00:49
  • My [answer](https://stackoverflow.com/a/63514584/8430155) proves that the order of `.keySet()` and `.values()` is consistent. Unfortunately the accepted answer is wrong. @karoberts - can you please take a look? – Harshal Parekh Aug 21 '20 at 00:01

12 Answers12

66

You can use a LinkedHashMap if you want a HashMap whose iteration order does not change.

Moreover you should always use it if you iterate through the collection. Iterating over HashMap's entrySet or keySet is much slower than over LinkedHashMap's.

ciamej
  • 6,918
  • 2
  • 29
  • 39
58

If it is not stated to be guaranteed in the API documentation, then you shouldn't depend on it. The behavior might even change from one release of the JDK to the next, even from the same vendor's JDK.

You could easily get the set and then just sort it yourself, right?

Ken Liu
  • 22,503
  • 19
  • 75
  • 98
  • 3
    As someone else mentioned, if you can control which Map instance is returned from getMap(), then you can return a SortedMap. In that case you would probably want to explicitly return a SortedMap from getMap() instead of just a Map. – Ken Liu Dec 10 '09 at 18:08
  • 4
    The HashMap and HashSet iteration order changed between Java 7 and Java 8. – user100464 Dec 22 '16 at 16:20
  • @KenLiu Hi I'm very new to Java, can you give me an example about how to get a SortedMap? Many thanks. – Cecilia Oct 27 '19 at 15:34
  • Can you prove that it is inconsistent? Just because the javadoc doesn't mention the word "guaranteed" does not mean it is inconsistent. – Harshal Parekh Aug 21 '20 at 00:02
  • This answer is incorrect. They are consistent. I have proved it [here](https://stackoverflow.com/a/63514584/8430155). – Harshal Parekh Aug 21 '20 at 02:27
  • @HarshalParekh This answer is correct in regards to the docs (although I disagree that sorting the keys is necessarily a good idea--better to use a `LinkedHashMap`). The [docs say](https://docs.oracle.com/javase/8/docs/api/java/util/HashMap.html) (at the time of writing) "This class makes no guarantees as to the order of the map; in particular, it does not guarantee that the order will remain constant over time." – ggorlen Sep 27 '22 at 00:35
9

Map is only an interface (rather than a class), which means that the underlying class that implements it (and there are many) could behave differently, and the contract for keySet() in the API does not indicate that consistent iteration is required.

If you are looking at a specific class that implements Map (HashMap, LinkedHashMap, TreeMap, etc) then you could see how it implements the keySet() function to determine what the behaviour would be by checking out the source, you'd have to really take a close look at the algorithm to see if the property you are looking for is preserved (that is, consistent iteration order when the map has not had any insertions/removals between iterations). The source for HashMap, for example, is here (open JDK 6): http://www.docjar.com/html/api/java/util/HashMap.java.html

It could vary widely from one JDK to the next, so i definitely wouldn't rely on it.

That being said, if consistent iteration order is something you really need, you might want to try a LinkedHashMap.

mpobrien
  • 4,922
  • 1
  • 33
  • 35
  • The Set class in and of itself guarantees no order for it's elements, only that it's unique. So when you ask for .keySet(), it returns an instance of Set which has no guaranteed order. If you want order, you have to do it on your own, and sort them (either with Collections.sort or a SortedSet implementation) – Matt Mar 16 '12 at 14:06
7

The API for Map does not guarantee any ordering whatsoever, even between multiple invocations of the method on the same object.

In practice I would be very surprised if the iteration order changed for multiple subsequent invocations (assuming the map itself did not change in between) - but you should not (and according to the API cannot) rely on this.

EDIT - if you want to rely on the iteration order being consistent, then you want a SortedMap which provides exactly these guarantees.

Andrzej Doyle
  • 102,507
  • 33
  • 189
  • 228
  • Beat me by five seconds so I will only add that even if you could rely on it, it's questionable whether you should. I have to wonder why one would need to depend on this as it seems very fragile. – PSpeed Dec 10 '09 at 17:55
5

Just for fun, I decided to write some code that you can use to guarantee a random order each time. This is useful so that you can catch cases where you are depending on the order but you should not be. If you want to depend on the order, than as others have said, you should use a SortedMap. If you just use a Map and happen to rely on the order then using the following RandomIterator will catch that. I'd only use it in testing code since it makes use of more memory then not doing it would.

You could also wrap the Map (or the Set) to have them return the RandomeIterator which would then let you use the for-each loop.

import java.util.ArrayList;
import java.util.Collections;
import java.util.HashMap;
import java.util.Iterator;
import java.util.List;
import java.util.Map;

public class Main
{
    private Main()
    {
    }

    public static void main(final String[] args)
    {
        final Map<String, String> items;

        items = new HashMap<String, String>();
        items.put("A", "1");
        items.put("B", "2");
        items.put("C", "3");
        items.put("D", "4");
        items.put("E", "5");
        items.put("F", "6");
        items.put("G", "7");

        display(items.keySet().iterator());
        System.out.println("---");

        display(items.keySet().iterator());
        System.out.println("---");

        display(new RandomIterator<String>(items.keySet().iterator()));
        System.out.println("---");

        display(new RandomIterator<String>(items.keySet().iterator()));
        System.out.println("---");
    }

    private static <T> void display(final Iterator<T> iterator)
    {
        while(iterator.hasNext())
        {
            final T item;

            item = iterator.next();
            System.out.println(item);
        }
    }
}

class RandomIterator<T>
    implements Iterator<T>
{
    private final Iterator<T> iterator;

    public RandomIterator(final Iterator<T> i)
    {
        final List<T> items;

        items = new ArrayList<T>();

        while(i.hasNext())
        {
            final T item;

            item = i.next();
            items.add(item);
        }

        Collections.shuffle(items);
        iterator = items.iterator();
    }

    public boolean hasNext()
    {
        return (iterator.hasNext());
    }

    public T next()
    {
        return (iterator.next());
    }

    public void remove()
    {
        iterator.remove();
    }
}
TofuBeer
  • 60,850
  • 18
  • 118
  • 163
4

I agree with LinkedHashMap thing. Just putting my findings and experience while I was facing the problem when I was trying to sort HashMap by keys.

My code to create HashMap:

HashMap<Integer, String> map;

@Before
public void initData() {
    map = new HashMap<>();

    map.put(55, "John");
    map.put(22, "Apple");
    map.put(66, "Earl");
    map.put(77, "Pearl");
    map.put(12, "George");
    map.put(6, "Rocky");

}

I have a function showMap which prints entries of map:

public void showMap (Map<Integer, String> map1) {
    for (Map.Entry<Integer,  String> entry: map1.entrySet()) {
        System.out.println("[Key: "+entry.getKey()+ " , "+"Value: "+entry.getValue() +"] ");

    }

}

Now when I print the map before sorting, it prints following sequence:

Map before sorting : 
[Key: 66 , Value: Earl] 
[Key: 22 , Value: Apple] 
[Key: 6 , Value: Rocky] 
[Key: 55 , Value: John] 
[Key: 12 , Value: George] 
[Key: 77 , Value: Pearl] 

Which is basically different than the order in which map keys were put.

Now When I sort it with map keys:

    List<Map.Entry<Integer, String>> entries = new ArrayList<>(map.entrySet());

    Collections.sort(entries, new Comparator<Entry<Integer, String>>() {

        @Override
        public int compare(Entry<Integer, String> o1, Entry<Integer, String> o2) {

            return o1.getKey().compareTo(o2.getKey());
        }
    });

    HashMap<Integer, String> sortedMap = new LinkedHashMap<>();

    for (Map.Entry<Integer, String> entry : entries) {
        System.out.println("Putting key:"+entry.getKey());
        sortedMap.put(entry.getKey(), entry.getValue());
    }

    System.out.println("Map after sorting:");

    showMap(sortedMap);

the out put is:

Sorting by keys : 
Putting key:6
Putting key:12
Putting key:22
Putting key:55
Putting key:66
Putting key:77
Map after sorting:
[Key: 66 , Value: Earl] 
[Key: 6 , Value: Rocky] 
[Key: 22 , Value: Apple] 
[Key: 55 , Value: John] 
[Key: 12 , Value: George] 
[Key: 77 , Value: Pearl] 

You can see the difference in order of keys. Sorted order of keys is fine but that of keys of copied map is again in the same order of the earlier map. I dont know if this is valid to say, but for two hashmap with same keys, order of keys is same. This implies to the statement that order of keys is not guaranteed but can be same for two maps with same keys because of inherent nature of key insertion algorithm if HashMap implementation of this JVM version.

Now when I use LinkedHashMap to copy sorted Entries to HashMap, I get desired result (which was natural, but that is not the point. Point is regarding order of keys of HashMap)

    HashMap<Integer, String> sortedMap = new LinkedHashMap<>();

    for (Map.Entry<Integer, String> entry : entries) {
        System.out.println("Putting key:"+entry.getKey());
        sortedMap.put(entry.getKey(), entry.getValue());
    }

    System.out.println("Map after sorting:");

    showMap(sortedMap);

Output:

Sorting by keys : 
Putting key:6
Putting key:12
Putting key:22
Putting key:55
Putting key:66
Putting key:77
Map after sorting:
[Key: 6 , Value: Rocky] 
[Key: 12 , Value: George] 
[Key: 22 , Value: Apple] 
[Key: 55 , Value: John] 
[Key: 66 , Value: Earl] 
[Key: 77 , Value: Pearl] 
Parth Joshi
  • 452
  • 4
  • 6
3

Hashmap does not guarantee that the order of the map will remain constant over time.

Amir Afghani
  • 37,814
  • 16
  • 84
  • 124
2

It doesn't have to be. A map's keySet function returns a Set and the set's iterator method says this in its documentation:

"Returns an iterator over the elements in this set. The elements are returned in no particular order (unless this set is an instance of some class that provides a guarantee)."

So, unless you are using one of those classes with a guarantee, there is none.

Jeff Storey
  • 56,312
  • 72
  • 233
  • 406
2

Map is an interface and it does not define in the documentation that order should be the same. That means that you can't rely on the order. But if you control Map implementation returned by the getMap(), then you can use LinkedHashMap or TreeMap and get the same order of keys/values all the time you iterate through them.

Andrey Adamovich
  • 20,285
  • 14
  • 94
  • 132
2

tl;dr Yes.


I believe the iteration order for .keySet() and .values() is consistent (Java 8).

Proof 1: We load a HashMap with random keys and random values. We iterate on this HashMap using .keySet() and load the keys and it's corresponding values to a LinkedHashMap (it will preserve the order of the keys and values inserted). Then we compare the .keySet() of both the Maps and .values() of both the Maps. It always comes out to be the same, never fails.

public class Sample3 {

    static final String AB = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
    static SecureRandom rnd = new SecureRandom();

    // from here: https://stackoverflow.com/a/157202/8430155
    static String randomString(int len){
        StringBuilder sb = new StringBuilder(len);
        for (int i = 0; i < len; i++) {
            sb.append(AB.charAt(rnd.nextInt(AB.length())));
        }
        return sb.toString();
    }

    public static void main(String[] args) throws Exception {
        for (int j = 0; j < 10; j++) {
            Map<String, String> map = new HashMap<>();
            Map<String, String> linkedMap = new LinkedHashMap<>();

            for (int i = 0; i < 1000; i++) {
                String key = randomString(8);
                String value = randomString(8);
                map.put(key, value);
            }

            for (String k : map.keySet()) {
                linkedMap.put(k, map.get(k));
            }

            if (!(map.keySet().toString().equals(linkedMap.keySet().toString()) &&
                  map.values().toString().equals(linkedMap.values().toString()))) {
                // never fails
                System.out.println("Failed");
                break;
            }
        }
    }
}

Proof 2: From here, the table is an array of Node<K,V> class. We know that iterating an array will give the same result every time.

/**
 * The table, initialized on first use, and resized as
 * necessary. When allocated, length is always a power of two.
 * (We also tolerate length zero in some operations to allow
 * bootstrapping mechanics that are currently not needed.)
 */
transient Node<K,V>[] table;

The class responsible for .values():

final class Values extends AbstractCollection<V> {
    
    // more code here

    public final void forEach(Consumer<? super V> action) {
        Node<K,V>[] tab;
        if (action == null)
            throw new NullPointerException();
        if (size > 0 && (tab = table) != null) {
            int mc = modCount;
            for (int i = 0; i < tab.length; ++i) {
                for (Node<K,V> e = tab[i]; e != null; e = e.next)
                    action.accept(e.value);
            }
            if (modCount != mc)
                throw new ConcurrentModificationException();
        }
    }
}

The class responsible for .keySet():

final class KeySet extends AbstractSet<K> {

    // more code here

    public final void forEach(Consumer<? super K> action) {
        Node<K,V>[] tab;
        if (action == null)
            throw new NullPointerException();
        if (size > 0 && (tab = table) != null) {
            int mc = modCount;
            for (int i = 0; i < tab.length; ++i) {
                for (Node<K,V> e = tab[i]; e != null; e = e.next)
                    action.accept(e.key);
            }
            if (modCount != mc)
                throw new ConcurrentModificationException();
        }
    }
}

Carefully look at both the inner classes. They are pretty much the same except:

if (size > 0 && (tab = table) != null) {
    int mc = modCount;
    for (int i = 0; i < tab.length; ++i) {
        for (Node<K,V> e = tab[i]; e != null; e = e.next)
            action.accept(e.key);               <- from KeySet class
            // action.accept(e.value);          <- the only change from Values class
    }
    if (modCount != mc)
        throw new ConcurrentModificationException();
}

They iterate on the same array table to support .keySet() in KeySet class and .values() in Values class.


Proof 3: this answer also explicitly states - So, yes, keySet(), values(), and entrySet() return values in the order the internal linked list uses.

Therefore, the .keySet() and .values() are consistent.

Harshal Parekh
  • 5,918
  • 4
  • 21
  • 43
  • 1
    The specification [explicitly states](https://docs.oracle.com/javase/8/docs/api/java/util/HashMap.html) that there is no guarantee of ordering. Relying on implementation details puts you at risk of things breaking for no apparent reason when dealing with unexpected input, deploying or upgrading versions. In this case, the API provides a data structure that [_is_ explicitly sorted](https://docs.oracle.com/javase/8/docs/api/java/util/LinkedHashMap.html) so there's no reason for this, even if it wasn't super dangerous. – ggorlen Sep 27 '22 at 00:45
1

Logically, if the contract says "no particular order is guaranteed", and since "the order it came out one time" is a particular order, then the answer is no, you can't depend on it coming out the same way twice.

Jonathan Feinberg
  • 44,698
  • 7
  • 80
  • 103
0

You also can store the Set instance returned by the keySet() method and can use this instance whenever you need the same order.

Shivang Agarwal
  • 1,825
  • 1
  • 14
  • 19
  • 2
    Is _that_ guaranteed, though? Or could each call to `iterator()` return an iterator with a different iteration order, even on the same set? – Matthew Leidholm Apr 04 '17 at 22:03