random.nextint(bound)取值范围是[0, bound−1)，非[0, bound]；bound必须为正整数，否则抛illegalargumentexception；生成[a,b]需用nextint(b−a+1)+a；应优先使用threadlocalrandom.current().nextint(bound)避免线程安全问题。
Random.nextInt(bound) 的实际取值范围是 0 到 bound−1
很多人误以为 nextInt(10) 会生成 0–10（含 10）的整数，其实它返回的是 0（含）到 bound（不含） 的均匀分布整数。这是 Java 文档明确规定的语义，不是 bug，而是设计如此。
常见错误现象：
• 用 nextInt(10) 想得到 0–10 共 11 个数，结果永远得不到 10；
• 把 bound 设成 0 或负数，直接抛出 IllegalArgumentException: bound must be positive。
-
bound必须为正整数，否则运行时报错 - 若要生成 [0, n]（含两端）的整数，应调用
nextInt(n + 1) - 若要生成 [a, b]（含 a 和 b）的整数，用
random.nextInt(b - a + 1) + a
为什么不能直接用 nextInt() 配合乘法缩放来生成指定范围？
有人尝试写 (int)(Math.random() * bound) 或用 nextInt() 手动缩放，这在逻辑上容易出错且不必要。Java 的 nextInt(bound) 已经做了无偏移、无溢出、无浮点误差的整数裁剪，内部使用位运算和拒绝采样确保均匀性。
手动缩放的问题包括：
• Math.random() 返回 double，乘法可能因精度丢失导致边界值缺失或越界；
• nextInt() 返回 int（32 位），直接乘除易溢出，比如 nextInt() * bound / Integer.MAX_VALUE 不安全；
• 多余计算，性能略差，还破坏可读性。
- 坚持用
nextInt(bound)，它是专为此场景优化的标准方法 - 不要试图“绕过 bound 限制”——它本身就是接口契约，不是限制而是保证
- 如果 bound 很大（接近
Integer.MAX_VALUE），nextInt(bound)内部会自动降级为安全的拒绝采样，无需你干预
多线程环境下要注意 Random 实例是否共享
Random 类不是线程安全的。如果多个线程共用同一个 Random 实例并频繁调用 nextInt(bound)，可能出现重复序列或状态错乱（虽然不常崩溃，但随机性被破坏）。
典型错误场景：
• Spring Bean 中将 Random 声明为单例成员变量；
• 工具类里用 static Random 字段供全系统调用。
- 推荐使用
ThreadLocalRandom.current().nextInt(bound)替代共享Random实例 - 如果必须用
Random，每个线程应持有独立实例，或用new Random(seed)显式隔离 -
ThreadLocalRandom不仅线程安全，而且比普通Random更快，尤其在高并发下
从 Random 切换到 SecureRandom 的代价与时机
如果你需要密码学强度的随机数（例如生成 token、密钥、盐值），Random.nextInt(bound) 绝对不合适——它的输出可预测，SecureRandom 才是正确选择。
但代价明显：
• 初始化慢（尤其首次调用，需采集熵）；
• 吞吐量低（比 Random 慢 10–100 倍）；
• 在某些容器环境（如无硬件熵源的 Docker）可能阻塞。
- 业务逻辑中生成 ID、分页偏移、测试数据等，用
Random或ThreadLocalRandom完全够用 - 只有涉及安全边界的场景（如 JWT 签名盐、AES IV、一次性验证码种子），才应切换到
SecureRandom - 切勿为了“显得更安全”而滥用
SecureRandom，它解决的是不同维度的问题
真正容易被忽略的是：bound 参数的语义边界和线程模型的隐式耦合。写一次 nextInt(10) 很简单，但把它放在一个被复用的工具方法里、又在多线程上下文中调用时，问题才开始浮现。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
