Under what Conditions two different objects may have same hashcode() value..?

Question

What I know is:-

" int hashCode() returns the memory address of the object as the default hash value of the object."

If the references x and y denote two different objects, the expression (x.hashCode() == y.hashCode()) is not always false

So, I want to ask in which cases the hash values of 2 different objects are same.

Answer 1

You can override hashCode in your classes. You would usually override it along with overriding equals , so that if a.equals(b) is true, a.hashCode() == b.hashCode() is also true (even if (a == b) is false).

However, even if a.equals(b) is false, a.hashCode() == b.hashCode() may still be true.

As you can see in the Javadoc of Object class :

• If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.
• It is not required that if two objects are unequal according to the java.lang.Object.equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results . However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables.

Answer 2

HashCode doesn't always return the memory address (which itself may be bogus since objects may be relocated in memory). A class that provides its own hashCode might have an algorithm that causes collisions (two different objects with the same hashCode).

Additionally, you can get equals involved: Two objects, where a!=b but a.equals(b) is true, must have the same hashCode or certain data structures like hashmaps, hashsets, LRU caches, etc, will not work properly. However, if two objects that are not equal have the same hashCode, this poses no problem-- hashCode is used in many cases as a hint for performance improvement (eg in hashMap). While poor hashCode implementations such as return 1; will not cause failure of a properly-written data structure, they will cause performance to drop (eg in the case of a HashMap, amortized O(1) becomes O(N)).

Thirdly, even the best hashCode will necessarily have collisions if there are more than 4,294,967,296 different objects of that class. This is because there are only 4,294,967,296 distict hashCode values possible because hashCode is an int, and by pigeonhole princple.

Contract for Object#hashCode() and all overriding implementations:

If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.

It is not required that if two objects are unequal according to the java.lang.Object.equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables.

Answer 3

The "return memory address" implementation of hashCode is the default . Almost always, when you're using a type of object in a HashMap or HashSet or what-have-you, you'll override hashCode with your own implementation, which could have nothing at all to do with the memory address of the object.