ThreadLocalRandom提升多线程随机数性能

ThreadLocalRandom 通过线程局部变量机制彻底规避了 Random 在多线程下因共享 seed 引发的 CAS 自旋竞争问题，显著提升高并发场景（如秒杀）下的随机数生成性能；但必须每次调用 `ThreadLocalRandom.current()` 获取当前线程专属实例，严禁 static 缓存，高频使用时可提取为方法内局部变量以减少重复调用开销；同时推荐优先使用 `nextInt(origin, bound)` 明确指定闭区间范围，既增强语义清晰度，又避免边界计算错误和潜在性能陷阱。

为什么 Random 在多线程下会变慢

因为 Random 的 nextInt() 内部靠 AtomicLong.compareAndSet() 更新种子，多个线程抢同一个 seed 时，失败线程只能自旋重试——不是等锁，是空转耗 CPU。线程数一过 4 个，响应时间就明显拉长；秒杀场景下，一个共享 Random 实例可能让接口 P99 延迟翻倍。

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

常见误用：private static final ThreadLocalRandom RANDOM = ThreadLocalRandom.current(); —— 这会让所有线程共用初始化那一刻的单个实例，彻底失去线程隔离意义，等同于退化回 Random。

• 正确做法：每次需要随机数时，直接写 ThreadLocalRandom.current().nextInt(1, 101)
• 如果在循环或高频路径里，可把 ThreadLocalRandom.current() 提前赋给局部变量（非 static），例如：ThreadLocalRandom r = ThreadLocalRandom.current();，再反复调用 r.nextInt(...)
• 不要在类加载期、静态块或 Spring Bean 初始化时缓存 current() 结果

范围参数别漏掉 origin，优先用 nextInt(origin, bound)

nextInt(int bound) 只能生成 [0, bound)，而 nextInt(1, 101) 明确表达 [1, 100]，避免手算偏移出错，也绕开 bound 的运行时异常。

• 错误写法：random.nextInt(100) + 1 —— 多一次加法，语义模糊，且边界易错
• 正确写法：ThreadLocalRandom.current().nextInt(1, 101)
• 注意：bound 必须大于 origin，否则抛 IllegalArgumentException

它不适合需要复现随机序列的场景

ThreadLocalRandom 的种子由系统安全随机数初始化，不可外部设置。如果你要调试算法、回放游戏逻辑、或做确定性测试，必须用 new Random(seed) 或 new SecureRandom(seed)。

• 适合它的地方：发券码、抽奖、ID 偏移、压测数据生成——只要求“够随机”，不要求“可重现”
• 不适合的地方：跨线程协同生成同一随机流（比如分布式一致性哈希种子）、算法单元测试中依赖固定输出
• 关键点：它的高性能来自“每个线程玩自己的骰子”，但这也意味着你永远没法在另一个线程里“摇出同样的数字序列”

最容易被忽略的是：你以为用了 ThreadLocalRandom 就万事大吉，结果在工具类里把它 static 化了——那不是优化，是给自己埋了个高并发雷。

今天关于《ThreadLocalRandom提升多线程随机数性能》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！