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