为何从Redis ZSet构造的Java HashSet能保持输入顺序？

这其实是巧合+特定实现细节的组合，HashSet本身并不保证迭代顺序，我们一步步拆解来看：

1. 先明确HashSet的本质 #

HashSet底层完全依赖HashMap实现，它的迭代顺序由HashMap的遍历逻辑决定：

• HashMap会先对元素的hashCode()做扰动计算得到哈希值，再映射到对应的桶位置。
• 遍历的时候，会按桶的索引从小到大依次遍历，每个桶内的元素（如果有哈希冲突）再按链表/红黑树的顺序遍历。
• 本质上，HashSet的迭代顺序和元素插入顺序没有必然联系，也不做任何有序保证。

2. 第一个本地HashSet例子的“有序”是巧合 #

你第一个例子中输出1 2 3 4 5，只是刚好踩中了几个特定条件：

• Integer的hashCode()返回自身值，而因为数值较小，经过HashMap的扰动计算后哈希值还是原数（高位都是0，右移16位异或后不变）。
• HashMap默认初始容量是16，桶索引计算为哈希值 & (16-1)，结果就是元素本身（因为所有元素都小于16）。
• 遍历桶的时候按索引0到15的顺序，所以刚好输出1、2、3、4、5——但这完全是巧合，如果你添加一个17（哈希值17，桶索引1），它会和1挤在同一个桶，遍历顺序立刻就会被打乱。

3. Redis ZSet转HashSet的“顺序保持”是怎么回事？ #

你的第二个例子中，看似HashSet保留了Redis ZSet的顺序，主要有两个核心原因：

（1）Redis ZSet的range方法返回有序列表 #

Redis ZSet是天生的有序集合，range(key, 0, -1)会严格按照score从小到大返回元素，也就是你添加时的顺序：1、4、3、2、5。RedisTemplate会把这个有序列表转换成Set返回。

（2）Spring Data Redis的实现细节（或特殊巧合） #

这里有两种最可能的情况：

• 实际是LinkedHashSet：LinkedHashSet是HashSet的子类，它通过维护双向链表来保证迭代顺序和插入顺序一致。虽然你输出set.getClass()是java.util.HashSet，但有可能是代理类、类型擦除或旧版本Spring Data Redis的显示问题——LinkedHashSet的getClass()本应返回自身，但如果实例被包装过，可能会显示父类HashSet。
• 极端巧合的哈希分布：如果确实返回的是普通HashSet，那只有一种可能是这些元素的哈希值对应的桶索引，刚好在HashMap遍历的时候和插入顺序一致。但按照Integer的哈希计算逻辑，这种情况理论上不会出现（按桶索引顺序应该是1、2、3、4、5），所以更可能是第一种情况。

总结 #

永远不要依赖HashSet的迭代顺序，它本身不做任何有序保证。如果需要有序的Set，应该直接使用LinkedHashSet（保证插入顺序）或TreeSet（保证自然排序）。Redis ZSet本身是有序的，如果你需要保留它的顺序，建议用SortedSet接收返回值，或者显式转换成LinkedHashSet。

内容的提问来源于stack exchange，提问作者Sheldon Wei