java - String.hashCode() 效率低下吗？-6ren

java - String.hashCode() 效率低下吗？

转载作者：塔克拉玛干更新时间：2023-11-03 05:06:13

<分区>

查看 source code of java.lang.String of openjdk-1.6 时，我看到 String.hashCode() 使用 31 作为质数并计算

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

现在我看这个的原因是我想到的问题是比较 String.equals 中的 hashCodes 是否会使 String.equals 明显更快。但是现在看hashCode，我想到了以下问题:

更大的素数是否有助于更好地避免冲突，至少对于短字符串而言，看到例如“BC”与“Ab”具有相同的散列(因为 ascii 字母位于 65-122 区域，不会'没有比那个更好的素数)？
使用 31 作为质数是有意识的决定，还是只是随机使用一个因为它很常见？
在给定固定字符串长度的情况下，哈希冲突的可能性有多大？这个问题的标题是最初的问题，比较 hashCodes 和字符串长度有多好已经可以辨别字符串，以避免比较实际内容。
可能有点跑题:String.equals 不将 hashCode 作为附加快捷方式进行比较有充分的理由吗？
有点离题:假设我们有两个内容相同但实例不同的字符串:有没有办法在不实际比较内容的情况下断言相等？我猜不会，因为在某种程度上进入字符串长度，空间会爆炸成我们不可避免地会发生冲突的大小，但是一些限制呢 - 只有特定的字符集，最大字符串长度......以及我们需要限制多少字符串空间能有这样的哈希函数吗？

塔克拉玛干

个人简介

我是一名优秀的程序员,十分优秀！

作者热门文章

滴滴打车优惠券免费领取

全站热门文章