高并发下 Random 性能瓶颈源于共享实例引发的 CAS 自旋空转，表现为 RUNNABLE 线程激增但吞吐不升、CPU 使用率异常偏低；应通过 Arthas、JMC 定位热点，禁用 static/final Random，改用每次调用 ThreadLocalRandom.current().nextInt()。
排查 Random 在高并发下因 CAS 竞争导致的性能瓶颈，核心是识别“线程在 RUNNABLE 状态却几乎不推进业务”的异常现象——它不是阻塞，而是空转耗 CPU。
看线程状态和 CPU 使用率是否矛盾
当系统 QPS 上升但吞吐不增、响应延迟飙升，而 CPU 使用率却未明显升高（甚至偏低），就要怀疑 CAS 自旋空转。这是因为失败线程反复执行 compareAndSet() 但总不成功，消耗 CPU 周期却不做有效计算。
- 用 Arthas thread 查看线程栈：重点关注大量线程堆栈停留在
java.util.Random.next或java.util.concurrent.atomic.AtomicLong.compareAndSet - 用 JMC（Java Mission Control） 或 VisualVM 观察热点方法：如果
Random.nextInt()占用 CPU 时间比例异常高，且调用频次与业务量严重不匹配，基本可定位 - 对比压测前后线程状态分布：RUNNABLE 线程数激增但实际工作线程没增加，说明大量线程卡在自旋重试
查代码里是否共享了 Random 实例
真正的问题往往藏在写法里。不是 Random 本身有问题，而是误用了它的线程安全假象。
- 搜索项目中所有
static Random或final Random字段声明，尤其是工具类、配置类、Spring Bean 中的单例 Random - 检查是否出现
private static final ThreadLocalRandom R = ThreadLocalRandom.current();这类静态缓存——它会让所有线程共用初始化时刻的同一个实例，完全失去线程隔离意义 - 留意并行流或 CompletableFuture 中是否传入了外部 Random 实例，例如
list.parallelStream().map(x -> sharedRandom.nextInt())
用压测对比验证瓶颈是否解除
改完之后不能只看单次日志，要量化验证。
立即学习“Java免费学习笔记（深入）”；
- 保持相同并发线程数（如 100 线程）、相同请求逻辑，分别测试
new Random().nextInt()、共享Random、ThreadLocalRandom.current().nextInt()三种写法 - 重点观测：P99 延迟下降幅度、QPS 提升倍数、CPU 负载变化趋势。实测中，ThreadLocalRandom 通常比共享 Random 快 4–5 倍
- 注意控制变量：避免因 GC 频次、内存分配等干扰项掩盖真实效果；建议用 JMH 写微基准测试隔离随机数生成环节
警惕“伪优化”写法
有些看似合理的方式，反而会退化成更差的性能。
- 不要为每个请求 new Random()：构造开销大，且初始种子依赖系统时间，高频调用时多个实例种子可能相同，导致随机序列趋同
- 不要用 synchronized 包裹 Random：锁粒度粗，吞吐量比 CAS 更低，还引入上下文切换开销
- 不要把 ThreadLocalRandom.current() 存为成员变量或静态变量：它必须在业务执行路径中每次调用，才能触发线程专属种子初始化
