关于不可变集和映射的JDK9随机化

阅读这个问题和Eugene给出的答案 ，我发现JDK9不可变集和映射将引入一个会影响其遍历的随机源。 这意味着迭代顺序确实是随机的，至少在JVM的不同运行中。

由于规范不保证集合和映射的任何遍历/迭代顺序，这绝对没问题。 实际上，代码绝不能依赖于特定于实现的细节，而是依赖于规范。

我知道今天，使用JDK 8，如果我有一个HashSet并执行此操作（取自链接的答案）：

 Set wordSet = new HashSet(Arrays.asList("just", "a", "test")); System.out.println(wordSet); for (int i = 0; i < 100; i++) { wordSet.add("" + i); } for (int i = 0; i < 100; i++) { wordSet.remove("" + i); } System.out.println(wordSet); 

然后元素的迭代顺序将改变，两个输出将不同。 这是因为向集合中添加和删除100个元素会更改HashSet的内部容量并重新生成元素。 这是完全有效的行为。 我这里不是在问这个问题。

但是，使用JDK9，如果我这样做：

 Set set = Set.of("just", "a", "test"); System.out.println(set); 

然后，在JVM的另一个实例中，我运行相同的代码，输出可能不同，因为已经引入了随机化。

到目前为止，我在youtube中找到了这个优秀的video（分钟44:55） ，其中Stuart Marks说这种随机化的一个动机是：

（…）人们编写的应用程序无意中依赖于迭代顺序。 （…）所以，无论如何，迭代顺序是一个大问题，我认为有很多代码存在潜在的依赖于迭代顺序尚未发现的代码。 （…）因此，我们对此的回应是故意将新集合中的Set和Map中的迭代顺序随机化。 因此，在收集的迭代顺序不可预测但稳定之前，这些是可预测的不可预测的。 因此，每次JVM启动时，我们都会获得一个随机数，并将其作为种子值使用，并与哈希值混合使用。 因此，如果你运行一个初始化一个集合然后以任何顺序打印出元素的程序，你会得到一个答案，然后，如果再次调用JVM并运行相同的程序，那么元素集通常会出现在不同的顺序。 所以，这里的想法是（…）如果你的代码中存在迭代顺序依赖，过去曾经发生的事情，是一个新的JDK版本出来了，你测试你的代码和（…）它’ d需要数小时的调试才能将其追溯到迭代顺序中的某种变化。 这意味着该代码中存在一个依赖于迭代顺序的错误。 现在，如果你更频繁地改变迭代次序，比如每次JVM调用，那么（我们希望）奇怪的行为会更频繁地表现出来，事实上我们希望你在做测试时……

因此，动机很明确，而且很明显，这种随机化只会影响新的不可变集和映射。

我的问题是： 这种随机化还有其他动机吗？它有什么优势？

Answer 1

事实certificate，随机迭代顺序还有另一个原因。 这不是一个大秘密或任何东西。 我以为我在那次谈话中已经解释过了，但也许没有。 我可能在OpenJDK邮件列表上或者在内部讨论中提到过它。

在任何情况下，随机迭代顺序的另一个原因是为将来的实现更改保留灵活性。

事实certificate这比大多数人想象的要大。 从历史上看， HashSet和HashMap从未指定过特定的迭代顺序。 但是，有时需要更改，改进性能或修复错误。 对迭代顺序的任何更改都会从用户中产生很多瑕疵。 多年来，许多阻力都在改变迭代顺序，这使得维护HashMap变得更加困难。

要了解这是一个问题，请考虑一系列不同的策略来管理迭代顺序的稳定性：

1. 指定迭代顺序，并坚持下去。

2. 保留迭代顺序未指定，但隐式保持迭代顺序稳定。

3. 不指定迭代顺序，但尽可能少地更改迭代顺序。

4. 经常更改迭代顺序，例如，在更新版本中。

5. 更频繁地更改迭代顺序，例如，从JVM的一次运行到下一次运行。

