How hashmap works with Integer as keys

Question

Map<Integer,String> m1 = new HashMap<>();

        m1.put(5, "gfd");
        m1.put(1,"sandy");
        m1.put(3, "abc");
        m1.put(2, "def");
        m1.put(1, "ijk");
        m1.put(10, "bcd");
        m1.put(0, "ssdfsd");

When I Print the map, the output is {0=ssdfsd, 1=ijk, 2=def, 3=abc, 5=gfd, 10=bcd}.

But, how the output is in sorted order even though I have used HashMap()??

not everytime , run it thrice or something , btw adding higher no of elements in the map will definitely show — Hussain Akhtar Wahid 'Ghouri', Sep 23 '14 at 08:05
@HussainAkhtarWahid'Ghouri': why would it be non-deterministic? — Oliver Charlesworth, Sep 23 '14 at 08:05

score 0 · Answer 1 · answered Sep 23 '14 at 08:02

A Map provides you with the interface of storing and retrieving objects into a map with a key attached to them.

What each implementation does internally is fully up to it, including in which order the key/value pairs are stored in the internal structure. See @Seshoumaro's answer for the quote from the javadoc.

HashMap hashes the key (which is an Integer in this case) and uses that hash as an array index. Since the hashCode for Integer is fairly simple to write yourself, it's not surprising that the array indices for each one are in the same order as the key itself.

What all that means is: you shouldnt be surprised that the HashMap is acting this way.

score 0 · Answer 2 · edited Sep 23 '14 at 08:15

The HashMap provides no guarantee as to the order of the items stored. It may even be in order in some cases. Taken from the javadoc:

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.

So it's working as intended. If you're curious as to why this particular example is placed in order, you could check out the source code itself.

score 0 · Answer 3 · edited May 23 '17 at 11:49

Its not just restricted to keys of Integers you may obtain the same with Strings at times. It just so happens to be at times and you would find numerous instances of the same.

As suggested by others HashMap never guarantees the insertion order while fetching.Since the official doc says to not rely you might find occasions when it would not retain the order so better code likewise.

See this for more

score 0 · Accepted Answer · answered Sep 23 '14 at 08:18

You can easily see this in the implementation. If you look into the source of HashMap.put(), you can see that the hash table index of the object is determined like this:

int hash = hash(key.hashCode());
int i = indexFor(hash, table.length);

The methods hash() and indexFor() only ensure that there are not too many collisions of hash values and they don't exceed the length of the hash table.

Now if you take a look at Integer.hashCode(), you'll see that the hash is the integer itself:

public int hashCode() {
    return value;
}

So the integer which has the value 0 ends up in index 0 of the hash table and so on. At least as long as the hash table is big enough.

The toString() method of HashMap iterates over the hash table and the elements in each index of the hash table. So in your case the order is preserved.

As others mentioned correctly, this behavior is not ensured by implementations of Map. It just works in this special case.

How hashmap works with Integer as keys

4 Answers4