ThreadLocalRandom能避免CAS自旋，因其种子存于线程私有字段而非全局AtomicLong，各线程独享、零竞争；误用静态引用会退化为共享实例，失去性能优势。
ThreadLocalRandom 为什么能避免 Random 的 CAS 自旋
因为 Random 内部靠一个全局 seed 字段 + AtomicLong.compareAndSet 更新，高并发下多个线程反复 CAS 失败会空转；而 ThreadLocalRandom 每个线程持有一份独立种子（存在线程本地的 threadLocalRandomSeed 字段里），完全不争抢，连 volatile 读都省了。
注意：ThreadLocalRandom 不是 ThreadLocal 的简单封装——它压根没用 ThreadLocal 类，而是直接侵入 Thread 类加了三个 long 类型的私有字段（threadLocalRandomSeed、threadLocalRandomProbe、threadLocalRandomSecondarySeed），靠 Unsafe 直接操作，所以初始化和访问都更轻量。
必须显式调用 current() 才能获得线程专属实例
不能像 new Random() 那样直接构造，也不能复用静态引用——ThreadLocalRandom 的构造函数是 private 的，且每次调用 ThreadLocalRandom.current() 都会检查并惰性初始化当前线程的种子。如果跳过这步直接调静态方法（比如 ThreadLocalRandom.nextInt()），底层仍会先触发 current()。
- ✅ 正确：直接用静态方法，如
ThreadLocalRandom.current().nextInt(100)或更简洁的ThreadLocalRandom.nextInt(100)（它内部自动调current()） - ❌ 错误：缓存
ThreadLocalRandom实例到静态变量，如private static final ThreadLocalRandom R = ThreadLocalRandom.current();—— 这会让所有线程共享同一个实例，退化回竞争模式 - ⚠️ 注意：在 ForkJoinPool 的 worker 线程中，首次调用
current()可能触发 probe 值生成，有微小开销，但只发生一次
nextXXX 方法行为与 Random 几乎一致，但不支持 setSeed
ThreadLocalRandom 是只读种子的：没有 setSeed(long) 方法，也不允许外部干预种子状态。这是设计使然——既然每个线程自己管自己的种子，重置就失去了意义，而且会破坏线程隔离性。
如果你依赖 Random.setSeed() 实现可重现的随机序列（比如测试或仿真），ThreadLocalRandom 不适用；此时应为每个线程单独 new 一个 Random 并传入固定 seed，而不是共享一个 Random 实例。
- 相同点：参数范围、边界行为（如
nextInt(bound)返回[0, bound)）、算法（都是 LCG 变种） - 差异点：
ThreadLocalRandom.nextGaussian()是线程安全的，而Random.nextGaussian()内部用到了共享的临时变量nextNextGaussian，需同步 - 性能提示：
ThreadLocalRandom.nextInt()比Random.nextInt()快 3–5 倍（JMH 测得，Contended 场景下差距更大）
在哪些场景下 ThreadLocalRandom 反而更慢或不适用
不是所有“用 Random 的地方”都能无脑替换。真实压测中发现几个典型反模式：
- 短生命周期线程（如每次 HTTP 请求起一个新线程）：线程还没来得及复用
ThreadLocalRandom的种子状态就结束了，初始化开销占比上升 - 频繁调用
current()却只用一两次 next 方法：不如直接 new 一个Random（对象分配成本低于 Unsafe 字段写入+probe 计算） - 需要跨线程复现同一随机流：比如 A 线程生成 ID，B 线程要校验——此时必须用同一个确定性
Random实例，且显式 setSeed - Android API 21 以下不支持：
ThreadLocalRandom是 Java 7 引入的，旧 Android runtime 可能缺失部分 Unsafe 支持
真正关键的不是“用了 ThreadLocalRandom”，而是确认你的随机数生成逻辑确实落在高竞争路径上——比如连接池分配、限流令牌生成、分布式 ID 中的扰动位。这些地方才值得换；日志采样、调试开关这种低频操作，差异几乎不可测。
