ThreadLocalRandom 明显快于 Random，因其为每个线程维护独立种子，避免 CAS 竞争与伪共享；Random 依赖 AtomicLong+CAS 更新共享种子，高并发时自旋重试导致性能骤降。
多线程环境下，ThreadLocalRandom 明显快于 Random，核心原因在于它彻底消除了线程间对共享种子的竞争。Random 虽线程安全，但靠 AtomicLong + CAS 更新种子，在高并发时大量线程自旋重试，性能急剧下降；而 ThreadLocalRandom 为每个线程维护独立种子和状态，无锁、无争用。
为什么 Random 在多线程下变慢
Random 的 next() 方法内部使用 CAS 循环更新种子：
- 多个线程同时调用时，只有一个能成功更新 seed，其余必须重试
- CPU 缓存行频繁失效（伪共享），尤其在多核机器上更明显
- 实测显示：200 线程共享一个 Random 实例，吞吐量可能比单线程还低
- Spring 或 Tomcat 中若将
new Random()声明为 Bean 字段，等同于全局共享，立刻触发锁竞争
ThreadLocalRandom 快在哪
它不依赖共享变量，而是复用 Thread 对象内置的三个字段：
-
threadLocalRandomSeed：线程专属种子 -
threadLocalRandomProbe：探针值，用于哈希定位 -
threadLocalRandomSecondarySeed：辅助种子，增强随机性 - 三者均加了
@Contended("tlr")注解，避免伪共享，提升缓存效率 - 调用
current()仅做一次线程局部查找，开销极小
怎么选才合适
不能简单说“ThreadLocalRandom 更好”，要按场景判断：
- 高并发服务（如 Web 请求、ForkJoinTask、CompletableFuture）→ 用
ThreadLocalRandom.current() - 需要可重现结果（单元测试、游戏存档、确定性分片）→ 只能用
Random，因它支持setSeed() - 单线程反复调用 → 复用一个
Random实例比频繁调用current()更快 - 安全性要求高（如生成令牌、密钥）→ 应用
SecureRandom，而非两者任一
常见误用与纠正
这些写法看似合理，实则埋雷：
- ❌
new Random()放在循环或 Runnable 内部 → 高并发下易得相同种子，输出重复序列 - ❌ Spring Bean 中
private final Random random = new Random();→ 全局单例，退化为竞争热点 - ✅ 正确做法：字段声明改为每次调用
ThreadLocalRandom.current().nextInt(100) - ✅ 或初始化时用
SecureRandom生成强熵种子：new Random(secureRandom.nextLong())
