Random.nextInt() 的范围陷阱在于 max - min 可能溢出为负数，导致 IllegalArgumentException；正确做法是确保 bound 为正，再平移：nextInt(max - min + 1) + min。
Random.nextInt() 的范围陷阱
直接写 Random.nextInt(max - min) + min 看似合理，但只在 min >= 0 且 max > min 时安全；一旦 min 是负数，max - min 可能溢出成负数，触发 IllegalArgumentException: bound must be positive。
- 错误现象：
new Random().nextInt(-10)直接抛出异常，不是返回负值 - 根本原因：
nextInt(int bound)要求bound必须为正整数，它生成的是[0, bound)区间整数，不支持负上界 - 所以
max - min不能只是“数学差”，必须确保结果是正的、可表示的int
安全生成 [min, max] 闭区间的正确写法
Java 没有内置的「闭区间随机整数」方法，得自己兜底。最稳妥的方式是用 nextInt(int bound) 生成长度，再平移起点：
- 先确认
min ，否则逻辑无意义 - 计算区间长度：用
(long) max - min + 1L避免 int 溢出（比如min = Integer.MIN_VALUE,max = 0） - 转成
int前必须检查是否超出Integer.MAX_VALUE，否则强转会静默截断 - 最终表达式：
random.nextInt((int) (max - min + 1)) + min—— 仅当max - min + 1 时成立
示例（安全）：int x = rand.nextInt(10 - 3 + 1) + 3; → [3, 10]
为什么不用 Math.random()？
Math.random() 返回 double，看似能绕过 bound 正数限制，但隐患更隐蔽：
立即学习“Java免费学习笔记（深入）”；
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 精度丢失：
(int)(Math.random() * (max - min + 1)) + min在大数值时因 double 表示有限，某些整数概率为 0 - 范围偏差：
Math.random()是[0.0, 1.0)，乘法后最大值略小于max - min + 1，导致max实际命中率偏低（尤其当区间长度接近2^53） - 性能稍差：double 运算 + 类型转换比纯 int 更重，虽微小但确定
除非你明确需要 double 中间态，否则没理由弃用 Random.nextInt()。
ThreadLocalRandom 在并发场景下的必要性
多线程下共享一个 Random 实例会因 CAS 竞争拖慢性能，甚至引发意外的序列相关性；而 ThreadLocalRandom 是专为此设计的替代方案：
- 获取方式：用
ThreadLocalRandom.current().nextInt(min, max + 1)—— 注意它原生支持闭-开区间，参数含义和Random.nextInt(bound)不同 - 关键区别：
ThreadLocalRandom.nextInt(int origin, int bound)要求origin ，且自动处理溢出检查，比手写更可靠 - 不推荐混用：
new Random()和ThreadLocalRandom状态无关，别试图用前者种子初始化后者
简单说：只要你在多线程里生成随机数，就该用 ThreadLocalRandom.current().nextInt(min, max + 1)，而不是 new 一个 Random。
边界值组合（比如 min = Integer.MIN_VALUE, max = Integer.MAX_VALUE）会让几乎所有常见写法失效，这时候必须用 ThreadLocalRandom 或手动拆解 long 运算——但那种需求本身就很罕见，多数人卡在 min 为负时的溢出上就停住了。
