Collections.shuffle 使用 Fisher-Yates 算法，从后往前逐个随机交换，确保每种排列概率严格相等；公正性依赖均匀 Random、不可预测种子及可修改列表，需统计检验验证。
Collections.shuffle 使用 Fisher-Yates（Knuth）洗牌算法，是真正公平的随机重排方法——只要底层 Random 实现是均匀的，每个排列出现的概率就严格相等，不存在偏差。
为什么它能保证公正性
关键在于它的“从后往前逐个固定”逻辑：对长度为 n 的列表，从索引 n−1 开始，每次在 [0, i] 范围内选一个位置与当前位置交换。这样第 i 个位置被填入任意元素的概率恒为 1/(i+1)，而前面未固定的位置又递归满足相同条件。
数学上可证：总共有 n × (n−1) × … × 1 = n! 种执行路径，每条路径概率均等，且一一对应一种最终排列，因此所有 n! 种排列等概率出现。
这和“每次随机选两个位置交换”或“遍历中随机选全局索引交换”的错误写法有本质区别——后者会产生 nⁿ 条路径，无法整除 n!，必然导致某些排列被重复覆盖、概率偏高。
影响公正性的实际风险点
算法本身无缺陷，但公正性依赖外部条件。以下情况会破坏等概率假设：
- 使用了非均匀 Random 实现：比如早期 JDK 中某些 Random 版本在低位存在周期性，或自定义 Random 重写了 nextInt() 但未保证分布均匀
- 种子值过小或可预测：如用当前毫秒时间戳做 seed，在高并发短时序场景下易重复，导致多线程拿到相同打乱序列
- 传入不可变或只读 List：例如 Arrays.asList() 返回的列表底层绑定数组，但若该列表被包装为 Collections.unmodifiableList()，调用 shuffle 会直接抛 UnsupportedOperationException，无法完成洗牌
- 对 LinkedList 大量调用 shuffle：虽算法公正，但因 LinkedList 不支持 O(1) 随机访问，JDK 内部会先转数组再回写，若中途被其他线程修改列表结构，可能引发 ConcurrentModificationException，间接影响结果一致性
如何验证一次 shuffle 是否真正随机
单次运行无法判断，需统计学验证。典型做法是：固定 seed，对小规模列表（如 4 元素）执行数万次 shuffle，统计全部 24 种排列的频次分布。
可用卡方检验（χ² test）判断是否服从均匀分布。若 p 值 > 0.05，可认为在显著性水平 5% 下未发现偏差。
工程中更实用的检查方式：
- 用 new Random(0) 或固定 seed 多次运行，确认输出完全一致（验证可重现性）
- 对同一列表连续 shuffle 两次，观察结果是否不同（排除意外缓存或空操作）
- 检查是否误用了 Arrays.asList(new int[]{…}) —— 这会返回 List
，而非预期的 List ，导致 shuffle 无效
保持公正性的推荐用法
不需要额外库或封装，标准写法已足够健壮：
- 优先使用重载版本：Collections.shuffle(list, new Random(seed))，尤其在测试、游戏关卡生成等需复现的场景
- 避免在多线程共享的 list 上并发调用 shuffle；如需并发安全，应在外层加锁，或改用 ThreadLocal<Random>
- 对 ArrayList 等实现 RandomAccess 的列表，性能与公正性兼得；对 LinkedList，确保数据量不大（JDK 阈值为 5），否则考虑先转 ArrayList 再 shuffle
- 不依赖 System.currentTimeMillis() 生成 seed；推荐用 SecureRandom 或 Long.hashCode() 混合时间与对象标识生成种子
