有一次给团队做代码评审看到有人在高并发抽奖接口里直接new Random()然后紧跟着在循环里调用nextInt(100)。我问他为什么这么写他说“随机数嘛不都这样”。那次之后我才意识到Java 里一个看起来最简单的Random其实藏着大量值得抠的细节种子怎么来、线程安全与否、性能差多少、什么时候该用SecureRandom。面试八股爱考它生产环境也总在它身上翻车。所以这篇就围绕 Java Random 好好聊聊从实现原理到选型实践从面试问答到排坑实录一次性把这块讲透。讲之前先定个调如果你只是写个小 demonew Random()确实够用但只要你碰并发、碰安全、碰大数据量模拟就必须搞清楚 Random 家族里每个成员的区别。这篇文章适合刚学 Java 的同学也适合准备面试的选手更适合理清生产环境随机数选型的老手。1. 项目概述与核心痛点1.1 这个标题背后的真实需求JAVA Random这几个词在搜索引擎里被翻来覆去地搜背后其实是几类完全不同的需求在共享同一个关键词。第一类是刚入门的人想知道Random怎么用nextInt()和Math.random()有什么区别。第二类是准备面试的人看到“Java 八股文”里经常出现 Random 相关的题比如“Random 线程安全吗”“ThreadLocalRandom 怎么用”。第三类是已经在写业务代码的人他们在并发场景里遇到了性能问题或者发现随机结果有规律想搞明白到底怎么选。所以这篇不会只停留在 API 层面而是把 Random 当成一个完整的技术主题来解构随机数发生器PRNG是怎么工作的、不同实现有什么取舍、在真实业务里应该怎么落地。1.2 理解“伪随机”的本质首先必须建立一个概念Java 里的Random不是真正的随机数发生器它是伪随机数发生器PRNG。意思是它生成的序列看起来随机但实际上是由一个确定性的算法从“种子”推算出来的。你可以把种子理解成一副扑克牌的洗牌初始顺序。种子一旦确定后面所有牌的顺序就完全确定了。Random也一样给定相同的种子调用相同次数的next方法得到的结果一定完全相同。这个特性既是优点也是坑。优点是你可以用固定种子复现实验这在调试、单元测试、蒙特卡洛模拟里非常有用坑在于如果不懂这个原理可能在生产环境里种下一个固定种子结果所有请求拿到的“随机数”序列一模一样线上事故就这么来的。2. 核心机制与实现细节2.1 线性同余生成器LCG的底层逻辑java.util.Random的核心是一个经典的线性同余生成器Linear Congruential GeneratorLCG。它的递推公式是seed(n1) a * seed(n) c (mod m)Random内部维护了一个 48 位的原子性种子AtomicLong seed每次生成新的随机数时都会用这个公式更新种子。公式里的几个常量在 JDK 里是写死的private static final long multiplier 0x5DEECE66DL; private static final long addend 0xBL; private static final long mask (1L 48) - 1;知道这个原理你就能解释很多现象为什么new Random(42)和new Random(43)出来的序列不同——因为种子不同。为什么Random能保证 48 位种子的周期——因为它是 48 位线性同余周期最多 2^48。为什么它不适合密码学——因为 LCG 的结构太可预测从输出序列反推内部状态是可行的。2.2 种子的生成方式默认构造方法new Random()并不是随机取种子而是用了一个很巧妙的策略用一个全局的AtomicLong seedUniquifier结合System.nanoTime()来生成种子。public Random() { this(seedUniquifier() ^ System.nanoTime()); }这里有个值得注意的点常规文档不会告诉你seedUniquifier()这个方法本身也是一个基于 LCG 的静态序列它存在的意义是让每次new Random()拿到的种子大概率不同。为什么要和nanoTime()做异或因为如果多个线程几乎同时new Random()seedUniquifier可能相同异或上纳秒级时间戳可以进一步打散。但这里有个面试常问的点即使加了 nanoTime如果两个线程同一纳秒 new Random()理论上种子仍可能相同只不过概率极低。在严格要求不重复的场景不能只依赖默认构造。2.3 nextInt 和 nextInt(bound) 的实现差异nextInt()返回一个均匀分布在整个 int 范围内的随机整数它的实现经过了一些位处理来保证分布质量。而nextInt(int bound)是用来生成[0, bound)范围内随机数的常用方法它的实现里有几个容易被忽略的细节。老版本的nextInt(bound)实现里JDK 团队处理了“取模偏差”问题。如果你自己写random.nextInt() % bound得到的结果不仅分布不均匀因为% bound对负数的处理和对边界的切割会让某些值出现频率更高而且可能拿到负数。而nextInt(bound)内部做了边界保护和拒绝采样public int nextInt(int bound) { if (bound 0) throw new IllegalArgumentException(bound must be positive); int r next(31); int m bound - 1; if ((bound m) 0) // i.e., bound is a power of 2 r (int)((bound * (long)r) 31); else { for (int u r; u - (r u % bound) m 0; u next(31)) ; } return r; }这个循环看不懂没关系关键结论是当 bound 是 2 的幂时用位运算加速否则用拒绝采样消除不均匀。所以写代码时凡是需要[0, n)随机整数直接用nextInt(n)千万别自己去Math.abs(random.nextInt() % n)又慢又不均匀。2.4 为什么说 Random 的“随机性”是有限的Random的随机性在很多场景够用但它毕竟只有 48 位状态生成的序列周期是有限的。对普通业务来说2^48 的周期几乎不可能触发但在大量科学计算、仿真模拟里如果一次性生成几十亿个随机数可能就会踩到周期问题。这时候需要用更高质量的随机数发生器。还有一个容易被忽略的点Random生成的是均匀分布。很多人想要“正态分布”“泊松分布”会自己基于 Random 拼逻辑比如取一堆值的平均来近似正态分布。JDK 的Random提供了nextGaussian()但它是 Box-Muller 变换性能一般高并发场景不如用现成的高质量库。3. 工具选型解析与并发场景对比3.1 Random 的线程安全陷阱Random号称线程安全因为它内部把seed声明成了AtomicLong每次更新种子都用 CAS比较并交换保证原子性。但“线程安全”不等于“高并发友好”。在 JDK 8 之前多线程共享同一个Random实例时CAS 竞争会导致性能断崖式下降。你可以试着用 16 个线程同时调用nextInt()对比每个线程各自持有一个Random实例共享实例的吞吐量可能只有后者的几十分之一。更隐蔽的坑是很多人以为每次new Random()就完事了但构造函数本身也会竞争seedUniquifier这个静态原子变量。高并发下频繁new Random()照样会有轻微锁竞争开销。所以结论是并发场景下不要共享Random也不要频繁 newRandom而应该用ThreadLocalRandom。3.2 ThreadLocalRandom 为什么快ThreadLocalRandom是 JDK 7 引入的从名字就能看出来它是每个线程持有一个随机数生成器的实现。它做得更绝把种子保存在Thread对象自己的字段里而不是放在一个共享的AtomicLong上。// 用法 ThreadLocalRandom.current().nextInt(100);它最大的优势有两个。第一没有 CAS 竞争每个线程操作自己的种子字段性能几乎和单线程Random一样快。第二它通过current()拿到当前线程专属实例不需要像ThreadLocal那样手动管理对象生命周期用起来很轻。实测结果非常有说服力8 线程并发用共享Random生成 1000 万次随机数耗时可能是几百毫秒到一秒而用ThreadLocalRandom往往几十毫秒就完成。量级差距非常明显。需要注意一个使用细节ThreadLocalRandom的current()调用本身有开销但比共享Random的 CAS 竞争小得多。在循环里频繁调用current().nextInt()也没有问题JDK 内部做了优化。3.3 SplittableRandom 与并行流场景Java 8 又带来了SplittableRandom。它的定位和ThreadLocalRandom不同它专门为并行流parallel stream和 ForkJoin 框架设计。SplittableRandom支持split()方法可以从当前实例分裂出一个新的实例两个实例各自独立互不干扰。这在并行任务里非常有用主线程创建一个实例然后 split 给每个子任务子任务之间没有锁没有竞争。SplittableRandom random new SplittableRandom(); random.split().nextInt(100);它的随机性质量比Random更好内部用的是不同的算法虽然具体实现版本有迭代但整体比 LCG 更现代。如果你的场景是并行计算、模拟、跑批任务SplittableRandom是很好的选择。注意SplittableRandom不是Random的子类两者 API 有一些区别。不要指望它能直接替换Random来调用多态方法。3.4 SecureRandom 什么时候必须用如果你的随机数用于安全敏感场景比如生成 Token、密码盐值、密钥、验证码那Random、ThreadLocalRandom全都不能用。原因很简单它们的算法是可预测的。攻击者如果拿到一段输出序列配合已知的时间戳有可能推算出种子进而预测后续所有“随机数”。SecureRandom才是正解。它底层依赖操作系统提供的熵源比如 Linux 上的/dev/urandom或 Windows 上的 CryptGenRandom。它生成的随机数在密码学意义上是安全的无法从输出推算内部状态。SecureRandom secureRandom new SecureRandom(); byte[] bytes new byte[16]; secureRandom.nextBytes(bytes);这里有一个必须记住的实战细节new SecureRandom()在某些操作系统上可能因为熵源不足而阻塞。Linux 下如果使用/dev/random在系统刚启动、熵池不足时可能等很久。所以生产环境通常建议显式使用SHA1PRNG算法或者直接依赖/dev/urandom。JDK 8 之后默认行为有所调整但稳妥做法是针对特殊环境做压测。一句话总结选型普通业务用ThreadLocalRandom并行计算用SplittableRandom安全场景无脑SecureRandom只有单线程、低并发、不在乎性能的老代码才继续用Random。3.5 选型速查表场景推荐类理由单线程 demo/小工具Random简单直接够用多线程共享实例ThreadLocalRandom无锁性能高并行流/ForkJoinSplittableRandom支持 split线程独立加密 Token/密码盐/密钥SecureRandom密码学安全可复现实验/单元测试new Random(固定种子)结果可控4. 实操过程与核心环节实现4.1 并发环境下生成随机 ID真实业务里最常见的需求是生成不含业务含义的随机 ID比如用户抽奖流水号、活动批次号等。很多人会写public String genId() { return String.valueOf(new Random().nextLong()); }这个写法有三个问题频繁new Random()浪费资源nextLong()有概率产生非常短的数比如 0 附近的值导致 ID 长度不稳定在并发下如果不共享实例可能出现两个线程生成相同 ID取决于种子碰撞概率。比较规范的写法是结合时间戳和线程本地随机数public String genId() { ThreadLocalRandom random ThreadLocalRandom.current(); long timestamp System.currentTimeMillis(); long randomPart random.nextLong(100000, 999999); return timestamp - randomPart; }这里用nextLong(100000, 999999)指定范围避免出现过于极端的随机值。当然真实场景对唯一性要求高的话直接上 UUID 或雪花算法更靠谱。随机数只是一个辅助因子不要让它承担太多唯一性责任。4.2 抽奖场景的加权随机实现抽奖是 Random 最常见的应用场景。假如有三个奖品权重分别是 1、2、5怎么实现加权随机最直观的办法是构造一个累加权重数组然后生成一个[0, totalWeight)之间的随机数再判断落在哪个区间。int[] weights {1, 2, 5}; int total 0; for (int w : weights) { total w; } int target ThreadLocalRandom.current().nextInt(total); int acc 0; for (int i 0; i weights.length; i) { acc weights[i]; if (target acc) { // 命中 i 号奖品 break; } }这个实现简单明确面试时手写也不容易错。它的时间复杂度是 O(n)奖品数量很大时可以改成前缀和数组加二分查找优化到 O(log n)。踩坑提醒加权随机的前提是权重必须是正的。如果业务上允许权重为 0记得先过滤掉如果权重可能非常大total用long累积避免溢出。还有抽奖记录落库后建议把随机种子或随机结果一并保存方便后续对账和问题回溯。4.3 概率模拟与蒙特卡洛随机数的另一个典型用途是蒙特卡洛模拟。比如估算 π 的值可以用随机点落在一个单位正方形内统计落在扇形内的比例ThreadLocalRandom random ThreadLocalRandom.current(); int total 100_000_000; int inside 0; for (int i 0; i total; i) { double x random.nextDouble(); double y random.nextDouble(); if (x * x y * y 1.0) { inside; } } double pi 4.0 * inside / total;这里有个很重要的经验nextDouble()返回的是[0.0, 1.0)区间均匀分布可以直接用。但如果你要模拟的是高精度需求比如金融风控里的极端情景模拟Random的质量可能不够可以考虑用性能更好的SplittableRandom跑并行模拟或者引入第三方高质量 PRNG 库如 Apache Commons Math 里的实现。蒙特卡洛模拟中随机数序列的可复现性也很重要。同一个实验如果每次运行结果差别巨大很难排查问题。这时候用固定种子的Random反而是优点。4.4 线程封闭模式的最佳实践用ThreadLocalRandom时有个细节它的实例是和当前线程绑定的不能跨线程传递。如果有子线程需要生成随机数必须在子线程内部调用ThreadLocalRandom.current()而不能从父线程拿一个实例传给子线程用。同理如果你用ThreadLocal自行封装Random也面临同样的问题。线程池场景下线程会复用所以ThreadLocalRandom的种子是存在线程对象里的线程的多次任务之间会继续用上一次的种子状态这通常是好事能让序列更分散。但如果你希望每次任务结果可复现就需要用到固定种子的Random并配合任务上下文传入种子参数。5. 面试八股里的高频 Random 问题5.1 Math.random() 和 Random 是什么关系Math.random()底层就是Random的静态实例public static double random() { return RandomNumberGeneratorHolder.randomNumberGenerator.nextDouble(); }所以它不是另一个随机数体系只是一层封装。面试时如果问“Math.random() 和 new Random().nextDouble() 有什么区别”标准回答是底层同一个类但Math.random()使用的是一个全局共享的Random实例高并发下有竞争问题而new Random()可以自己控制实例还可以设置种子。这里就能自然引出线程安全问题Math.random()在多线程下虽然线程安全但性能不好。如果要高并发直接ThreadLocalRandom.current().nextDouble()更合适。5.2 Random 到底线程安全吗准确说法是Random的实例方法是线程安全的因为内部用AtomicLong更新种子但它在高并发下存在性能问题。面试官如果追问“既然线程安全为什么不用”可以回答CAS 失败会自旋重试线程越多竞争越激烈吞吐量下降明显。而且Random的线程安全只保证“不产生数据竞争”不保证“每次生成的序列在不同线程间没有关联”。如果多个线程同时用一个 Random 实例虽然不会得到相同的值概率极低但整体性能很差。更严谨的方案是每个线程独立的ThreadLocalRandom它把竞争消除在源头。5.3 为什么 Random 不能用于加密核心原因有两个第一LCG 的数学结构允许攻击者从输出序列反推内部状态。假设攻击者获取到连续的几个nextInt(100)结果虽然输出被bound截断过但配合暴力搜索 2^48 空间在现实算力下可行能恢复种子。第二Random的种子来源不包含不可预测的熵种子生成依赖时间戳和静态序列攻击者如果知道大概时间窗口可以大幅缩小搜索范围。安全场景必须用SecureRandom。它的熵来自操作系统内核的随机数池输出经过密码学安全的生成算法不可反推。5.4 面试中容易答错的细节有一个经典问题new Random(100).nextInt()和new Random(100).nextLong()第一个值一样吗答案是不一样因为nextInt()和nextLong()消耗的比特数不同种子更新的次数不同。但如果你分别new Random(100)然后调用相同次数、相同方法序列是相同的。这个问题能考出候选人是否理解“种子决定序列”的本质。另一个高频坑是nextInt(bound)的边界。nextInt(bound)返回[0, bound)不包含 bound。如果业务需求是生成[1, n]需要写成random.nextInt(n) 1。别小看这个1很多线上 bug 就是边界搞错的。同理nextInt(n)传负数会抛IllegalArgumentException不是返回负数。6. 常见问题与排查技巧实录6.1 为什么每次重启后随机数序列都一样如果线上服务每次重启后随机出来的中奖结果完全一样十有八九是有人显式设置了种子。排查方法很简单全局搜索new Random(看是否传入了固定数字。有些同事为了“复现问题”在代码里临时加了new Random(12345)忘了删就会导致这种现象。还有一种隐蔽情况某些框架的测试环境配置里通过-Drandom.seed设置了种子或者 Spring Boot 的测试套件复用了固定 Random。排查时不但要看代码还要看启动参数。6.2 ThreadLocalRandom 在线程池里使用正常吗正常但要理解一个现象线程池里线程被复用所以同一个线程在不同任务里拿到的ThreadLocalRandom.current()是同一个实例。这意味着随机序列会跨任务延续不会被重置。这通常是好事但如果某个任务依赖固定随机序列来复现结果就不能用ThreadLocalRandom而应该改用new Random(固定种子)并在任务内部隔离。6.3 生成的随机数重复率为什么高有一种很经典的错法在高频循环里new Random().nextInt(100)。表面上看每次生成新实例但实例的种子生成受系统时间影响。循环速度非常快时System.nanoTime()的差异可能很小导致多个实例的种子接近生成出来的第一批随机数就高度相关甚至相同。这种问题在低并发单线程里偶尔出现在高并发多线程里更容易出现因为多个线程同时获取种子碰撞概率上升。解决方案还是那一个共享一个ThreadLocalRandom或者用SplittableRandom。6.4 SecureRandom 初始化很慢怎么办在 Linux 生产环境new SecureRandom()偶尔会出现初始化耗时几十秒的情况。这是因为底层在等熵源。解决思路第一步确认 JDK 版本。JDK 8 以上默认用/dev/urandom的场景变多了但仍可能受securerandom.source配置影响。第二步在 JVM 启动参数里显式指定-Djava.security.egdfile:/dev/urandom第三步如果应用启动时不需要安全随机数可以考虑延迟初始化。比如等真正需要生成 Token 时再创建SecureRandom避免启动阻塞。注意不是所有环境都适合改egd要结合具体合规要求判断。6.5 多线程下共享 Random 导致 CPU 飙高这种情况我真实遇到过一个消息推送服务用全局单例Random来生成消息 ID 中的随机部分。压测时发现 CPU 使用率异常高火焰图一看大量时间耗在AtomicLong.compareAndSet的自旋上。换成ThreadLocalRandom后CPU 占用直接降了一个量级。如果你在代码里看到类似这样的写法private static final Random random new Random();然后多个线程频繁调用就要警惕了。虽然线程安全但它经常成为并发瓶颈。热力图上sun.misc.Unsafe.compareAndSwapLong出现频率高基本可以判定是这个原因。聊了这么多我的体会是Java 的随机数家族看着简单真正用对并不容易。个人建议你在项目里定一个简单的规范——默认用ThreadLocalRandom安全场景单独走SecureRandom并行计算交给SplittableRandom只有为了复现实验结果时才用固定种子的Random。最后再分享一个实用小技巧凡是涉及到随机数选择的代码都在注释里写清楚“为什么用这个类”这能避免后来者因为不理解而改成错误写法。随机数这事不踩一次线上坑很难真正长记性。