Reason for using 31 coefficient when defining hashcode

Hash calculation is to calculate which element of the array the element should be placed in. Exactly which linked list is put in. According to Java rules, if you want to put an object into a HashMap, your object class must provide a hashcode method to return an integer value. For example, the string class has the following methods:

Notice the for loop above, isn't it? Let me give you an example to make it easy for you to understand what it is doing. For example, there is a string "ABCDE", which uses the 31 base calculation method to calculate the sum of this string. You will write the following calculation formula:

a*31^4+b*31^3+c*31^2+d*31^1+e*31^0. Note that a, B, C, D or e here refer to their ASCII values. Very interesting loop, actually can be used to calculate n-ary. This loop can be extracted separately as a good tool for calculating the base value:

The static method caculate accepts Radix as the base number. Array a simulates the base number to be calculated, but note that the surface order needs to be consistent. For example, the 01 binary string should be arranged according to {0,1} in the array. The output result above is 1, which conforms to the true value of 01.

So why use 31 as the base? First understand why you need hashcode Each object calculates the hashcode based on the value. Although the code size is not expected to be unique (because it is usually very slow to calculate), it should not be repeated as much as possible, so the cardinality should be as large as possible. In addition, 31 * n can be optimized by the compiler to shift 5 bits left and subtract 1, which has high performance. In fact, the selection of 31 is still controversial. Refer to here.

Detailed introduction to rewriting hashcode() and equals() methods

Explain the essential difference and relationship between hashcode() and equals()

Analysis of HashMap usage from the perspective of Java source code