为什么Sun指定String.hashCode（）实现？

Question

关于依赖当前String.hashCode()的实施是否安全似乎存在争议，因为从技术上讲，它是由规范（Javadoc）保证的。

1. 为什么Sun在规范中指定String.hashCode()的实现？
2. 为什么开发人员需要依赖hashCode（）的特定实现？
3. 为什么如果将来String.hashCode()发生变化，太阳会害怕天空会下降？ （这可能由＃2解释）

Answer 1

依赖于hashCode（）的特定实现的原因是它是否被持久存储到数据库，文件或任何其他存储介质中。如果在散列算法发生变化时读回数据，则会发生 Bad Things （tm）。您可能会遇到意外的哈希冲突，更令人担忧的是，无法通过哈希找到某些内容，因为哈希在持久化数据和“现在”之间发生了变化。

事实上，这几乎解释了第3点=）

第1点的原因可能是“允许互操作性”。如果hashCode实现被锁定，则可以非常安全地在不同的Java实现之间共享数据。即，无论实现如何，给定对象的散列都将始终相同。

Answer 2

自原始String类以来，实现已更改。如果我记得，过去只有每个第16个（？）字符在哈希中用于“长”字符串。

可能已指定促进后续Java版本之间的序列化互操作性，甚至不同供应商的运行时之间的序列化互操作性。我同意，程序员不应该直接依赖hashCode()的特定实现，但更改它可能会破坏序列化集合的 lot 。