hashcode() 与 toString().hashcode();答案

【问题标题】：hashcode() vs toString().hashcode();hashcode() 与 toString().hashcode();
【发布时间】：2020-03-20 14:20:18
【问题描述】：

只是想讨论和理解以下代码之间的区别。

一个>

SortedSet<String> set = new TreeSet<>();
set.addAll(str);
int hashcode= set.toString().hashCode();

SortedSet<String> set = new TreeSet<>();
set.addAll(str);
int hashcode = set.hashCode();

我已经检查了如果您将相同的字符串元素以任何顺序放入两个集合中，哈希码返回值将是相同的。只是想知道条件 a> 比

【问题讨论】：

不同之处在于，您在集合上直接请求hashCode，而不是在它的字符串表示上请求。如果您碰巧得到相同的值，这纯属巧合，并且可以并且将会随着任何 Java 更新而改变。集合的字符串表示可能会改变。 String 的 hashCode 实现可能会改变。 TreeSet 的 hashCode 实现可能会改变。如果其中任何一个发生变化，那么两者之间的哈希值肯定会有所不同。
在这种情况下，您所说的“安全”是什么意思？防范什么？
这里的哈希码不是加密哈希。但是，是的，如果不知道威胁是什么，就不能谈论安全。
@Zabuzza String 和 Set 已定义。（虽然在 1.00 中String 确实有一个不可能的定义，但从 1.1 开始应该保持不变。）
如果替换了加密散列（这是担心的角度），则 toString 方法不会生成安全散列，因为分隔符可能出现在元素字符串中。字符串化键是漏洞的常见原因。

【解决方案1】：

第一个 sn-p 将集合转换为字符串（可能是繁重的操作），然后对其进行哈希处理。第二个直接散列集合。

由于相等的集合会产生相等的字符串和相等的哈希，所以这两种方法在技术上都可以，但是首先将集合转换为字符串确实是多余的（方法 a） - 使用它没有任何好处，而你正在做的一切在转换为字符串时浪费资源。

【讨论】：

"相等的集合会产生相等的字符串" 可以保证吗？由于集合不保证顺序，集合[1,2,3] 有时会产生字符串[1,3,2] 有时会产生[3,2,1] 吗？
@Sweeper TreeSets 保证订单。唯一的问题是如果compareTo 和equals 不同意（BigInteger 和显然是Double）。
@Sweeper 是的 - 不能保证集合的顺序，但它是稳定的。给定相同的 JRE 和 JDK，相同的集合将始终具有相同的顺序。此外，正如 Tom 提到的，这些是 SortedSet，因此无论如何都可以保证顺序