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

Question

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

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

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

我们向服务器发送一组请求的结果类型,这最初取自config并放入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更新X而不是Java 6更新Y),迭代顺序也可能不同.

列出特定于实现的更改的任何位置都没有列表.如果您编写的Java程序依赖于特定Java版本的未记录的实现细节,那么您的程序可能不再适用于任何其他Java版本.

Oracle提供了JDK 8兼容性指南,其中解释了Java 8与先前版本存在轻微不兼容性的方式,但这仅包括Java API中的更改,而不是实现细节.

如果您确实从Java 6升级到Java 8(无论如何推荐,因为不再支持Java 6),那么在将它们投入生产之前测试您的程序.