The importance of the hashCode()

Interviewers like to ask questions about the importance of hashCode() function, kind of “what would be if the hashCode() returns the same value for different objects” and vise versa, “what could be if it returns random number every time, can it break anything”?

I think the best way to memorize the answers for such a questions is to understand how it actually works in a real life code. Simple remember the following implementation from java.util.HashMap:

public V get(Object key) {
        if (key == null)
            return getForNullKey();
        int hash = hash(key.hashCode());
        for (Entry<K,V> e = table[indexFor(hash, table.length)];
             e != null;
             e = {
            Object k;
            if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
                return e.value;
        return null;

Even just these two lines:

if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
                return e.value;

As we see, two different keys can have the same hashes. If we make the hashCode() always return the same integer it won’t break anything but it will decrease performance of searching the key. HashSet collection is based on the HashMap and works the same way when we use it’s contains(Object key); method (basically it just delegates the task to the hashMap’s getEntry(Object key); method which is using the above algorithm).

So, the answers are: if we use a custom object as a key, we need to provide our own hashCode() to have a greater performance. If hashCode() returns random integer every time, the hashMap won’t probably ever find the key you’ve put into it.