如何在 Java 中通过 Random.nextInt(bound) 生成 0 到指定上限的随机数

随机数生成在Ja va里是个老朋友了，几乎每个项目都会跟它打交道。这里头，Random.nextInt(bound)是最常用的一招，但偏偏不少人在这上面栽过跟头。今天这篇文章，不聊那些宏大的理论，就说几个实实在在的核心判断和常见陷阱。

Random.nextInt(bound) 的实际取值范围是 0 到 bound−1

一个常见的误解是，nextInt(10)能顺带生成10。其实不然，它的取值范围是从0（包括0）到bound-1（包括bound-1）。这不是什么bug，而是Ja va官方文档白纸黑字的规定——左闭右开。

实践中，这种误会导致的问题很典型：
• 想要0到10共11个数，老老实实写nextInt(10)，结果等了半天也等不到10的影子；
• 一时手快把bound设成0或者负数，程序直接抛给你一个IllegalArgumentException: bound must be positive。

牢记三条基本原则：
• bound必须是正整数，否则运行时直接报错；
• 要的是[0, n]这个闭区间，那就得用nextInt(n + 1)；
• 要生成[a, b]这个区间内的整数，公式就是random.nextInt(b - a + 1) + a，一个萝卜一个坑。

为什么不能直接用 nextInt() 配合乘法缩放来生成指定范围？

有人或许会想，能不能用(int)(Math.random() * bound)或者拿nextInt()自己手动缩放一下？逻辑上绕，还容易出岔子。nextInt(bound)内部早就用位运算和拒绝采样把均匀性安排得明明白白，无偏移、无溢出、无浮点误差，何必舍近求远。

手动缩放的问题很现实：
• Math.random()返回的是double，乘法一做，精度一丢，边界值要么不见了要么越界；
• nextInt()返回32位int，直接乘除溢出风险极大，比如nextInt() * bound / Integer.MAX_VALUE这种写法，安全系数几乎为零；
• 多了不必要的计算，性能自然打折扣，可读性也差点意思。

立即学习“Ja va免费学习笔记（深入）”；

所以，最佳方案始终只有一个：
• 坚持用nextInt(bound)，这是专门为这个场景优化的标准方法；
• 不必想着“绕过bound限制”——它本身就是接口契约，是保证，不是限制；
• 如果bound值很大，接近Integer.MAX_VALUE，内部会自动切换到安全的拒绝采样模式，完全不需要你操心。

多线程环境下要注意 Random 实例是否共享

Random类不是线程安全的，这一点常被忽视。多个线程抢着调用同一个Random实例的nextInt(bound)，轻则随机序列出现重复，重则状态错乱，虽然程序不一定立刻崩溃，但随机性已经被严重破坏。

典型踩坑场景：
• 把Random声明成Spring Bean的单例成员变量；
• 在工具类里搞一个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的初始化向量、一次性验证码的种子，这时候才该切换到SecureRandom；
• 千万别为了“显得更安全”而滥用SecureRandom，解决的是不同维度的问题。

说到底，真正容易被忽略的，不是那些光鲜的细节，而是bound参数的语义边界，以及它背后与线程模型的隐式耦合。写一次nextInt(10)很容易，但把它塞进一个被复用的工具方法里，再放到多线程上下文中调用时，问题才刚刚浮出水面。