In java 8 java.util.Hashmap I noticed a change from:
static int hash(int h) {
h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>>
As you noted: there is a significant performance improvement in HashMap
in Java 8 as described in JEP-180. Basically, if a hash chain goes over a certain size, the HashMap
will (where possible) replace it with a balanced binary tree. This makes the "worst case" behaviour of various operations O(log N)
instead of O(N)
.
This doesn't directly explain the change to hash
. However, I would hypothesize that the optimization in JEP-180 means that the performance hit due to a poorly distributed hash function is less important, and that the cost-benefit analysis for the hash
method changes; i.e. the more complex version is less beneficial on average. (Bear in bind that when the key type's hashcode
method generates high quality codes, then gymnastics in the complex version of the hash
method are a waste of time.)
But this is only a theory. The real rationale for the hash
change is most likely Oracle confidential.