直接用 Collections.shuffle() 就行，别自己写随机交换

说到给集合洗牌，很多人的第一反应是自己写个循环，用 Random 生成下标然后交换元素。

但真的有必要吗？答案是否定的。

Ja va 标准库里的 Collections.shuffle() 方法，就是一个经过千锤百炼、完全符合 Fisher-Yates 洗牌算法的现成方案。

自己手动实现，不仅容易在边界处理上出错，导致元素分布不均，还可能在小规模集合上引入难以察觉的偏向性。

使用前提与注意事项

不过，使用它有个明确的前提：它只接受 List 接口的实现。 如果你手头是 Set 或者 Map，直接调用是行不通的——这一点常常被忽略。

具体使用时，还有几个细节需要留意：

• 可变性要求：传入的 List 必须是可变的，比如 ArrayList 或 LinkedList。如果你传入了由 Arrays.asList() 返回的固定大小列表，程序会抛出 UnsupportedOperationException。
• 线程安全：它的无参版本内部使用默认的 Random 实例，这在多线程环境下并不安全。对于高并发场景，更稳妥的做法是传入一个线程安全的随机数生成器，比如 ThreadLocalRandom.current()。
• 性能表现：它的时间复杂度是 O(n)，空间复杂度是 O(1)，属于原地打乱，不会创建新的集合对象。

Collections.shuffle() 的两个重载版本怎么选

这个方法提供了两个入口：

public static void shuffle(List list)
public static void shuffle(List list, Random rnd)

它们的核心区别在于是否允许你控制随机数源。

无参版本：方法内部会创建一个新的 Random 实例，其种子依赖于系统时间。这适用于大多数一次性的、对随机性要求不苛刻的场景，比如刷新用户界面上的一个列表。

有参版本：则给了你更大的灵活性。

• 你可以传入一个已有的 Random 对象进行复用。
• 可以传入 ThreadLocalRandom.current() 来避免多线程竞争，提升性能。
• 更重要的是，在编写单元测试时，你可以传入一个固定了种子的 Random 对象（例如 new Random(42)），从而确保每次测试运行都能得到完全一致的“随机”结果，这对于测试的可重复性至关重要。

至于 SecureRandom，虽然它能提供密码学级别的强随机性，但性能开销较大，除非有特殊安全需求，否则在一般业务逻辑中并不需要用到它。

对非 List 集合（如 HashSet、LinkedHashMap）怎么洗牌

标准库没有为 Set 或 Map 提供直接的洗牌方法。

通用的解决思路是：先将它们转换为 List，对 List 进行洗牌，然后再根据需求转换回去。 不过，这个过程中需要注意语义可能丢失的问题。

• HashSet：由于其本身不保证顺序，转换洗牌后再转回 Set 是可行的，结果依然是一个合法的、元素唯一的集合。
• LinkedHashMap：情况复杂一些。它通常用来维护插入顺序或访问顺序。如果你希望重建一个保持新顺序的 Map，就必须使用 new LinkedHashMap(list.size()) 并按洗牌后的顺序逐个放入键值对。这样一来，新的 LinkedHashMap 的插入顺序就是洗牌后的顺序，但原来的访问顺序信息就丢失了。
• TreeSet：不建议进行洗牌操作。因为它内部依赖元素的 compareTo() 方法来维持排序结构。即使你将其转换为 List 洗牌后再放回去，它也会立刻根据比较规则重新排序，之前的洗牌等于做了无用功。

下面是一个安全转换的示例代码：

List temp = new ArrayList<>(myHashSet);
Collections.shuffle(temp, ThreadLocalRandom.current());
// 后续可以直接使用 temp 列表，或者重建 set：new HashSet<>(temp)

常见报错和静默陷阱

有些问题不会直接导致程序崩溃，但会让程序行为偏离预期，更值得警惕。

• UnsupportedOperationException：当你对 Arrays.asList(arr) 返回的列表调用 shuffle 时，就可能触发这个异常。因为这个方法返回的是一个基于原始数组的、固定大小的视图，不支持结构修改。解决办法很简单，用 new ArrayList(Arrays.asList(...)) 包装一层即可。
• “洗了但没洗”：如果你传入一个空集合或者只有一个元素的集合，方法会正常执行完毕，但显然看不出任何效果。这属于方法的正确行为，并非缺陷。
• 测试结果不一致：如果没使用固定种子的 Random，每次运行测试得到的结果都可能不同，这会给断言带来麻烦。因此，在单元测试中务必传入像 new Random(123) 这样的固定种子生成器。
• 与流式操作混淆：有人可能会写出这样的代码：list.stream().map(...).collect(...) 之后，再去对原始的 list 调用 shuffle。需要记住，stream 操作是惰性的，collect 才会触发计算并生成一个新的列表，原始的 list 并不会被改变。此时去洗牌，洗的可能是那个已经被“遗忘”的旧引用。

真正需要小心的是那些编译期不会报错，但运行时才会暴露的问题，比如类型判断失误和可变性检查疏漏。

《夸克》非常好用的免费AI浏览器

下载APP查看