我有一个应用程序，它按行显示一组对象，一个对象 = 一行。对象存储在 HashMap 中。行的顺序不会影响应用程序的功能（这就是使用 HashMap 而不是可排序集合的原因）。
但是我注意到，当使用两个不同版本的 Java 虚拟机运行相同的应用程序时，运行方式会有所不同。该应用程序使用 JDK 5 编译，可以使用 Java 5 或 Java 6 运行时运行，没有任何功能差异。
有问题的对象会覆盖java.lang.Object#hashCode()，并且显然已经注意遵循 Java API 中指定的约定。事实证明，它们在应用程序的每次运行中总是以相同的顺序出现（在同一个 Java 运行时中）。
出于好奇，为什么 Java 运行时的选择会影响顺序？
HashMapcan and do change的实现细节。这个包私有方法很可能是这样做的（来自 JDK 1.6.0_16）：
/**
* Applies a supplemental hash function to a given hashCode, which
* defends against poor quality hash functions. This is critical
* because HashMap uses power-of-two length hash tables, that
* otherwise encounter collisions for hashCodes that do not differ
* in lower bits. Note: Null keys always map to hash 0, thus index 0.
*/
static int hash(int h) {
// This function ensures that hashCodes that differ only by
// constant multiples at each bit position have a bounded
// number of collisions (approximately 8 at default load factor).
h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>> 7) ^ (h >>> 4);
}
作为参考，JDK 1.5.0_06 中的类似物是：
/**
* Returns a hash value for the specified object. In addition to
* the object's own hashCode, this method applies a "supplemental
* hash function," which defends against poor quality hash functions.
* This is critical because HashMap uses power-of two length
* hash tables.<p>
*
* The shift distances in this function were chosen as the result
* of an automated search over the entire four-dimensional search space.
*/
static int hash(Object x) {
int h = x.hashCode();
h += ~(h << 9);
h ^= (h >>> 14);
h += (h << 4);
h ^= (h >>> 10);
return h;
}
可能是因为 aMap没有定义为具有任何特定的迭代顺序；元素返回的顺序可能是其内部实现的产物，不需要保持一致。
如果实现在 Java 5 和 6 之间更新（尤其是出于性能原因），Sun 没有任何好处或义务来确保两者之间的迭代顺序保持一致。
编辑：我刚刚在早期的 Java 6 版本之一中发现了一个有趣的片段（不幸的是，我不确定确切的版本，但它显然是 2006 年 6 月的 HashMap 1.68）：
/**
* Whether to prefer the old supplemental hash function, for
* compatibility with broken applications that rely on the
* internal hashing order.
*
* Set to true only by hotspot when invoked via
* -XX:+UseNewHashFunction or -XX:+AggressiveOpts
*/
private static final boolean useNewHash;
static { useNewHash = false; }
private static int oldHash(int h) {
h += ~(h << 9);
h ^= (h >>> 14);
h += (h << 4);
h ^= (h >>> 10);
return h;
}
private static int newHash(int h) {
// This function ensures that hashCodes that differ only by
// constant multiples at each bit position have a bounded
// number of collisions (approximately 8 at default load factor).
h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>> 7) ^ (h >>> 4);
}
所以看起来，尽管我有上述断言，Sun 实际上确实考虑了迭代顺序的一致性——在稍后的某个时间点，这段代码可能被删除了，新的顺序成为了最终的顺序。
HashMap 没有与任何特定的顺序结合，但Map 的LinkedHashMap实现应该保留顺序。