手写数字抽奖系统避坑指南 搞定随机算法不翻车 面对屏幕上那串红色的 StackTrace，是不是脑子直接宕机了？明明照着教程敲的代码，一运行就抛出 IndexOutOfBoundsException 或者 NullPointerException，看着满屏的英文报错却完全不知道从哪下手改。别慌，这种“代码能跑但结果不对”或者“直接崩溃”的情况，在实现【数字抽奖】功能时简直是家常便饭。今天这篇【避坑指南】不讲虚的，直接带你从零搭建一个真正生产级可用的抽奖模块，把那些藏在底层逻辑里的坑一次性填平。 项目目标：不只是随机，更是公平 很多新手对抽奖系统的理解还停留在 Math.random() 上，觉得生成个随机数就行。但在真实的业务场景中，比如电商大促、社区活跃活动，抽奖系统面临的是高并发、高频率的请求。如果算法设计不当，轻则导致某些用户永远抽不到奖（体验极差），重则被黑产利用漏洞批量刷奖（资损巨大）。 我们今天要构建的目标很明确：绝对公平：确保每个参与者中奖概率均等，不受顺序影响。 高性能：支持高并发场景下的快速响应，避免数据库压力过大。 防作弊：防止同一个账号重复提交，防止脚本刷单。 可追溯：每一次抽奖结果都要有日志记录，便于后续审计和客服查询。这不是一个简单的玩具代码，而是一个可以直接应用到生产环境的基础模块。对于刚入行的工程师来说，理解这套逻辑，比背八股文有用得多。 目录结构：清晰分层，各司其职 为了保证代码的可维护性，我们采用经典的 MVC 分层架构。虽然项目不大，但规范不能丢。以下是核心目录结构： lottery-system/ ├── src/ │ ├── main/ │ │ ├── java/com/example/lottery/ │ │ │ ├── controller/ │ │ │ │ └── LotteryController.java # 接口层，处理HTTP请求 │ │ │ ├── service/ │ │ │ │ ├── LotteryService.java # 业务逻辑层，核心算法 │ │ │ │ └── impl/ │ │ │ │ └── LotteryServiceImpl.java # 具体实现 │ │ │ ├── entity/ │ │ │ │ └── Prize.java # 奖品实体类 │ │ │ └── utils/ │ │ │ └── RandomUtil.java # 随机数工具类封装 │ │ └── resources/ │ │ └── application.yml # 配置文件 │ └── test/ │ └── java/com/example/lottery/ │ └── LotteryServiceTest.java # 单元测试，验证公平性 └── pom.xml这种结构的好处是，当我们需要更换随机算法（比如从 Random 换成 SecureRandom）时，只需要修改 RandomUtil 和 LotteryServiceImpl，完全不需要动 Controller 层的代码。这就是解耦的价值。 核心代码实现：逐行拆解避坑点 这是整篇文章的重头戏。我们将重点讲解 LotteryServiceImpl 中的核心抽奖逻辑。这里隐藏着新手最容易踩的三个坑：随机数偏差、并发安全问题、奖品库存扣减失败。 1. 奖品模型定义 首先定义一个奖品类，包含奖品ID、名称、权重（决定中奖概率）和剩余库存。 @Data public class Prize {private Long id;private String name;private int weight; // 权重，数值越大越容易中奖private int stock; // 剩余库存，0表示已抽完 }2. 核心抽奖算法：加权随机与库存校验 很多初学者喜欢用 random.nextInt(max) 然后取模，这在数学上是有偏差的，且无法处理“库存为0”的情况。我们采用累加权重法，这是 Stack Overflow 上关于加权随机数讨论中被公认最稳健的方案之一。 @Service public class LotteryServiceImpl implements LotteryService {// 假设奖品列表是从数据库加载到缓存中的，这里简化为静态变量演示private final ListPrize prizeList = new ArrayList();// 使用 AtomicInteger 保证并发下的库存扣减安全private final MapLong, AtomicInteger stockMap = new ConcurrentHashMap();/*** 执行抽奖* @param userId 用户ID* @return 中奖奖品，如果未中奖返回 null*/public Prize drawLottery(Long userId) {// 1. 前置校验：检查用户是否已经参与过（实际项目中需查 Redis 或 DB）if (isUserParticipated(userId)) {throw new BusinessException(您已参与过本次抽奖);}// 2. 计算总权重int totalWeight = 0;for (Prize prize : prizeList) {// 关键避坑点：只累加还有库存的奖品权重if (getStock(prize.getId()) 0) {totalWeight += prize.getWeight();}}// 如果所有奖品都没了，直接返回谢谢参与if (totalWeight == 0) {return null;}// 3. 生成随机数// 避坑点：不要使用 new Random()，在多线程下性能差且可能重复// 使用 ThreadLocalRandom 是 JDK 8 后推荐的高性能并发随机数生成器int randomNum = ThreadLocalRandom.current().nextInt(totalWeight);// 4. 遍历奖品，确定中奖者for (Prize prize : prizeList) {int currentWeight = prize.getWeight();// 如果该奖品没库存，跳过if (getStock(prize.getId()) = 0) {continue;}// 核心逻辑：如果随机数小于当前权重，则命中if (randomNum currentWeight) {// 5. 扣减库存（这里存在并发竞争，需原子操作）boolean success = decrementStock(prize.getId());if (success) {// 记录日志，便于追溯log.info(User {} won prize {}, userId, prize.getName());return prize;} else {// 库存扣减失败（并发下被其他线程抢走），需要重新抽奖或返回失败// 简化处理：直接返回 null，实际项目中可能需要重试机制log.warn(Stock deduction failed for prize {}, prize.getId());return null; }}// 未命中，减去当前权重，继续比较下一个奖品randomNum -= currentWeight;}// 理论上走不到这里，除非逻辑错误return null;}private boolean isUserParticipated(Long userId) {// 模拟检查，实际应查 Redis setreturn false; }private int getStock(Long prizeId) {AtomicInteger stock = stockMap.get(prizeId);return stock == null ? 0 : stock.get();}private boolean decrementStock(Long prizeId) {AtomicInteger stock = stockMap.get(prizeId);if (stock == null) return false;// CAS 操作，确保并发安全while (true) {int current = stock.get();if (current = 0) {return false; // 库存不足}if (stock.compareAndSet(current, current - 1)) {return true; // 扣减成功}// 如果 CAS 失败，说明被其他线程修改，重试}} }逐行讲解与避坑分析：ThreadLocalRandom 的使用： 很多老代码习惯用 new Random() 或全局共享的 Random 实例。在单线程下没问题，但在高并发下，共享 Random 会导致大量的线程竞争和锁等待，性能急剧下降。JDK 8 引入的 ThreadLocalRandom 为每个线程维护独立的随机数种子，无锁且高性能，是服务端开发的首选。ConcurrentHashMap 与 AtomicInteger： 直接对 int 类型做 stock-- 操作在并发下是极其危险的。两个线程可能同时读到 stock=1，然后都执行减一变成 0，导致超卖。使用 AtomicInteger 的 compareAndSet (CAS) 机制，可以确保只有在库存确实大于0且修改成功时才返回 true。这是解决并发超卖问题的基础手段。权重的动态累加： 注意我们在计算 totalWeight 时，跳过了库存为 0 的奖品。如果某个奖品抽完了，它的权重应该从总权重中剔除，否则用户会有概率“命中”一个已经没奖的区间，导致 randomNum 一直减到最后都没匹配到奖品，或者匹配到了但扣减失败。这种逻辑错误很难在测试中发现，因为它是概率性的。运行与测试：用数据说话 代码写完了，怎么证明它是公平的？光靠肉眼看不出来。我们需要写单元测试，模拟一万次抽奖，统计每个奖品的中奖次数，看是否与权重比例一致。 @Test public void testLotteryFairness() {// 初始化奖品：奖品A权重80，奖品B权重20，库存各10000Prize a = new Prize();a.setId(1L); a.setName(A); a.setWeight(80); a.setStock(10000);Prize b = new Prize();b.setId(2L); b.setName(B); b.setWeight(20); b.setStock(10000);// 初始化 Service 内部状态 (简化演示，实际需通过构造器注入)// 假设 stockMap 已初始化lotteryService.initStock(a, b); int countA = 0;int countB = 0;int totalAttempts = 100000; // 模拟10万次抽奖for (int i = 0; i totalAttempts; i++) {Prize result = lotteryService.drawLottery((long)i);if (result != null) {if (result.getId() == 1L) countA++;if (result.getId() == 2L) countB++;}}double ratioA = (double) countA / (countA + countB);double ratioB = (double) countB / (countA + countB);System.out.println(A 中奖比例: + ratioA);System.out.println(B 中奖比例: + ratioB);// 断言：误差应在 5% 以内assertTrue(Math.abs(ratioA - 0.8) 0.05);assertTrue(Math.abs(ratioB - 0.2) 0.05); }运行结果预期： A 中奖比例: 0.7985 B 中奖比例: 0.2015 如果测试结果偏差巨大（比如 A 只有 50%），说明你的随机算法或者权重累加逻辑有 Bug。这时候不要怀疑运气，要怀疑代码。在 Stack Overflow 的许多关于随机数分布的讨论中，最常见的错误就是 nextInt 的边界处理不当。 优化扩展：应对真实业务场景 基础版代码能跑，但离生产环境还有距离。以下是几个关键的优化方向：库存预热与异步扣减： 在代码中，我们每次抽奖都去查库存并扣减。在高并发下，stockMap 的锁竞争会变得严重。 优化方案：将库存预加载到 Redis 中。抽奖时先查 Redis 是否有库存，有则直接返回奖品信息，并发送一条 MQ 消息。消费者异步去数据库扣减库存。这样可以将数据库的压力完全隔离在异步链路中，前端响应速度提升 10 倍以上。防刷机制： 目前的 isUserParticipated 只是模拟。实际项目中，必须在 Redis 中使用 SETNX (Set if Not eXists) 命令来标记用户已参与。Key 设计为 lottery:user:{activityId}:{userId}，过期时间设为活动结束后。这是防止同一用户多次请求的标准做法。日志与监控： 不要只打 System.out。使用 SLF4J 记录关键路径。更重要的是，要监控“抽奖失败率”。如果因为库存扣减失败导致的 return null 比例突然升高，说明可能存在超卖风险或库存同步延迟，需要立即告警。安全随机数： 如果涉及大额现金奖品，建议将 ThreadLocalRandom 替换为 SecureRandom。虽然性能略低，但能抵抗针对线性同余生成器的预测攻击。小结 从零搭建一个【数字抽奖】系统，看似简单，实则是对并发控制、随机算法、业务逻辑闭环的一次综合考察。 回顾一下我们踩过的坑：随机数生成器：别用 new Random()，用 ThreadLocalRandom。 并发安全：库存扣减必须用 AtomicInteger 或 Redis 原子操作，严禁直接 --。 逻辑闭环：权重计算必须动态剔除无库存奖品，避免“空指针”式的逻辑死角。 验证：不要相信“看起来对”，要用大样本单元测试验证分布均匀性。编程不仅仅是写出能跑的代码，更是写出可靠、高效、可维护的代码。这套【避坑指南】里的每一个点，都是无数前人在生产环境中用事故换来的经验。 你在项目里踩过这个坑吗？或者你有更巧妙的随机算法实现？评论区聊聊，我们一起交流。