Collections.shuffle() 有时不生效，因集合不可修改（如unmodifiableList）或非RandomAccess实现（如LinkedList性能差）；默认用System时间种子，快速调用可能结果重复；其基于Fisher–Yates算法，正确高效，无需手写。
为什么 Collections.shuffle() 有时不生效？
因为传入的集合不是 RandomAccess 实现类，或者被包装成了不可修改视图。比如用 Arrays.asList() 得到的列表是固定大小的，但它是支持随机访问的；而如果再套一层 Collections.unmodifiableList()，调用 shuffle() 就会抛 UnsupportedOperationException。
- 确保集合底层是可修改的（如
ArrayList、LinkedList），避免用unmodifiableXXX或singletonList等只读包装 - 对
LinkedList调用shuffle()性能较差（O(n²) 随机访问），建议先转成ArrayList再洗牌 - 若集合为空或只有一个元素，
shuffle()不报错也不做任何事——这是正常行为，不是 bug
Collections.shuffle() 的随机性从哪来？
默认使用 new Random() 实例，种子由系统时间决定。这意味着：在毫秒级时间窗口内连续创建多个 shuffle() 调用，可能得到相同结果——尤其在单元测试或快速循环中。
- 需要可重现结果时，显式传入带固定种子的
Random对象：Collections.shuffle(list, new Random(123L)) - 生产环境一般不用干预，默认行为足够；但安全敏感场景（如抽奖逻辑）应避免依赖系统时间种子
- Java 17+ 中
Random已默认使用LXM算法，比旧版LinearCongruentialGenerator更均匀，无需额外升级
替代方案：自己写 shuffle 会更可控吗？
标准库的 shuffle() 就是 Fisher–Yates（Knuth shuffle）实现，正确且高效。手写容易出错，比如典型错误是用 rand.nextInt(i) 而非 rand.nextInt(i + 1)，导致分布不均。
- 不要用
list.sort((a,b) -> Math.random() - 0.5)—— 这不是真随机，排序器行为未定义，Chrome V8 曾因此产生严重偏差 - 若需打乱流（
Stream），不能直接 shuffle，得先收集为List再调用：list.stream().collect(Collectors.toList())后 shuffle - 对大型集合（百万级），
shuffle()是原地操作，内存友好；自己用Stream.generate()+limit()模拟反而易 OOM
泛型擦除会影响 shuffle() 吗？
完全不影响。该方法签名是 public static void shuffle(List> list)，只依赖 List 接口的 get() 和 set()，与类型擦除无关。你传 List<string></string>、List<integer></integer> 或原始类型 List（不推荐），运行期行为一致。
立即学习“Java免费学习笔记（深入）”；
- 唯一要注意的是：如果集合里存的是不可变对象（如
String），洗牌只是重排引用，不影响元素自身状态 - 若集合含自定义对象，只要没重写
equals/hashCode导致比较异常，就和shuffle()无关 - 泛型警告（raw type）只影响编译期检查，不改变实际打乱逻辑
事情说清了就结束。真正容易被忽略的是：洗牌前后集合引用没变，但顺序变了——如果你把 list 传给了别的模块并假设它有序，这时候就得小心了。
