用 math.random() 做权重抽奖总抽不到低概率奖品,因其返回 [0,1) 导致最后一区间长度缺失;正确做法是预计算前缀和,用 math.random() * totalweight 后二分查找。

用 Math.random() 做权重抽奖,为什么总抽不到低概率奖品?
因为直接乘权重再取整会破坏概率分布——比如权重 [1, 9],你生成 0~1 的随机数,乘以 10 得到 0~9 整数,再按区间映射,看似合理,但 Math.random() 返回的是 [0, 1) 开闭区间,0 可能被包含而 1 永远不出现,导致最后一个区间实际长度少了一丁点。
正确做法是预计算前缀和,用 Math.random() * totalWeight 得到一个浮点目标值,再二分查找它落在哪个区间:
double r = Math.random() * totalWeight; int idx = 0; for (int i = 0; i
- 必须用
prefixSum[i-1] 逻辑(或等价的「首次大于」),不能写成 <code> - 前缀和数组
prefixSum长度应与奖品数一致,prefixSum[0] == weight[0],不是从 0 开始累积 - 如果奖品数多(>1000),建议改用
Arrays.binarySearch(),避免线性扫描
Spring Boot 项目里怎么把权重配置从代码里抽出来?
硬编码权重等于锁死业务规则。推荐用 @ConfigurationProperties 绑定 YAML 列表,但要注意字段类型和结构匹配:
lottery:
prizes:
- id: "iphone"
weight: 5
- id: "coupon_5"
weight: 80
- id: "thanks"
weight: 15
对应 Java 类字段必须是 List<prizeconfig></prizeconfig>,且 PrizeConfig 中 weight 用 int 或 long,别用 Integer(否则空值报错)。
- YAML 中数字不要加引号,
weight: "5"会导致类型转换失败,抛出Failed to bind properties - 启动时校验总权重是否 > 0,可在
@PostConstruct里加断言,避免上线后抽不到任何奖 - 如果运营要动态调权,别 reload YAML,改用 Spring Cloud Config +
@RefreshScope,但注意RefreshScope不支持静态内部类绑定
并发抽奖时,Random 和 ThreadLocalRandom 怎么选?
用 new Random() 是最常见错误——每次新建实例会复用系统时间做 seed,高并发下大量实例几乎同时创建,seed 相同,导致随机序列重复。
你接手一个需求时,是不是经常这样:"改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续";这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境(JDK、Spring Boot、ORM、数据库、前端框架),记在
ThreadLocalRandom.current().nextDouble() 是唯一安全选择,它为每个线程维护独立种子,无锁且比 Random 快。
- 千万别在循环里反复调用
ThreadLocalRandom.current(),虽然不报错,但没必要;存一次引用即可 - 如果用了 Redis 分布式锁控制抽奖入口,仍需在锁内用
ThreadLocalRandom,因为锁只保原子性,不保随机性 - 测试时若想复现某次中奖结果,可临时换成
new Random(12345L)固定 seed,但上线必须删掉
MySQL 存奖品配置,查权重时 COUNT(*) 为什么越来越慢?
当奖品配置表只有几十行时,SELECT * 没问题;但一旦加了运营后台允许增删奖品,表变大、加了索引、甚至分库分表后,每次抽奖都查库就成瓶颈。
权重数据本质是低频更新、高频读取的元信息,应该加载进 JVM 内存,用 ConcurrentHashMap 缓存,并监听配置变更事件刷新。
- 缓存 key 推荐用
"prize:config:version"+ 版本号,而不是直接缓存整个列表,便于灰度发布 - 数据库加
updated_at字段,应用启动时查最大版本,之后定时轮询(如每 30 秒)该字段变化,避免长连接监听的复杂性 - 如果用 MyBatis,别在
@Select方法上加@CacheNamespace,它的默认 LRU 清理策略可能误删正在用的权重数据
权重逻辑看着简单,真正卡住人的永远不是算法,而是边界:浮点精度、并发安全、配置热更、缓存一致性——这些地方一漏,中奖率就悄悄偏移,而且很难监控到。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










