Java String的hashCode实现

String类中的HashCode实现函数：

    /**     * Returns a hash code for this string. The hash code for a     * {@code String} object is computed as     * <blockquote><pre>     * s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]     * </pre></blockquote>     * using {@code int} arithmetic, where {@code s[i]} is the     * <i>i</i>th character of the string, {@code n} is the length of     * the string, and {@code ^} indicates exponentiation.     * (The hash value of the empty string is zero.)     *     * @return  a hash code value for this object.     */    public int hashCode() {        int h = hash;        if (h == 0 && value.length > 0) {            char val[] = value;             for (int i = 0; i < value.length; i++) {                h = 31 * h + val[i];            }            hash = h;        }        return h;    }

可以看到最终hash = s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1];

BKDRHash计算公式的推导

    由一个字符串（比如：ad）得到其哈希值，为了减少碰撞，应该使该字符串中每个字符都参与哈希值计算，使其符合雪崩效应，也就是说即使改变字符串中的一个字节，也会对最终的哈希值造成较大的影响。我们直接想到的办法就是让字符串中的每个字符相加，得到其和SUM，让SUM作为哈希值，如SUM（ad）= a+d;可是根据ascii码表得知a(97)+d(100)=b(98)+c(99)，那么发生了碰撞，我们发现直接求和的话会很容易发生碰撞，那么怎么办哪？我们可以对字符间的差距进行放大，乘以一个系数：

SUM(ad) =系数1 * a + 系数2 * d

SUM(bc)= 系数1 * b + 系数2 * c

    系数1不等于系数2，这样SUM(ad)等于SUM(bc)的概率就会大大减小。

    可是我们的字符串不可能只有两位或者三位，我们也不可能为每个系数去人为的赋值，但是字符串中有位数的顺序，比如在”ab”中，b是第0位，a是第1位,那么我们可以用系数的n次方作为每个字符的系数，但这个系数不能为1:

SUM(ad) =系数^1 * a + 系数^0 * d

SUM(bc)= 系数^1 * b + 系数^0 * c

    这样我们就大大降低了碰撞的发生，下面我们假设有个字符数组p，有n个元素，那么

即:

    下面就是这个“系数”取值的问题，取什么值那？从上面的分析来看，取除1之外的什么值都可以，我们知道整数不是奇数就是偶数，为了便于推算我们将偶数分为2的幂的偶数和非2的幂的偶数，也就是分3种取值讨论

系数的推导

    现在我们的任务是推导系数的值，分2的幂的偶数、非2的幂的偶数、奇数三个部分讨论。

a. 取2的幂

    假如我们取32，也就是2^5，那么我们计算SUM(ad)和SUM(bc)结果如下:3204、3235

结果不同，有效处理了碰撞。

    但是当我们进一步测试会发现，当我们取SUM(ahijklmn)和SUM(hijklmn)时计算得:3637984782、3637984782

取SUM(abhijklmn)和SUM(abchijklmn)时计算得:3637984782、3637984782

SUM(abcdefghijklmn)和SUM(123456hijklmn)时计算得:3637984782、3637984782

    我们会发现，只要最末尾的”hijklmn”这几个字符不变，不管前面怎么变，得到的哈希值都是一样的，完全碰撞了！这是为什么那？

    首先哈希值SUM的存储类型用什么？当然用unsignedint ,因为值会很大，unsigned int 是32位，而只要计算就可能会溢出，CPU对于溢出的处理是抛弃最高位，比如两个unsigned int 的值相加结果为33位，那么最高位33位就会被抛弃，那么我们对上面的情况进行计算:

计算SUM(ahijklmn)和SUM(bhijklmn)：

SUM(ahijklmn)= 32^7*a + 32^6*h + 32^5*I + 32^4*j + 32^3*k + 32^2*l + 32^1*m + 32^0*n

SUM(bhijklmn)= 32^7*b + 32^6*h + 32^5*I + 32^4*j + 32^3*k + 32^2*l + 32^1*m + 32^0*n

将32换为2^5得：

SUM(ahijklmn)= 2^35*a + 2^30*h + 2^25*I + 2^20*j + 2^15*k + 2^10*l + 2^5*m + 2^0*n

SUM(bhijklmn)= 2^35*b + 2^30*h + 2^25*I + 2^20*j + 2^15*k + 2^10*l + 2^5*m + 2^0*n

由此可知SUM(ahijklmn)和SUM(bhijklmn)都大于unsignedint所能表达的最大值，所以需要抛弃最高位，也就是对0x100000000(也就是2^33)取余，根据同余定理：

