Random与ThreadLocalRandom性能对比详解

在高并发场景下，ThreadLocalRandom凭借为每个线程维护独立种子、彻底消除CAS竞争与伪共享，性能显著优于依赖AtomicLong+CAS更新共享种子的Random；但选择并非绝对——需根据是否需要可重现性（选Random）、单线程复用效率、安全性要求（应选SecureRandom）等具体场景权衡，同时警惕将Random声明为全局Bean或在循环中频繁新建等常见误用陷阱。

多线程环境下，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())

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~