Collections.shuffle() 基于 Fisher-Yates 算法，保证各排列等概率，时间复杂度 O(n)；需用 SecureRandom 提升安全性，避免手动抽号或多次 shuffle，并注意线程安全与 Android 兼容性。
collections.shuffle() 是 java 提供的、基于 fisher-yates（knuth）洗牌算法的标准实现，它能保证每个排列出现的概率完全相等，满足统计学意义上的公平性。只要使用得当，无需自行重写洗牌逻辑。
为什么 shuffle() 本身已具备统计公平性
该方法内部采用的是“原地随机交换”策略：从数组末尾开始，每次随机选取一个索引（含当前位）与当前位置交换。时间复杂度 O(n)，且数学上可证明——对长度为 n 的列表，共产生 n! 种等概率排列，无偏移、无重复偏好。
关键前提是：随机源必须是高质量的。默认使用 new Random()，其种子基于系统纳秒时间，适合一般业务场景；高安全或高并发抽奖可显式传入 SecureRandom 实例。
正确调用方式与常见误区
避免以下写法：
- 对原始集合做多次 shuffle 后取前 k 个 → 不增加公平性，反而可能因重复操作引入隐式 bias（如对象哈希冲突影响迭代顺序）
- 先用
Random.nextInt()手动抽号再去重 → 易导致概率倾斜（尤其在奖池小、中奖率高时），且效率低 - 对不可变集合（如
Arrays.asList()返回的固定大小列表）调用 shuffle → 可能抛UnsupportedOperationException
推荐写法：
List<Prize> prizes = new ArrayList<>(originalPrizes); // 确保可修改 Collections.shuffle(prizes, new SecureRandom()); // 显式指定安全随机源 List<Prize> winners = prizes.subList(0, Math.min(10, prizes.size()));
配合业务逻辑增强可审计性与可重现性
抽奖系统不仅要公平，还要可验证。建议：
- 记录每次 shuffle 使用的随机种子（若用
new Random(seed)），便于问题复现与第三方审计 - 不直接 shuffle 原始奖品池，而是 shuffle 奖品 ID 列表或索引数组，保持奖品对象状态分离
- 对同一组输入数据 + 同一 seed，shuffle 结果必须完全一致 —— 这是验证算法正确性的基本依据
注意边界情况下的行为一致性
空列表、单元素列表、含 null 元素的列表均被 shuffle() 正确支持，不会抛异常或改变语义。但需注意：
- 若奖品列表含重复对象（非重复 ID），shuffle 不会去重，业务层应提前校验唯一性
- 多线程环境下，不要共享同一个
Random实例（SecureRandom是线程安全的，普通Random不是） - Android 早期版本（API Collections.shuffle() 有轻微偏差，建议升级或自行封装 Fisher-Yates
