java - 32 位和 64 位之间集合实现的差异，我们需要担心的任何陷阱？

Question

我们有一个 32 位客户端进程，它通过 CORBA 与远程机器上运行的遗留服务器应用程序进行通信。这已经运行良好且可靠了大约 12 年。

我们需要(暂时)将我们的客户端进程切换到 64 位以获得更多内存(等待即将重写)并且几乎立即遇到了一些远程应用程序的问题。该过程反复崩溃。最初这没有任何意义，如果远程应用程序使用 CORBA 等平台不可知协议(protocol)，它怎么会对客户端应用程序 VM 敏感？

经过几天的调查，我们发现远程进程崩溃与客户端 VM 无关，但似乎与我们发送的参数顺序有关。

我们向服务器发送一个请求结果类型的数组，这最初是从配置中获取并放入一个 HashSet，在最后一刻转换为一个数组。服务器应用程序似乎对请求的结果类型的顺序很敏感。

例如如果我们发送 PV (0)、DELTA (1)、NPV (2)、GAMMA (3) 就没问题。如果我们发送 GAMMA (3)、PV (0)、DELTA (1)、NPV(2)，远程应用程序就会崩溃。这似乎是远程应用程序中的一个奇怪的错误，以前从未暴露过，因为顺序一直是数字(偶然)。

切换到 64 位似乎有所不同，64 位版本产生与 HashSet 不同的元素排序。这不是我所期望的，但我怀疑 HashCodes 仅在平台基础上具有确定性。

确保在发送之前对数组进行排序已经解决了这个问题。切换到 TreeSet 也会有所帮助，但那是在图书馆深处的某个地方。

我们需要担心 32 位和 64 位之间的任何其他奇怪之处吗？到目前为止，转换的简单程度给我留下了深刻的印象，根本没有其他代码更改。

目前我们使用的是 Java 6，迁移到 Java 8 迫在眉睫。迁移到 Java 8 时我们会遇到类似的问题吗？

Answer 1

首先，Java字节码是平台无关的。您可以在 32 位或 64 位 JVM 上运行相同的字节码；您不需要为特定平台重新编译代码。

Map 的实现通常没有指定的迭代顺序，因此您不应编写依赖于元素顺序的程序，例如 HashMap。如果你这样做，正如你所发现的，那么你的应用程序中就有一个错误。如果您需要特定的迭代顺序，请使用例如 LinkedHashMap(保持元素的插入顺序)或 TreeMap(保持元素排序，使用您指定的任何标准) .

如果有更多可用内存(例如，因为您使用 64 位 JVM 而不是 32 位 JVM，内存设置不同)，HashMap 的行为可能会有所不同。如果您使用稍微不同的 JVM 版本(例如，Java 6 update X 而不是 Java 6 update Y)，迭代顺序也可能会不同。

没有任何地方列出特定于实现的更改。如果您编写的 Java 程序依赖于特定 Java 版本的未记录实现细节，那么您的程序当然有可能不再适用于任何其他 Java 版本。

Oracle 有一个 Compatibility Guide for JDK 8其中解释了 Java 8 究竟在哪些方面与以前的版本存在轻微的不兼容性，但这只涵盖了 Java API 的变化，而不是实现细节。

如果您确实从 Java 6 升级到 Java 8(无论如何推荐，因为不再支持 Java 6)，然后在将程序投入生产之前测试您的程序。