Java随机数工具：Random与ThreadLocalRandom选择指南

多线程环境下应使用ThreadLocalRandom替代Random，因其无锁、线程隔离、性能高；单线程场景Random更合适，支持自定义种子和完整API；Math.random()仅适用于简单原型。

多线程环境下直接用 Random 会出问题

并发场景下，多个线程共用同一个 Random 实例时，nextLong()、nextInt() 等方法内部会竞争同一把锁（AtomicLong 或同步块），导致吞吐量下降，甚至出现明显性能瓶颈。这不是“偶尔慢”，而是在高并发压测中能观测到的 RT 上升和 CPU 软中断升高。

• 现象：线程数增加后，随机数生成速率不增反降，jstack 可见大量线程阻塞在 Random.next() 内部
• 根本原因：所有实例共享一个原子状态更新逻辑，无法真正并行
• 误区：有人以为“自己加锁保护 Random”就能解决——这只会让问题更重，且没解决本质竞争

ThreadLocalRandom 是专为并发设计的替代方案

ThreadLocalRandom 不是 Random 的子类，也不共享状态；它利用 ThreadLocal 为每个线程维护独立种子和计算逻辑，调用开销极低，无锁，且初始化延迟到首次使用。

• 必须通过 ThreadLocalRandom.current() 获取实例，不能 new —— 否则抛 UnsupportedOperationException
• 不支持设置自定义种子（setSeed() 被禁用），因为种子由线程本地机制隐式管理
• 只提供 nextInt()、nextLong()、nextDouble() 等常用方法，没有 nextGaussian() 这类开销大的方法
• 在 ForkJoinPool 或虚拟线程（Loom）中同样适用，JDK 19+ 已验证其与 ScopedValue 兼容

单线程或低频场景，Random 更简单可控

如果只是单元测试、配置加载、命令行工具等单线程上下文，Random 反而是更合适的选择：可预测（能传入固定 seed）、方法更全（比如 nextGaussian()、ints() 流式接口）、调试友好。

• 需要复现某次随机行为？new Random(12345) 比任何 ThreadLocalRandom 都可靠
• 要生成服从正态分布的值？Random.nextGaussian() 是标准解，ThreadLocalRandom 不提供
• 用在 Spring Bean 中被多个单线程组件引用？只要不跨线程共享实例，Random 完全安全

别混淆 Math.random() 和前两者

Math.random() 底层其实调用的是静态的 ThreadLocalRandom 实例，但它只返回 [0.0, 1.0) 的 double，且无法控制种子或分布类型。它适合快速原型，但不适合对随机性有明确要求的业务逻辑。

• 调用 Math.random() 一百万次，比直接用 ThreadLocalRandom.current().nextDouble() 多一次方法查表和范围缩放
• 它和 ThreadLocalRandom 共享同一套线程本地状态，所以不会额外增加线程局部存储压力
• 但如果你需要整数、带边界的随机值（如 nextInt(100)），硬用 Math.random() 做转换反而易出边界错误