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