ThreadLocalRandom.current()比共享Random快5–10倍且无锁竞争，因其为每线程独享实例，避免CAS自旋争抢种子；误用static声明会退化为共享实例，失去线程隔离优势。
直接用 ThreadLocalRandom.current() 获取实例，比共享 Random 快 5–10 倍，且完全避免锁竞争。
为什么不能继续用 static Random
Random 的线程安全靠 AtomicLong + CAS 实现：每次 nextInt() 都要读种子、计算新种子、再用 CAS 更新——失败就自旋重试。线程一多，大量 CPU 时间耗在等待上，不是卡在业务逻辑，而是卡在“抢骰子”。电商秒杀场景中，一个全局 Random 就可能让接口响应时间翻倍。
- 所有线程共用同一个 seed 变量
- CAS 失败后不阻塞，而是空转重试（自旋），白占 CPU
- 线程数超过 4 个后，性能下降开始明显
ThreadLocalRandom 正确用法
它不需手动管理实例，也不该提前声明为 static 字段——这是常见误用，会导致所有线程共用初始化时的那个实例，失去线程隔离意义。
- 每次需要随机数时，调用 ThreadLocalRandom.current()，它会自动为当前线程初始化专属生成器
- 推荐使用带范围的 nextInt(origin, bound)，比如 nextInt(1, 101) 表示 [1, 100] 整数，语义清晰、无边界错误风险
- 避免写成 private static final ThreadLocalRandom RANDOM = ThreadLocalRandom.current(); —— 这样所有线程拿到的是同一个初始实例，等同于退化为 Random
适用场景与注意事项
ThreadLocalRandom 不是万能的，它适合高并发、低耦合的随机需求，比如发券码、抽奖、ID 偏移、测试数据生成等。但不适合需要强可重现性的场景（如游戏回放、算法调试），因为各线程种子独立，无法统一控制。
- 适合：短生命周期任务、线程池中大量并行计算、无状态服务
- 不适合：需要跨线程复现同一随机序列的场景（此时应传入固定 seed 构造 Random）
- 注意：它的种子由系统安全随机数初始化，不可外部设置；若需可控 seed，仍得用 Random 或 SecureRandom
简单对比代码示意
错例（看似省事，实则埋雷）：
private static final Random SHARED_RANDOM = new Random(); // 所有线程争抢这一个int n = SHARED_RANDOM.nextInt(100);
对例（推荐写法）：
int n = ThreadLocalRandom.current().nextInt(1, 101); // 每个线程玩自己的
