如何通过 Random 类生成指定范围内的随机整数

如何通过 Random 类生成指定范围内的随机整数

Ja va 中 Random.nextInt(int bound) 的正确用法

先说一个最核心的结论：Random.nextInt(n) 这个方法，生成的其实是 [0, n) 这个左闭右开区间内的整数。换句话说，它能取到0，但绝对取不到n。如果你需要的是包含两端点（比如 [min, max]）的整数，那就得自己手动做一下偏移和范围调整了。

新手最容易踩的坑，往往是写成 random.nextInt(max - min)，结果永远漏掉了最大值 max；或者忘了加上 min 这个偏移量，导致下界完全不对。

• 标准公式：要生成 [min, max]（包含两端）的随机整数，正确的写法是：random.nextInt(max - min + 1) + min。
• 这里的 max - min + 1 是关键，它代表了合法的取值总数，必须作为 bound 参数传进去。
• 如果粗心把 min 和 max 写反了，导致 min > max，程序会直接抛出 IllegalArgumentException。
• 还有一个隐蔽的陷阱：整数溢出。当 max 接近 Integer.MAX_VALUE 而 min 又是负数时，max - min + 1 这个计算本身就可能溢出。对于这种极端边界情况，更稳妥的做法是直接使用 ThreadLocalRandom.current().nextInt(min, max + 1)。

为什么不用 Math.random() 强转？

可能有人会想，Math.random() 返回的是 [0.0, 1.0) 的 double 值，用它乘以范围再强转成 int 不也一样吗？理论上可行，但实践中坑不少。

比如这个写法：(int)(Math.random() * (max - min + 1)) + min。由于 Math.random() 返回值严格小于1.0，乘以N之后最大值也严格小于N，所以强转int后确实能覆盖 [0, N) 的范围。看起来没问题，对吧？但魔鬼藏在细节里：

• 浮点误差：double 类型的乘法存在精度问题，有极小的概率因为舍入导致结果等于 N，强转后就会超出预期范围。
• 一致性风险：不同JVM实现或版本可能在细节处理上有差异，导致行为不一致。
• 性能开销：Math.random() 内部其实也使用了 Random 类，并且多了一层 synchronized 锁，在高频调用时会有不必要的性能损耗。

所以，除非是维护遗留代码，否则真的没必要绕这个远路。

多线程环境下优先用 ThreadLocalRandom

在高并发场景下，使用同一个 Random 实例会产生激烈的锁竞争，导致性能急剧下降。这时候，ThreadLocalRandom 就是你的最佳选择，它为每个线程维护了独立的随机数生成器，完全无锁。

用它来生成 [min, max] 区间的整数，语法上更加简洁直观：ThreadLocalRandom.current().nextInt(min, max + 1)。这里需要特别注意，它的第二个参数是独占的上界，所以我们必须传入 max + 1。

• 安全性更高：该方法内部已经处理了整数溢出的检查，比自己手动计算 max - min + 1 更安全。
• 使用方式固定：不能通过 new 来创建，必须通过静态方法 current() 获取当前线程的实例。
• 一个重要的限制：它不支持设置种子（seed），因此其随机序列是不可重现的。如果你的单元测试需要确定性的随机结果来进行断言，那么还是应该使用可以传入固定种子的 Random。

边界值测试容易忽略的细节

写单元测试时，只测一下 min 和 max 这两个边界值是远远不够的。真正容易出问题的，往往是那些“边界的边界”。

• 当 min == max：此时范围只有一个值，理应稳定返回该值。但如果错误地写成了 nextInt(max - min)，就会导致除零异常。
• 当范围覆盖整个int区间：比如 min == Integer.MIN_VALUE 且 max == Integer.MAX_VALUE。这时范围总数超过了 2^31，max - min 这个计算本身就会溢出。这种情况下，必须依赖 ThreadLocalRandom.nextInt(min, max + 1) 这类在内部使用 long 运算的方法来规避。
• 负数区间：例如生成 [-5, -1] 的随机数。很多人会误以为 nextInt(-1 + 5) - 5 能行，但实际上它生成的是 [-5, -1) 这个区间，永远漏掉了 -1 这个上界。

总之，在处理随机数范围时，边界情况永远比直觉更脆弱，尤其是在混合了整数溢出和开闭区间语义的时候。多花几分钟考虑这些边缘案例，能省下未来数小时的调试时间。