并发环境下的随机数生成：对比 Random、ThreadLocalRandom 与 SecureRandom 的线程安全性

遇到并发环境下的随机数生成，很多人的第一反应是直接用Random，或者干脆上SecureRandom图个心安。先下一个判断：这三个工具各有各的用武之地，选错了，轻则性能掉一个数量级，重则把系统的安全防线直接暴漏出去。

简单梳理一下它们的核心差异：Random线程安全，但高并发下因为CAS的激烈争抢，反而会成为性能瓶颈；ThreadLocalRandom则更像为并发量身定制，每个线程有自己独立的状态，完全没有同步开销；至于SecureRandom，它的优先级永远是安全，性能只能往后放，特别适合密钥这类敏感场景。

Random：线程安全，但别在人多的地方用

Random类在API层面确实是线程安全的，这一点没毛病。它内部用AtomicLong来管理种子，每次调用方法都能保证原子性。但问题就出在这里——当多个线程共享同一个Random实例时，它们都在拼命地争抢种子更新权。底层操作是CAS自旋，在高并发下，光是这个自旋消耗就够喝一壶的，还会导致缓存行失效，吞吐量断崖式下降。

你可能会在实际项目中遇到这种情况：

• 8个线程共用一个Random实例，结果总吞吐量反而比单线程还慢
• 生成验证码、会话ID这种高频操作，成了响应延迟的隐性元凶
• 虽然程序不会报错，但这种性能损耗是真实存在的，尤其是在CPU密集型的服务里

ThreadLocalRandom：天生为了并行而生

Ja va 7引入的ThreadLocalRandom，本质上不是“加锁版的Random”。它彻底放弃了这个思路，转而让每个线程都拥有独立的随机数状态。这个状态是通过Thread类的私有字段（比如threadLocalRandomSeed）来实现的，没有CAS，更没有任何同步开销。

使用起来有几个要点需要记住：

• 不需要new实例，直接调用ThreadLocalRandom.current()就能拿到当前线程的实例
• 几乎覆盖了所有多线程业务场景：负载均衡选节点、模拟请求延迟、分页随机偏移，它都能轻松胜任
• 但它不能指定seed，也不支持setSeed——这是为了保持线程隔离性而付出的代价

SecureRandom：安全至上，性能可以妥协

如果说前两者追求的是速度和可用性，那SecureRandom的核心价值只有一件事：不可预测性。它从操作系统采集熵源（比如/dev/urandom，或者硬件时钟的抖动），再经过SHA或AES这类算法混合生成。从设计上，它就不是为快而生的。

换句话说：

• 它确实是线程安全的，但初始化过程可能会阻塞，尤其是在熵源不足的容器环境里
• 生成速度远不如前两者，高频调用下会成为明显的性能短板
• 但有些场景是它的“主场”：JWT密钥、AES初始化向量、一次性令牌、密码盐值……这些地方，必须用SecureRandom

选择的逻辑：场景为王

不用纠结“哪个最好”，核心是匹配你的实际需求：

• 单线程或低并发的工具类→Random就够用了，简单、可靠、没毛病
• Web服务、消息处理、批任务这类通用多线程逻辑→ThreadLocalRandom是默认推荐，省心又高效
• 密钥、签名、认证、加密这些安全相关环节→没得选，必须上SecureRandom，这点性能开销省不得

最后补充一点，关于混淆风险。用Random去生成token或salt，本质上等于把系统安全建立在一个可预测的线性序列上。市面上已经有了不少漏洞案例，根因就是这里。别贪图一时的方便，有些代价是系统承受不起的。