为什么 Sun 指定 String.hashCode() 实现？
关于依赖 String.hashCode() 当前的实现是否安全，似乎一直存在争论，因为从技术上讲，它是由规范 (Javadoc) 保证的。
- 为什么Sun 在规范中指定了
String.hashCode()的实现？ - 为什么开发人员需要依赖 hashCode() 的特定实现？
- 为什么Sun这么害怕以后
String.hashCode()一改天就塌了？ （这可能由#2 来解释）
There seems to be an ongoing debate about whether it is safe to rely on the current implementation of String.hashCode() because, technically speaking, it is guaranteed by the specification (Javadoc).
- Why did Sun specify
String.hashCode()'s implementation in the specification? - Why would developers ever need to rely upon a specific implementation of hashCode()?
- Why is Sun so afraid that the sky will fall if
String.hashCode()is changed in the future? (This is probably be explained by #2)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
依赖 hashCode() 的特定实现的一个原因是它是否被持久保存到数据库、文件或任何其他存储介质中。如果在哈希算法更改时读回数据，就会发生坏事(tm)。您可能会遇到意外的哈希冲突，更令人担忧的是，无法通过哈希找到某些内容，因为哈希在数据持久化和“现在”之间发生了变化。
事实上，这也很好地解释了第 3 点 =)
第 1 点的原因可能是“允许互操作性”。如果 hashCode 实现被锁定，那么数据可以在 Java 的不同实现之间非常安全地共享。即，无论实现如何，给定对象的散列总是相同的。
A reason for relying on the specific implementation of hashCode() would be if it is ever persisted out into a database, file or any other storage medium. Bad Things(tm) would happen if the data was read back in when the hashing algorithm had changed. You could encounter unexpected hash collisions, and more worryingly, the inability to find something by its hash because the hash had changed between the data being persisted and "now".
In fact, that pretty much explains point #3 too =)
The reason for point #1 could be "to allow interoperability". If the hashCode implementation is locked down then data can be shared between different implementations of Java quite safely. i.e, the hash of a given object will always be the same irrespective of implementation.
自原始
String类以来，实现已发生变化。如果我记得的话，过去只有每 16 个（？）字符用于“长”字符串的哈希值。它可能被指定为促进 Java 后续版本之间，甚至不同供应商的运行时之间的序列化互操作性。我同意，程序员不应该直接依赖
hashCode()的特定实现，但更改它可能会破坏大量序列化集合。The implementation has changed since the original
Stringclass. If I recall, it used to be that only every 16th (?) character was used in the hash for "long" strings.It may have been specified to promote serialization interoperability between subsequent versions of Java, or even between the runtimes of different vendors. I agree, a programmer should not rely on a particular implementation of
hashCode()directly, but changing it could potentially break a lot of serialized collections.