I read in a book that hashCode() shows a memory area which helps (e.g. HashSets) to locate appropriate objects in memory. But how can that be true if we cannot manipulate memory in Java directly? There are no pointers, in addition to it objects are created and moved from one place to another and the developer doesn’t know about it.
I read that realization like hashCode() {return 42;} is awful and terrible, but what’s the difference if we can’t instruct VM where to put our objects?
The question is: what is the purpose of hashCode() on deep level if we can’t manipulate memory?
I like Jon Skeet’s answer (+1) but it requires knowing how hash tables work. A hash table is a data structure, basically an array of buckets, that uses the hashcode of the key to decide which bucket to stick that entry in. That way future calls to retrieve whatever’s at that key don’t have to sift through the whole list of things stored in the hashtable, the hashtable can calculate the hashcode for the key, then go straight to the matching bucket and look there. The hashcode has to be something that can be calculated quickly, and you’d rather it was unique but if it isn’t it’s not a disaster, except in the worst case (your
return 42;), which is bad because everything ends up in the same bucket and you’re back to sifting through everything.The default value for Object#hashCode may be based on something like a memory location just because it’s a convenient sort-of-random number, but as the object is shunted around during memory management that value is cached and nobody cares anyway. The hashcodes created by different objects, like String or BigDecimal, certainly have nothing to do with memory. It’s just a number that is quickly generated and that you hope is unique more often than not.