6. 更频繁地更改迭代顺序，例如，从一次迭代到下一次迭代。

在JDK 1.2中引入集合时，未指定HashMap迭代顺序。 LinkedHashMap以稍高的成本提供了稳定的迭代顺序。 如果您不需要稳定的迭代订单，则不必为此付费。 这排除了＃1和＃2。

对于接下来的几个版本，我们尝试保持迭代顺序稳定，即使规范允许它更改。 代码中断时没有人喜欢它，并且告诉客户他的代码被破坏是非常不愉快的，因为它取决于迭代顺序。

所以我们最终得到了政策＃3，尽可能保持迭代顺序尽可能稳定，尽管它确实不时发生变化。 例如，我们在JDK 7u6（JDK-7118743的代码审查 ）和JDK 8（ JEP 180 ）中的树容器中引入了替代散列，并且在某些情况下都改变了HashMap迭代顺序。 在早期版本中，订购也改变了几次。 有人做了一些考古学，发现每个主要JDK版本的迭代顺序平均改变了一次。

这是所有可能世界中最糟糕的。 主要版本每两年才发生一次。 当一个人出来时，每个人的代码都会破裂。 人们会修复他们的代码，并且我们承诺永远不会再次改变迭代顺序。 几年过去了，编写的新代码无意中依赖于迭代顺序。 然后我们将推出另一个改变迭代顺序的主要版本，这将再次破坏每个人的代码。 这个循环将重新开始。

我想避免为新集合重复这个循环。 我没有尽可能保持迭代顺序稳定，而是采取了尽可能频繁地改变它的政策。 最初， 每次迭代都会更改顺序，但这会带来一些开销。 最终，我们根据JVM调用确定了一次。 每个表探测器的成本是32位XOR操作，我认为这很便宜。

在某种程度上，这是关于“强化”应用程序代码。 如果更改迭代顺序会破坏代码，那么更频繁地破坏该代码将导致它产生那种破坏的阻力。 当然，代码本身并没有变得更强大; 它需要更多的开发人员才能实现这一目标。 人们会非常合理地抱怨不得不做这项额外的工作。

但是，应用程序代码的“强化”在某种意义上是inheritance保留更改实现的自由的另一个目标。 保留HashMap迭代顺序使得维护更加困难。 新集合中的随机迭代顺序意味着我们在修改它们时不必担心保留迭代顺序，因此它们更易于维护和增强。

例如，当前的实现（Java 9，pre-GA，2017年7月）有三个基于字段的Set（ Set0 ， Set1和Set2 ）实现和​​一个基于数组的实现（ SetN ），它使用简单的闭合散列和线性探测方案。 将来，我们可能希望添加一个Set3实现，该实现在三个字段中包含三个元素。 或者，我们可能希望将SetN的冲突解决策略从线性探测更改为更复杂的策略。 如果我们不必处理保留迭代顺序，即使在次要版本中，我们也可以完全重构实现。

总之，权衡是应用程序开发人员必须做更多的工作，以确保他们的代码抵制迭代顺序更改的破坏。 这可能是他们在某些时候必须使用HashMap做的工作。 通过这种方式获得的是JDK提供更多机会和空间效率的机会，每个人都可以从中受益。

Answer 2

这句话和你的想法已经成为支持这一点的有力论据。 那你还需要什么呢？

换句话说：Java的“父亲”之一宣称他们 “随机地图/集合顺序” 的动机是“教育”Java程序员不要期望甚至依赖任何特殊订单。 因此答案（可能是自以为是） – 质疑你的期望。

负责人告诉你他们这样做的想法。 没有理由认为他们“隐藏”了这个设计决策的其他动机。

恰恰相反：人们可能会发现反对花费额外努力来实现这种随机性的论据–JVM可能会花费相当多的额外CPU周期 – 只是为了实现不确定行为（我们通常会不惜一切代价避免这种行为）。