(a+b)%m= (a%m + b%m)%m

(a*b)%m= (a%m * b%m)%m

可知

SUM(ahijklmn)%2^33 = (2^35*a% 2^33 + 2^30*h% 2^33 + … + 2^0*n%2^33)% 2^33

SUM(bhijklmn)%2^33 = (2^35*b % 2^33 + 2^30*h % 2^33 + … + 2^0*n%2^33) 2^33

2^35*a% 2^33和 2^35*b % 2^33 为零，所以因溢出被CPU舍弃，得

SUM(ahijklmn)%2^33 = (2^30*h% 2^33 + … + 2^0*n% 2^33) 2^33

SUM(bhijklmn)%2^33 = (2^30*h % 2^33 + … + 2^0*n% 2^33) 2^33

最终他们的哈希值为

SUM(ahijklmn)= 2^30*h + 2^25*I + 2^20*j + 2^15*k + 2^10*l + 2^5*m + 2^0*n

SUM(bhijklmn)= 2^30*h + 2^25*I + 2^20*j + 2^15*k + 2^10*l + 2^5*m + 2^0*n

    所以SUM(ahijklmn)等于SUM(bhijklmn)，这就是为什么” hijklmn”不变时，不管前面是什么字符串都会被舍弃，得到一样的字符串。这里用的是32=2^5，只要你用2^n，n不管为多少都不行，都会因为字符串的长度达到一定值而造成前面的被舍弃，造成一直碰撞。

b. 取非2的幂的偶数

    既然去取2的幂不行，那么我们取非2的幂的偶数，假如我们取6作为系数，6为2^2+2，我们由上面取2的幂的推导可知，当字符的长度大于等于33时，系数就会变为6^32=3*2^33，可知系数大于2^32，对2^33取余，被舍弃，那么造成只要后32个字符不变，前面不管有多少个同的字符，都会被舍弃，计算所得的哈希值也就一样。

由上面两块可知，系数取偶数行不通

c. 取奇数（大于1）

    假如我们取9=2^3+1，9^2=81=80+1，9^3=729=728+1，… ，9^n=9^n-1+1，我们知道9的幂肯定是奇数，那么9^n-1肯定为偶数，由上面的推论可知字符串达到一定的长度时，偶数系数前面的字符是可以舍弃的，可是9^n=9^n-1+1，最后的1是永远不会被舍弃的，所以每个字符都会参与运算，取大于1的奇数可行。

结论

由上面三步的推导可知，这个系数应当选择大于1的奇数，这样可以很好的降低碰撞的几率

扩展

    注意：即使最终求得的bkdrhash值几乎不会冲突碰撞，但他们都是很大的值，不可能直接映射到哈希数组地址上，所以一般都是直接对哈希数组大小取余，以余数作为索引地址，但是这就造成了，可能的地址冲突。bkdrhash值不一样，但是取余后得到的索引地址一样，也就是冲突，只是这种冲突的概率很小。对于哈希表不可能完全消除碰撞，只能降低碰撞的几率。作为对哈希知识的进一步熟悉，下面罗列几点提升哈希表效率的注意点:

1.选用的哈希函数

    哈希函数的目的就是为了产生譬如字符串的哈希值，让不同的字符串尽量产生不同的哈希值的函数就是好的哈希函数，完全不会产生相同的哈希函数就是完美的。

2.处理冲突的方法

    处理冲突的方法有多种，拉链法、线性探测等，我喜欢用拉链法

3.哈希表的大小

    这个哈希表的大小是固定的，但可以动态调整，也就是创建个新的数组，用旧的给新的循环重新计算Key赋值，删除旧的。但最好根据需求数据量设置足够大的初始值，防止动态调整的频繁，因为调整是很费时又费空间的。还有重要的是，这个哈希表的大小要设为一个质数，为什么是质数？因为质数只有1和它本身两个约数，当用bkdrhash算得的key对哈希表大小取余时，不会因为存在公约数而缩小余数的范围，如果余数范围缩小的话，就会加大碰撞的几率(说法有点牵强，知道的童鞋请给个合理的解释)。

4.装载因子，即哈希表的饱和程度

    一般来说装载因子越小越好，装载因子越小，碰撞也就越小，哈希表的速度就会越快，可是这样会大大的浪费空间，假如装载因子为0.1，那么哈希表只有10%的空间被真正利用，其余的90%都浪费了，这就是时间和空间的矛盾点，为了平衡，现在大部分采用的是0.75作为装载因子，装载因子达到0.75，那么就动态增加哈希表的大小。