说一说java里面的hashcode3-再说string-hashcode

[url]http://www.hetaoblog.com/%E8%AF%B4%E4%B8%80%E8%AF%B4java%E9%87%8C%E9%9D%A2%E7%9A%84hashcode3-%E5%86%8D%E8%AF%B4string-hashcode/[/url]

前一篇文章说一说java里面的hashcode-string-hashcode， 这篇再多说一下这个String.hashcode(),

我看到String.hashcode()的冲突的时候，第一个想法就是，哈，那不是质数31取的太小了么？导致在常用ascii字符集里面容易冲突，那么，直接设个大点的质数不就好了么？幸运的是，257就是个质数，那么就用257，立刻就可以避免之前的冲突的例子了，下面是一段代码

@Test
public void testBetterhash()
{
System.out.println(betterHash("Aa") + "," + betterHash("BB"));
System.out.println(betterHash("Ba") + "," + betterHash("CB"));
System.out.println(betterHash("Ca") + "," + betterHash("DB"));
System.out.println(betterHash("Da") + "," + betterHash("EB"));
}
public static int betterHash(String s)
{
int h = 0;
int len = s.length();

for (int i = 0; i < len; i++) {
h = 257*h + s.charAt(i);
}

return h;
}

返回的结果很好，全部不冲突
16802,17028
17059,17285
17316,17542
17573,17799

不过悲剧的是，该算法相当于以257为进制，每次乘以257至少相当于移了8位多，在32位jdk下面，int只有32位，遇到5个字符就溢出了，调用betterHash("abcde")就会返回-372058641

所以，这个想法自然就失败了；
那么，原来的String.hashcode()算法在‘通常情况’下大约有多少的冲突概率呢？

为此，我从http://www.mieliestronk.com/wordlist.html下载了常用英文单词表，其中包含了将近6万个单词，我为了测试大小写排列组合的情况，取了前面5000个单词，然后对每个单词做大小写全排列，
也就是cat会有cat/caT/cAt/cAT/Cat/CaT/CAt/CAT 这8种情况，得到8021600个不同的字符串，分别计算他们的hashcode(),得到了8012142个不同的hashcode，也就是有9458 个冲突，在这样的场景下，大约有超过千分之一的冲突；

我想, jdk的实现肯定是经过了充分的考虑，考虑到大多数情况下能够在所有域上冲突能够做均匀分布；