如何利用 ThreadLocalRandom 避免多线程中传统 Random 的竞争开销？

本文共计712个文字，预计阅读时间需要3分钟。

多个线程共用一个 `Random` 实例时，每次调用 `nextInt()` 都需竞争更新同一个 `AtomicLong seed`。CAS 失败后，不是挂起，而是空转重试（自旋）。线程数超过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 ，两者都抛 <code>IllegalArgumentException，务必提前校验输入
• 不要试图用 ThreadLocalRandom 生成跨线程一致的序列——它不支持 setSeed()，种子由系统安全熵初始化，不可控

单线程场景下别硬套 ThreadLocalRandom

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

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

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