Random应复用单例避免重复创建导致种子冲突；nextInt(bound)生成[0,bound)，闭区间[a,b]需用a+nextInt(b-a+1)；多线程优先用ThreadLocalRandom；安全场景如token才用SecureRandom。
Random类的基本用法和常见误区
Java里用Random生成随机数，最常踩的坑是重复创建实例——每次new一个Random()，在高并发或短时间密集调用下，可能因种子相同导致返回相同序列。推荐复用单个实例，比如声明为static final。
默认构造器用系统时间纳秒做种子，但若两对象创建间隔小于纳秒（实际中极少见），仍可能撞种子；更稳妥的方式是用new Random(System.nanoTime() + Thread.currentThread().getId())微调，不过绝大多数场景直接复用一个实例就够了。
-
nextInt()返回int范围内的任意值（-2³¹ ~ 2³¹−1），不是0~n−1 -
nextInt(int bound)才返回[0, bound)之间的整数，
bound必须>0，否则抛
IllegalArgumentException -
nextDouble()返回[0.0, 1.0)的double，不包含1.0
生成指定范围整数的正确写法
要生成[a, b]闭区间内的随机整数（含a和b），不能直接用nextInt(b - a)，因为那得到的是[a, b)，还少一个b。正确公式是：a + random.nextInt(b - a + 1)。
注意边界检查：如果a > b，结果未定义；如果b − a + 1溢出（比如a=Intege.MAX_VALUE, b=Integer.MAX_VALUE），会抛异常。生产环境建议加校验。
public static int randomIntInRange(Random random, int min, int max) {
if (min > max) throw new IllegalArgumentException("min > max");
return min + random.nextInt(max - min + 1);
}线程安全问题：什么时候该用ThreadLocalRandom
多个线程共用同一个Random实例时，内部的seed更新是CAS操作，有竞争开销。JDK 7+提供了ThreadLocalRandom，它为每个线程维护独立实例，无锁且更快。
适用场景：多线程环境下只用于生成随机数，不需要设置种子或复现序列。它不支持自定义种子，也不能调用setSeed()。
- 获取实例用
ThreadLocalRandom.current()，不要new - 方法名基本一致：
nextInt(int bound)、nextLong(long bound)、nextDouble()等 - 在ForkJoinPool或CompletableFuture中尤其推荐使用
替代方案：SecureRandom适合哪些场景
SecureRandom是密码学强度的随机数生成器，适用于生成密钥、token、盐值等对不可预测性要求高的地方。但它比Random慢得多，初始化也可能阻塞（尤其在Linux上读/dev/random）。
日常业务逻辑（如抽奖、测试数据、排序打乱）完全没必要用SecureRandom；用了反而拖慢性能，还可能引发熵池耗尽告警。
- 想避免阻塞？可显式指定算法：
new SecureRandom(new byte[20], "SHA1PRNG") - 打乱List？用
Collections.shuffle(list, new SecureRandom())是过度设计，Random足够 - 生成JWT token中的nonce？这才轮到
SecureRandom
真正需要关注的，是别把Random当成“真随机”来用，也别在安全敏感路径上图省事漏掉SecureRandom。两者定位不同，混用容易出问题。
