1. 从一次压测事故说起为什么随机数生成也能成为性能瓶颈几年前参与一个订单号生成服务QPS 峰值大概在八千左右逻辑本身不复杂接收请求生成一个带随机后缀的流水号写库返回。上线前压测单机四核TPS 死活卡在两千出头CPU 使用率却只有百分之四十多剩下的全耗在等待上。用采样工具抓了一轮线程栈发现大量线程阻塞在java.util.Random的nextInt方法上——准确地说是阻塞在它内部那个AtomicLong的 CAS 自旋上。这个场景其实非常典型。Random为了保证多线程下的种子一致性内部用了一个原子变量做种子更新每次取随机数都要 CAS 一次。单线程下没问题一旦并发上来多个线程抢同一个原子变量CAS 失败就重试重试失败再重试CPU 空转吞吐量断崖式下跌。当时把Random换成ThreadLocalRandom同样的压测脚本TPS 直接冲到一万二CPU 使用率反而更平稳了。这件事让我意识到随机数生成这个看起来人畜无害的基础 API在高并发场景下能直接决定系统的吞吐上限。而ThreadLocalRandom正是 JDK 7 引入、专门为解决这个问题而生的工具类。它适合所有需要在多线程环境下生成随机数的场景尤其是高并发服务端开发、压测工具、模拟数据生成、游戏逻辑、抽奖算法这类对性能敏感的地方。如果你还在多线程里用Random或者Math.random()这篇文章值得花时间看完。2. ThreadLocalRandom 到底解决了 Random 的什么问题2.1 Random 的种子竞争一个被低估的并发陷阱先看Random的内部结构。它维护一个AtomicLong seed每次调用next(int bits)时通过 CAS 把种子更新为(seed * 0x5DEECE66DL 0xBL) ((1L 48) - 1)然后取高位返回。这个设计在单线程下是完美的线性同余发生器速度快、分布均匀。问题出在多线程。假设十个线程同时调nextInt()它们都要对同一个AtomicLong做 CAS。同一时刻只有一个线程能成功其余九个要么自旋重试要么被挂起。线程越多竞争越激烈CAS 失败率越高实际有效计算时间占比越低。这就是典型的伪共享之外的另一种并发退化——热点原子变量竞争。我做过一个粗略的对比测试八核机器每个线程生成一千万个随机整数实现方式线程数总耗时毫秒相对性能Random1420基准Random89800下降约 23 倍ThreadLocalRandom1450基本持平ThreadLocalRandom8620几乎线性扩展数据很直观Random在多线程下性能不升反降而ThreadLocalRandom几乎保持了线性扩展能力。原因就在于它把种子从全局共享变成了线程私有。2.2 线程私有种子把竞争消灭在源头ThreadLocalRandom继承自Random但重写了核心的种子管理逻辑。它不再使用AtomicLong而是把种子存放在每个Thread对象自己的一个字段里JDK 8 之后是Thread类中的threadLocalRandomSeed、threadLocalRandomProbe、threadLocalRandomSecondarySeed三个字段。每个线程操作自己的种子天然没有竞争也不需要 CAS。这里有个设计细节值得说为什么种子不放在ThreadLocalRandom实例里而是放在Thread对象里因为ThreadLocalRandom是单例的所有线程共享同一个实例。如果种子放在实例里那又回到了共享状态的老路。把种子挂到Thread上每个线程访问自己的字段既避免了竞争又省去了ThreadLocal的 map 查找开销。这是一种用空间换并发的经典手法代价是每个线程多几个字段的内存占用换来的是近乎零开销的随机数生成。2.3 与 Math.random() 的关系同一个坑的两副面孔很多人以为Math.random()是独立实现其实它内部就是持有一个静态的Random实例每次调用都走那个共享实例的nextDouble()。也就是说Math.random()在高并发下和直接用Random是一模一样的性能问题甚至更隐蔽因为调用者根本看不到那个共享实例的存在。我在代码审查里见过不少项目业务代码里到处是Math.random()压测一上来就发现某个接口 RT 飙升排查半天才发现是随机数生成的锅。所以第一条经验就是多线程环境下见到Math.random()和共享Random实例就要警惕。3. 正确使用 ThreadLocalRandom 的几种姿势3.1 获取实例current() 而不是 newThreadLocalRandom的构造函数是私有的你没法new。正确入口是静态方法ThreadLocalRandom.current()。这个方法会检查当前线程的种子是否已初始化没有就初始化一个然后返回单例。ThreadLocalRandom random ThreadLocalRandom.current(); int value random.nextInt(100);注意current()返回的是同一个单例对象但每次调用都会确保当前线程的种子就绪。所以你可以放心地在方法内部反复调用current()不会有额外开销也不需要在类级别缓存这个实例。实际上缓存ThreadLocalRandom实例是反模式因为它本来就是单例缓存反而可能让代码看起来像是跨线程共享引起误解。3.2 常用 API 与边界语义ThreadLocalRandom提供了比Random更丰富的 API尤其是带边界的生成方法// 生成 [0, bound) 范围内的 int int i ThreadLocalRandom.current().nextInt(100); // 生成 [origin, bound) 范围内的 int int j ThreadLocalRandom.current().nextInt(10, 50); // 生成 [0, bound) 范围内的 long long l ThreadLocalRandom.current().nextLong(1000L); // 生成 [origin, bound) 范围内的 long long m ThreadLocalRandom.current().nextLong(100L, 200L); // 生成 [0.0, 1.0) 范围内的 double double d ThreadLocalRandom.current().nextDouble(); // 生成 [origin, bound) 范围内的 double double e ThreadLocalRandom.current().nextDouble(1.5, 3.5); // 生成随机 boolean boolean b ThreadLocalRandom.current().nextBoolean();这里有个容易踩的坑所有带边界的 API 都是左闭右开区间即[origin, bound)。nextInt(10, 10)会直接抛IllegalArgumentException因为区间为空。如果你需要生成[1, 100]的闭区间随机数得写成nextInt(1, 101)。这个加一的操作看起来简单但在实际项目里我见过不止一次因为漏加一导致最大值永远取不到抽奖活动里一等奖永远抽不中的 bug 就是这么来的。3.3 生成随机数组和流式操作JDK 8 之后ThreadLocalRandom还支持生成随机数组和流// 生成 10 个 [0, 100) 的随机整数数组 int[] arr ThreadLocalRandom.current().ints(10, 0, 100).toArray(); // 生成 5 个 [1.0, 10.0) 的随机 double 数组 double[] doubles ThreadLocalRandom.current().doubles(5, 1.0, 10.0).toArray(); // 生成无限随机流取前 20 个 int[] streamArr ThreadLocalRandom.current().ints(0, 1000).limit(20).toArray();这些流式 API 在生成测试数据、模拟批量请求时特别顺手。不过要注意ints(long streamSize, int randomNumberOrigin, int randomNumberBound)这个重载的参数顺序是数量在前边界在后和nextInt(origin, bound)的顺序不一样写的时候容易搞混。我的习惯是生成数组时统一用流式写法避免参数顺序记错。4. 那些年我在 ThreadLocalRandom 上踩过的坑4.1 跨线程传递种子不会跟着线程走这是最隐蔽也最容易出问题的一点。ThreadLocalRandom的种子绑定在当前执行线程上如果你把任务提交到线程池任务实际执行在池里的工作线程上种子用的是工作线程的而不是提交线程的。这本身没问题但如果你在任务里依赖同一个线程生成的随机序列可复现就会出问题。更典型的场景是主线程调current()拿到实例传给子线程用。子线程调用时current()内部会检查子线程自己的种子发现没初始化就初始化一个所以功能上没问题但如果你误以为传过去的实例带着主线程的种子状态那就错了。实例是共享的状态是线程私有的这个心智模型必须建立起来。4.2 在 ForkJoinPool 和虚拟线程中的表现JDK 8 的ForkJoinPool对ThreadLocalRandom有特殊优化工作线程的种子初始化时机和普通线程略有不同但使用方式不变。到了 JDK 21 的虚拟线程情况又变了虚拟线程数量可能极其庞大每个虚拟线程都往Thread对象上挂种子字段内存开销需要关注。不过虚拟线程的Thread对象本身是轻量的种子字段也就几个 long实际影响可控。我在一个模拟十万虚拟线程的测试里随机数生成部分没有成为瓶颈真正吃内存的是每个虚拟线程的栈和调度结构。4.3 setSeed 的陷阱别在多线程里调ThreadLocalRandom重写了setSeed(long seed)但它的实现是直接抛UnsupportedOperationException。原因很简单种子是线程私有的你在这个线程调setSeed影响不了别的线程语义上容易让人误解为全局设置种子所以 JDK 直接禁掉了。如果你确实需要可复现的随机序列比如单元测试里固定种子正确做法是用new Random(seed)创建局部实例在单线程里用。测试代码通常不追求并发性能用Random完全没问题。我见过有人在测试里用ThreadLocalRandom然后抱怨结果不可复现这就是用错了工具。4.4 安全性它不是加密安全的ThreadLocalRandom和Random一样都是线性同余发生器输出序列在知道部分结果后可以被预测。绝对不能用于生成密码、令牌、会话 ID、加密密钥这类安全敏感的场景。这类场景要用java.security.SecureRandom。我在安全审计里见过用ThreadLocalRandom生成短信验证码的代码虽然验证码有有效期限制风险相对可控但这是明确的反模式一旦被利用就是批量撞库的入口。判断标准很简单如果随机数的不可预测性关系到资金、权限、隐私就用SecureRandom如果只是为了让数据分布均匀、避免碰撞用ThreadLocalRandom。前者慢但安全后者快但可预测各司其职。5. 性能对比与选型决策表5.1 三种随机数方案的横向对比维度RandomThreadLocalRandomSecureRandom线程安全是CAS是线程私有是单线程性能高高低多线程性能急剧下降接近线性扩展低可预测性可预测可预测不可预测适用场景单线程、测试高并发业务安全敏感场景种子设置支持不支持支持JDK 版本1.01.71.0这张表基本覆盖了选型时需要考虑的所有维度。我的经验是默认用ThreadLocalRandom除非有明确的安全需求或单线程可复现需求。这个默认选择能覆盖百分之九十以上的场景。5.2 一个真实的选型案例之前做一个抽奖系统奖品池有十万个奖品用户点击抽奖时从池子里随机取一个。最初用的是Collections.shuffle加RandomQPS 一高就卡。后来改成用ThreadLocalRandom生成随机索引直接从数组里取性能问题解决。但这里有个细节奖品池是共享的多个线程同时读没问题但如果抽奖后要移除奖品就得加锁或用并发容器。我们当时的方案是奖品池只读抽中的奖品通过单独的库存服务扣减这样随机数生成和库存扣减解耦各自都能水平扩展。这个案例说明ThreadLocalRandom解决的是随机数生成这一环的性能但整个系统的并发问题往往不止这一环。选型时要看清楚瓶颈到底在哪别把ThreadLocalRandom当成万能药。5.3 基准测试的注意事项如果你想自己跑基准测试有几个坑要避开。第一别用System.currentTimeMillis()计时精度不够用System.nanoTime()。第二要预热JIT 编译需要时间前几轮的结果不可信。第三要防止死代码消除生成的结果得被使用比如累加后打印。第四线程数要匹配 CPU 核心数超配线程反而会引入调度开销干扰结论。我通常用 JMH 做这类测试虽然配置麻烦点但结果可靠。手写测试的话至少跑五轮取后三轮平均每轮之间让线程休息一下避免热积累影响。6. 把 ThreadLocalRandom 用对的几条硬核经验第一永远不要在类字段里缓存ThreadLocalRandom.current()的返回值。它本来就是单例缓存没有性能收益反而会让读代码的人以为这是个有状态对象。直接在方法里调current()JIT 会把它优化得很好。第二生成闭区间随机数时边界记得加一。nextInt(1, 100)生成的是 1 到 99要生成 1 到 100 得写nextInt(1, 101)。这个错误在抽奖、分页、索引计算里特别常见而且往往测试时发现不了上线后才发现某个边界值永远取不到。第三线程池场景下放心用但别指望种子可复现。线程池的工作线程是复用的每个线程的种子在第一次调用时初始化之后一直沿用。这意味着同样的任务提交顺序不同批次的执行结果可能不同。如果业务需要可复现用固定种子的Random实例并且保证单线程执行。第四安全场景一律换SecureRandom。这条没有例外。验证码、令牌、密钥、盐值全部走SecureRandom。性能不够就加缓存池但绝不能为了性能牺牲安全性。第五注意 JDK 版本差异。JDK 7 刚引入时ThreadLocalRandom的种子字段是放在ThreadLocal里的JDK 8 才改成Thread的直接字段。如果你维护的是 JDK 7 的老系统性能特征可能和 JDK 8 不一样升级前最好重新测一轮。第六别在静态初始化块里调current()。类加载阶段可能由特定的线程执行那时候拿到的种子和后续业务线程的不是一回事。虽然功能上没问题但如果你在静态块里生成一批随机数据缓存起来要清楚这批数据是用哪个线程的种子生成的。第七生成大量随机数时考虑批量 API。ints(size, origin, bound)这类方法内部做了优化比循环调nextInt快不少。我实测生成一百万个随机整数批量 API 比循环快大约百分之三十数据量越大差距越明显。7. 从字节码角度看 ThreadLocalRandom 的快如果你对底层感兴趣可以看看current()方法编译后的字节码。它大致做了这么几件事获取当前Thread对象读取threadLocalRandomSeed字段如果为 0 就调用初始化逻辑然后返回单例。整个过程没有锁没有 CAS没有ThreadLocalMap查找就是几次字段访问加一个分支判断。对比Random.next()的字节码你会看到AtomicLong.compareAndSet的调用那是一个 native 方法涉及内存屏障和缓存一致性协议。在八核机器上跨核的缓存行同步开销是几十到上百纳秒级别而ThreadLocalRandom的字段访问基本就是 L1 缓存命中几纳秒的事。这个差距在高频调用下被放大成数量级的性能差异。理解这一点你就能明白为什么ThreadLocalRandom的设计是把状态打散到各个线程而不是用更聪明的锁来保护共享状态。前者从根源上消除了竞争后者只是在竞争发生时减少等待。这是两种完全不同的并发哲学ThreadLocalRandom选择了前者。8. 一个完整的实战示例高并发订单号生成器最后给一个可以直接参考的订单号生成器实现用到了ThreadLocalRandom和ThreadLocal的结合public class OrderIdGenerator { private static final DateTimeFormatter FORMATTER DateTimeFormatter.ofPattern(yyyyMMddHHmmss); public static String generate() { String timestamp LocalDateTime.now().format(FORMATTER); int randomSuffix ThreadLocalRandom.current().nextInt(100000, 1000000); return timestamp randomSuffix; } }这个实现里时间戳精确到秒随机后缀六位理论上一秒内可以生成九十万个不重复的订单号。如果并发量更大可以把时间戳精确到毫秒或者增加随机后缀位数。注意这里没有用synchronized也没有用AtomicLong做序列号完全依赖ThreadLocalRandom的并发能力。实测在十六核机器上这个生成器的 TPS 可以稳定在五十万以上瓶颈最终落在LocalDateTime.now()的系统调用上而不是随机数生成。如果连这个都要优化可以用System.currentTimeMillis()加缓存格式化结果但那是另一个话题了。这个例子想说明的是ThreadLocalRandom的价值不只是快更是让并发代码变简单。你不需要考虑锁、不需要考虑序列号同步、不需要考虑线程安全直接调就行。这种无脑用的体验才是它最大的工程价值。