如何通过 ThreadLocalRandom 解决多线程环境下对传统 Random 实例的竞争损耗

偷偷努力，悄无声息地变强，然后惊艳所有人！哈哈，小伙伴们又来学习啦~今天我将给大家介绍《如何通过 ThreadLocalRandom 解决多线程环境下对传统 Random 实例的竞争损耗》，这篇文章主要会讲到等等知识点，不知道大家对其都有多少了解，下面我们就一起来看一吧！当然，非常希望大家能多多评论，给出合理的建议，我们一起学习，一起进步！

共享Random会拖慢高并发服务，因多线程竞争更新同一AtomicLong seed导致CAS自旋耗CPU；ThreadLocalRandom必须每次调用current()，不可static缓存；推荐用nextInt(origin,bound)明确边界且性能更优。

为什么共享 Random 会拖慢高并发服务

多个线程共用一个 Random 实例时，每次调用 nextInt() 都要竞争更新同一个 AtomicLong seed。CAS 失败后不是挂起，而是空转重试（自旋），CPU 白耗在“抢种子”上。线程数超过 4 个后，响应时间就明显抬升；电商秒杀里一个全局 Random 可能直接让接口 P99 延迟翻倍。

ThreadLocalRandom.current() 必须每次调用，不能 static 缓存

常见误写：private static final ThreadLocalRandom RANDOM = ThreadLocalRandom.current();——这行代码只在类加载时执行一次，所有线程拿到的是同一个初始实例，完全失去线程隔离意义，等同于退化回 Random。

• 正确做法：每次需要随机数时，都写 ThreadLocalRandom.current().nextInt(1, 101)
• 不要提取为字段或常量，哪怕在循环里也照写不误
• Spring Bean 或 Servlet 中，别把 Random 声明为 private final 字段，否则所有请求线程共享同一实例

范围生成别用 nextInt(bound)，优先用 nextInt(origin, bound)

nextInt(100) 生成 [0, 100) 整数，容易写错边界；而 nextInt(1, 101) 明确表达“1 到 100（含）”，语义清晰、不易越界，且内部对 bound - origin 是 2 的幂时会走位运算快速路径。

• 避免 nextInt(0, 100) 这种冗余写法，和 nextInt(100) 等价但更啰嗦
• 若 bound ，两者都抛 IllegalArgumentException，务必提前校验输入
• 不要试图用 ThreadLocalRandom 生成跨线程一致的序列——它不支持 setSeed()，种子由系统安全熵初始化，不可控

单线程场景下别硬套 ThreadLocalRandom

在纯单线程逻辑（如 CLI 工具、单元测试 setup）、或线程生命周期极短且调用频次极高（比如每毫秒调用几十次）时，ThreadLocalRandom.current() 的线程局部变量查找开销反而比复用一个本地 Random 实例慢。

• 单线程反复生成随机数：用 new Random() + 本地变量更合适
• 需要可重现结果（如算法验证、游戏回放）：必须用 new Random(seed)，ThreadLocalRandom 不提供种子控制能力
• ForkJoinPool / Tomcat / CompletableFuture 等典型多线程环境，才是它的主场

真正容易被忽略的是：它解决的是“争种子”的问题，不是“随机性差”的问题。如果你的业务依赖确定性序列，或者压根没并发，强行替换只会引入额外开销和理解成本。

好了，本文到此结束，带大家了解了《如何通过 ThreadLocalRandom 解决多线程环境下对传统 Random 实例的竞争损耗》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！