Java随机数生成全攻略：从基础API到高并发场景的实战案例解析
目录导读
- Java随机数的基础三件套：
Math.random()、Random类、ThreadLocalRandom的对比与选型 - 真实业务案例：验证码生成、抽奖权重分配、分布式ID中的随机数陷阱
- 高并发下的性能与安全：
SecureRandom的密码学强度与ThreadLocalRandom的线程隔离 - 常见问答（FAQ）：针对随机数种子、重复率、性能的深度解答
- 踩坑清单：
new Random()每次创建、nextInt(n)的偏斜问题
基础随机数API：别再用错工具了
很多Java开发者写随机数时,第一反应是Math.random()，它内部其实是通过java.util.Random的nextDouble()实现的，但返回值是double类型（0.0到1.0之间），无法直接生成整数，如果需要随机整数，必须做乘法与类型转换，代码既不直观，性能也差（因为每次调用都生成一个Random实例）。
更优选择是java.util.Random，它提供了nextInt()、nextLong()、nextBoolean()等丰富方法，但请注意，Random是线程安全的（使用了CAS），不过这在高并发下会导致自旋锁竞争，性能大打折扣，而ThreadLocalRandom（JDK 7+）完美解决了这个问题，每个线程维护一个独立的Random实例，通过ThreadLocal隔离，无锁竞争，吞吐量提升一个数量级。
选型结论：
- 单线程或简单场景 → 用
Random - 多线程并发（如Web服务） → 必须用
ThreadLocalRandom.current().nextInt() - 密码学安全需求（如令牌、盐值） → 必须用
SecureRandom
实战案例：从需求到代码的完整演绎
图形验证码生成（安全与性能的平衡）
通常验证码由4-6位数字或字母组成，如果使用Random，在高并发登录接口下会成为瓶颈，正确做法是使用ThreadLocalRandom，并且定义静态字符池，避免频繁创建字符数组。
public static String generateCaptcha(int length) {
String chars = "ABCDEFGHJKLMNPQRSTUVWXYZ23456789"; // 去掉易混淆的0/O/1/I
StringBuilder sb = new StringBuilder();
for (int i = 0; i < length; i++) {
int idx = ThreadLocalRandom.current().nextInt(chars.length());
sb.append(chars.charAt(idx));
}
return sb.toString();
}
抽奖活动权重分配
需求是：A奖品概率10%，B奖品20%，C奖品70%，初学者容易犯的错是nextInt(10)判断，但若概率不是整数百分比就会很麻烦，标准解法是“区间映射法”。
public static String lottery() {
double rand = ThreadLocalRandom.current().nextDouble(); // [0.0, 1.0)
if (rand < 0.1) return "A";
else if (rand < 0.3) return "B"; // 0.1+0.2
else return "C";
}
分布式ID中的随机数陷阱
生成唯一订单号，有人会用System.currentTimeMillis() + random.nextInt(1000)，这在单机尚可，但在集群中很可能碰撞，更合理的做法是用随机数辅以原子计数器或时间戳高位，或者用雪花算法（Snowflake）替代，随机数只作为最后一位的噪声。
高并发与安全：不能忽视的两个进阶点
（一）性能对比数据
在8核CPU、100线程并发下循环生成10万次随机数：
Random：耗时约850ms（CAS竞争激烈）ThreadLocalRandom：耗时约120ms（性能提升7倍）SecureRandom：耗时约2000ms（但它是阻塞式，基于熵池）
（二）为什么用SecureRandom？
当你的随机数用于生成会话ID、密码盐、支付令牌时，使用Random是致命的，因为Random是线性同余算法（LCG），攻击者只要获取连续两个随机数，就能反推出种子，进而预测后续所有随机数，而SecureRandom提供密码学安全伪随机数生成器（CSPRNG），内部依赖操作系统熵源（如/dev/urandom），不可预测。
最佳实践：不要每次调用new SecureRandom()，而是将其作为静态常量复用，因为创建会触发熵池收集，开销极大。
问答环节（FAQ）
Q1：为什么我用Random生成的随机数序列总是重复？
A：因为Random是伪随机数，它由一个种子（seed）通过数学公式推导，如果种子相同，生成的序列就完全一样，默认种子取自当前纳秒时间，如果两个Random实例在极短时间（同一纳秒）内创建，可能得到相同种子。解决方案：在循环外创建单个实例，或使用ThreadLocalRandom自动处理。
Q2：nextInt(n)会分配不均匀吗？
A：经典问题！JDK的nextInt(int bound)内部通过(next(31) % bound)实现（早期版本），会产生模偏差（Modulo Bias），当bound不是2的幂时，低位数概率略高，Java 8+已修复为rejection sampling算法，但如果你用Math.abs(random.nextInt()) % n就仍有偏差，务必直接使用random.nextInt(n)。
Q3：如何生成指定范围内的随机数（如[50, 100]）？
A：统一公式：int result = ThreadLocalRandom.current().nextInt(50, 101);，注意nextInt(origin, bound)是左闭右开，所以目标是100时要传101。
Q4：高并发下用Math.random()有问题吗？
A：问题很大，它内部持有一个Random实例，底层是synchronized方法，在高并发下相当于串行化操作，会拖垮整个接口。
踩坑清单：这些错误你中过几个？
- 在方法内部
new Random()：每次调用都重新初始化种子，生成效率低下，且易重复。 - 使用
Random做安全令牌：迟早会被脱库攻击。 - 未复用
ThreadLocalRandom：ThreadLocalRandom.current()每次调用都要做线程本地查找，应赋值给局部变量。 - 忽略种子设置：测试环境需要固定随机数时，不考虑用带种子的
new Random(42)来复现问题。 - 随机数做哈希分布：用
hashCode()取余代替nextInt，极端情况下哈希冲突会导致数据倾斜。
Java随机数虽小,却是一面多棱镜，折射出性能、并发、安全与设计哲学，从API选型到实战案例，再到高并发下的性能调优，每一步都藏着经验之谈，希望这篇拆解文能帮你彻底告别“随机数只会用Math.random()”的尴尬，在面试或项目评审时，能自信地讲出每种随机数的适用边界。没有最好的随机数，只有最合适的场景。 下次写代码前，先问自己一句：我的随机数需要安全吗？需要扛住每秒万次并发吗？想清楚，再动手。
