random.nextint(bound)生成[0, bound)左闭右开区间，需+1得[0,n]或[1,n]；多线程宜用threadlocalrandom；大bound时存在轻微分布偏差，密码学场景应选securerandom。
Random.nextInt(bound) 生成的是 [0, bound) 区间，不是 [0, bound]
很多人写 new Random().nextInt(10) 想要“0 到 10 之间的随机数”，结果发现永远得不到 10。这是因为 nextInt(bound) 的定义就是返回一个 **大于等于 0、小于 bound 的 int** —— 数学上叫左闭右开区间 [0, bound)。
常见错误现象：
- 用 nextInt(10) 后 +1 得到 1~10，但没考虑 bound=0 时抛 IllegalArgumentException
- 在需要包含上界（比如数组索引取 length）时直接传入 array.length，结果下标越界
- 如果要生成 [0, N]（含 N），得用
nextInt(N + 1) - 如果要生成 [1, N]（含 1 和 N），用
nextInt(N) + 1 - bound 必须 > 0，否则运行时抛
IllegalArgumentException: bound must be positive
多线程环境下 new Random() 不是最佳选择
每次调用 new Random() 都会基于当前时间戳初始化种子，高并发下容易产生重复序列 —— 尤其在毫秒级内大量创建实例时。这不是 bug，是设计使然。
使用场景：
- 单次工具脚本、单元测试里临时用一下，没问题
- Web 请求中每个请求都 new Random()，可能撞种子，导致不同请求拿到相同随机数
- 推荐复用一个
Random实例，比如声明为static final Random RANDOM = new Random(); - Java 7+ 更推荐用
ThreadLocalRandom.current().nextInt(bound)，它专为多线程优化，无竞争、无同步开销 -
ThreadLocalRandom不能指定种子，也不支持setSeed()，所以需要可重现序列的场景（如游戏存档）仍得用Random
nextInt(bound) 的 bound 接近 Integer.MAX_VALUE 时有偏差
当 bound 很大（比如 > 2^30），nextInt(bound) 内部用的是拒绝采样法：先生成完整 int 范围的随机值，再模 bound。但由于 2^32 不能被所有 bound 整除，某些余数出现概率略高 —— 理论上存在轻微分布偏差。
性能 / 兼容性影响：
- 对绝大多数业务逻辑（抽奖、ID 偏移、测试数据）完全可忽略
- 密码学、蒙特卡洛模拟等对均匀性敏感的场景，不能用 Random，应换 SecureRandom
- 若真需大范围且均匀，可用
ThreadLocalRandom.current().nextInt(0, bound)（Java 8+），它内部做了优化，比老式nextInt(bound)更公平 -
SecureRandom.nextInt(bound)也能用，但性能差一个数量级，别滥用
替代方案：为什么现在更常看到 ThreadLocalRandom 或 Random.ints()
Random.ints() 是 Java 8 引入的流式接口，适合批量生成；ThreadLocalRandom 是为并发而生。它们不是“取代”，而是各司其职。
立即学习“Java免费学习笔记（深入）”；
参数差异：
- Random.nextInt(bound) 返回单个 int
- ThreadLocalRandom.current().nextInt(bound) 行为一致，但线程安全
- new Random().ints(100, 0, 10).toArray() 生成 100 个 [0,10) 的 int 流
- 不要为了“新”而改，已有
Random实例且线程安全可控，没必要动 - Spring Boot 项目里，直接注入
@Bean Random random() { return new Random(); }是常见且合理的做法 - 注意
Random.ints()默认是无限流，必须用limit(n)或指定范围参数，否则终端不终止
事情说清了就结束。边界判断、线程模型、分布质量这三点，漏掉任何一个都可能让“随机”变成“似曾相识”。
