I know the contract says "if two objects are equal then they should return the same hash code". That is so that those objects can be place in the same hash bucket and to improve hash code related collection functions know. Then again why it says "if two objects have same hash code those should not always be equals". I mean if it is true in the contract we should say "if two objects are equals they may return same hash code but which is not mandatory"
I mean if it is true in the contract we should say "if two objects are equals they may return same hash code but which is not mandatory"
No, it should not. This is because, whenever an object is searched let's say in a HashMap or a HashSet, then first it is searched on the basis of hashCode(NOTE : - hashCode() is not used for search in case of ArrayList, or LinkedList. They are not hash based collections), and then if the two objects have same hashcodes, it moves to the equals method to compare the objects themselves.
Now suppose if the above statement was true, the first test itself would fail for those objects. That is, if two equal objects are allowed to have different hashcode, then while searching for a particular hashCode, it won't return the correct result, and thus the test will not proceed to equals method, and declare those objects to be unequal even though you expected them to be equal.
Now lets move to the second statement: -
if two objects have same hash code those should not always be equals"
Let's understand like this: - Since hashCode generated for each object is of type int, so you can generate a maximum 2 ^ 32 unique hashcodes. So, imagine what would happen if you want to store more objects than that. In that case, there has to be a collison for two different objects. So, you would have no other way than to assign same hashCodes to two different objects. And hence the above statement is justified.
So, two things are quite clear from the above explanation: -
- Two same objects must have same hashCodes.
- Two different objects can have same hashCodes.
More details on this topic in the below link (Nothing can give better explanation than this): -
Nope. The docs are right, and you're getting mixed up.
- Two objects that are equal must have the same hash code.
- Two objects that have the same hash code might be unequal.
- For the sake of hash table performance, you usually want two objects that are not equal to have different hash codes as often as possible.
For example, the following is always a valid implementation of hashCode():
public int hashCode() {
return 0;
// clearly all equal objects have the same hash code -- 0
// but it's totally okay that unequal objects also have the same hash code
}
A HashMap can store multiple entries per bucket, and which bucket is chosen depends on the hashcode. The HashMap finds entries for a key by using the hashcode() to identify the bucket, and then equals() to find the matching key within that bucket.
Given the above, it should be clear that you can have duplicated hashcodes with little issue (it affects the performance of HashMaps if multiple objects have the same hashcode but everything will still work)
If 2 identical hash codes had to come from the same object, than the hash wouldn't be as secure. it would be technically possible to figure what a password was based on the hash. this would undermine the purpose of hash codes(at least in the security sense.)
for non security hashing, if you could have every unique value make a unique hash, than you would have solved an unsolved computing problem.
hash functions are usually
one way functions
: some input values (objects) may produce the same hashcode.
It is basically saying that if two objects have the same hashcode they should be equal. However, this is not always the case since there is no (perfect) hash function that will always assign a different hash to a different object.
Different objects can have the same hashcode, due to hash collisions.
But two object that are equal should have the same hashcode.
来源：https://stackoverflow.com/questions/13570309/hashcode-and-equals-contract-vice-versa