Java随机抽奖核心是避免重复中奖、保证公平性与高并发安全；应使用ThreadLocalRandom替代Random/Math.random()，配合“随机索引+末尾交换”移除中奖者，高安全场景用SecureRandom，并需完善业务校验与幂等控制。
Java 里实现随机抽奖系统，核心不是“怎么生成随机数”，而是“怎么避免重复中奖、保证公平性、支持高并发抽离逻辑”。直接用 Math.random() 或 Random 类容易翻车——比如重复抽取、线程不安全、种子被重置导致可预测。
用 ThreadLocalRandom 替代 Random 防止并发冲突
多线程环境下（比如 Web 接口批量抽奖），共享一个 Random 实例会导致竞争和序列可预测；Math.random() 内部也用的是共享的 Random 实例。
正确做法是使用线程隔离的 ThreadLocalRandom，它在每个线程内独立初始化，无锁、高效、不可预测：
import java.util.concurrent.ThreadLocalRandom; <p>// 安全获取 [1, 100] 区间内的随机整数 int luckyNumber = ThreadLocalRandom.current().nextInt(1, 101);
-
ThreadLocalRandom.current()每次调用都返回当前线程专属实例，无需手动管理 - 不要缓存
ThreadLocalRandom实例（比如设为 static 字段），它本就是线程绑定的 - 不支持设置自定义 seed —— 这反而是优点：避免人为干预随机性
抽中后立即移除，避免重复中奖（List + 随机索引交换）
如果奖池是固定名单（如员工 ID 列表），最常见错误是“随机取一个再 list.remove()”，这会引发 ConcurrentModificationException（遍历时修改）或性能问题（ArrayList 删除中间元素要移动后续元素）。
立即学习“Java免费学习笔记（深入）”；
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
推荐“随机索引 + 末尾交换”法，O(1) 时间完成一次抽取且不破坏原结构：
List<String> participants = new ArrayList<>(Arrays.asList("张三", "李四", "王五", "赵六"));
ThreadLocalRandom r = ThreadLocalRandom.current();
<p>if (!participants.isEmpty()) {
int i = r.nextInt(participants.size());
String winner = participants.get(i);
// 把最后一个元素移到位置 i，再删末尾
Collections.swap(participants, i, participants.size() - 1);
participants.remove(participants.size() - 1);
System.out.println("中奖者：" + winner);
}- 全程不遍历、不查找、不扩容，适合几千人以内的实时抽奖
- 如果需保留原始名单，先
new ArrayList(original)做副本 - 不要用
Stream.findAny()或skip().findFirst()模拟随机 —— 效率低且不真正随机
用 SecureRandom 应对安全性要求高的场景
普通抽奖用 ThreadLocalRandom 足够；但如果涉及奖金发放、链上抽奖、防作弊审计等场景，JVM 默认的伪随机算法（如 LCG）可能被逆向推测后续结果。
此时必须升级为密码学强度的 SecureRandom：
import java.security.SecureRandom; <p>SecureRandom secure = new SecureRandom(); // 自动选用 OS 提供的熵源（/dev/urandom 等） int ticketId = secure.nextInt(1_000_000);
-
SecureRandom初始化稍慢（要收集足够熵），但一旦创建，性能与Random相当 - 避免显式传入 seed（如
new SecureRandom(byte[])），除非你控制熵源且理解风险 - Spring Boot 项目中可通过
@Bean注册单例SecureRandom，复用而非每次 new
真正难的不是“怎么随机”，而是怎么把随机嵌进业务流里：是否允许同一用户多次参与？中奖资格是否需前置校验（如实名、充值）？落库时要不要加唯一约束防止重复发奖？这些逻辑一旦漏掉，再“随机”的代码也救不了业务漏洞。
