通常,默认实现Object.hashCode()是内存中对象的已分配地址的某个函数(尽管这不是JLS强制要求的).鉴于VM在内存中分流对象,为什么System.identityHashCode()在对象的生命周期内返回的值永远不会改变？
如果它是"一次性"计算(对象的hashCode计算一次并隐藏在对象标题或其他东西中),那么这是否意味着两个对象可能具有相同的identityHashCode(如果它们碰巧首先在内存中的相同地址)？
六年前,我烧了几天试图追捕我完全确定的框架随机响应的地方.在精心追逐整个框架确保它全部使用相同的Random实例后,我继续追逐单步执行代码.这是高度重复的迭代自调用代码.更糟糕的是,该死的效果只会在完成大量迭代后出现.在+6小时之后,当我在javadoc中为HashSet.iterator()发现一行时,我终于处于智慧状态,表明它不能保证返回元素的顺序.然后我浏览了整个代码库,并用LinkedHashSet替换了所有HashSet实例.而且,我的框架正好向确定性生活迈进!哎呀!
我现在刚刚经历过同样的FREAKIN影响(至少这次只有3个小时).无论出于何种原因,我都错过了HashMap碰巧为其keySet()获得相同方式的细节.
这是关于这个主题的SO线程,虽然讨论从来没有完全回答我的问题:HashSet的迭代顺序
所以,我很好奇为什么会这样.鉴于我两次都有一个庞大的单线程java应用程序在完全相同的实例化/插入空间中使用完全相同的JVM参数(来自同一批处理文件的多次运行)在同一台计算机上运行,几乎没有其他任何运行,这可能会扰乱JVM使得HashSet和HashMap在经过大量迭代之后会表现得不可预测(并不是因为javadoc说不依赖于顺序而不一致)？
从源代码(java.util中的这些类的实现)或者你对JVM的了解(可能是某些GC影响内部java类在分配内部存储空间时获得非零内存的位置)的任何想法？