Random 多线程下变慢因 seed 竞争导致 CAS 自旋耗 CPU；ThreadLocalRandom 必须每次调用 current()，不可 static 缓存；高频场景应提取为局部变量；推荐用 nextInt(origin, bound) 明确范围。
为什么 Random 在多线程下会变慢
因为 Random 的 nextInt() 内部靠 AtomicLong.compareAndSet() 更新种子，多个线程抢同一个 seed 时，失败线程只能自旋重试——不是等锁，是空转耗 CPU。线程数一过 4 个，响应时间就明显拉长；秒杀场景下，一个共享 Random 实例可能让接口 P99 延迟翻倍。
ThreadLocalRandom.current() 必须每次调用，不能 static 缓存
常见误用：private static final ThreadLocalRandom RANDOM = ThreadLocalRandom.current(); —— 这会让所有线程共用初始化那一刻的单个实例，彻底失去线程隔离意义，等同于退化回 Random。
- 正确做法：每次需要随机数时，直接写
ThreadLocalRandom.current().nextInt(1, 101) - 如果在循环或高频路径里，可把
ThreadLocalRandom.current()提前赋给局部变量（非 static），例如：ThreadLocalRandom r = ThreadLocalRandom.current();，再反复调用r.nextInt(...) - 不要在类加载期、静态块或 Spring Bean 初始化时缓存
current()结果
范围参数别漏掉 origin，优先用 nextInt(origin, bound)
nextInt(int bound) 只能生成 [0, bound)，而 nextInt(1, 101) 明确表达 [1, 100]，避免手算偏移出错，也绕开 bound 的运行时异常。
- 错误写法：
random.nextInt(100) + 1—— 多一次加法，语义模糊，且边界易错 - 正确写法：
ThreadLocalRandom.current().nextInt(1, 101) - 注意：
bound必须大于origin，否则抛IllegalArgumentException
它不适合需要复现随机序列的场景
ThreadLocalRandom 的种子由系统安全随机数初始化，不可外部设置。如果你要调试算法、回放游戏逻辑、或做确定性测试，必须用 new Random(seed) 或 new SecureRandom(seed)。
- 适合它的地方：发券码、抽奖、ID 偏移、压测数据生成——只要求“够随机”，不要求“可重现”
- 不适合的地方：跨线程协同生成同一随机流（比如分布式一致性哈希种子）、算法单元测试中依赖固定输出
- 关键点：它的高性能来自“每个线程玩自己的骰子”，但这也意味着你永远没法在另一个线程里“摇出同样的数字序列”
最容易被忽略的是：你以为用了 ThreadLocalRandom 就万事大吉，结果在工具类里把它 static 化了——那不是优化，是给自己埋了个高并发雷。
