Java 随机数陷阱：SecureRandom

背景一个看似简单的小说推荐功能在本地开发和云服务器直接部署时都运行良好但一旦迁移到 Docker 容器环境接口响应时间从毫秒级飙升到几十秒甚至超时最终导致后端服务假死。只有重启容器才能恢复。经过系列排查找到罪魁祸首如下Random rand SecureRandom.getInstanceStrong();问题现象本地 Windows/Mac 开发环境推荐接口响应 10ms云服务器直接部署CentOS 8推荐接口响应 20msDocker 容器部署同一台 CentOS 8推荐接口响应 5s~60s高并发时线程池耗尽错误日志2026-06-30 18:35:18.123 ERROR [http-nio-9091-exec-42]org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/api]Servlet.service() for servlet [dispatcherServlet] threw exceptionjava.lang.IllegalStateException: Thread blocked waiting for entropyat java.base/java.security.SecureRandom.nextBytes(SecureRandom.java)at org.example.chyznovel.service.impl.BookServiceImpl.listRecBooks(BookServiceImpl.java:202)浏览器端表现OPTIONS 预检请求返回 504 Gateway Time-out实际 POST 请求偶尔成功但大部分超时Nginx 日志显示大量 upstream timeout原因分析1. SecureRandom.getInstanceStrong() 的工作原理SecureRandom.getInstanceStrong() 是 Java 提供的密码学安全随机数生成器它会Linux 系统读取 /dev/random 设备文件Windows 系统调用 CryptoAPImacOS 系统读取 /dev/urandom关键问题在于/dev/random 是阻塞式的真随机数源。2. 熵池Entropy Pool机制Linux 内核维护一个熵池收集系统中的各种噪音作为随机数种子键盘敲击时间间隔鼠标移动轨迹硬盘读写延迟网络包到达时间中断事件当应用程序从 /dev/random 读取数据时熵池充足立即返回随机数熵池不足阻塞等待直到收集到足够的熵查看当前熵池大小cat /proc/sys/kernel/random/entropy_avail# 正常值 1000# 危险值 100此时读取 /dev/random 会阻塞3. 为什么容器环境特别容易触发环境熵源丰富度是否容易阻塞本地开发机丰富有鼠标、键盘、GUI否物理服务器较丰富有硬盘、网络、中断偶尔Docker 容器贫乏隔离环境无外设极易容器的熵池问题隔离性导致熵源减少容器内没有鼠标、键盘等交互设备共享宿主机熵池多个容器竞争同一个宿主机的熵资源启动初期熵池为空容器刚启动时熵池几乎为零需要时间积累高并发放大问题每个线程调用 getInstanceStrong() 都会消耗熵快速耗尽池子4. 为什么本地和直接部署没问题本地开发你的电脑有鼠标、键盘、浏览器等大量源熵池始终充足云服务器直接部署虽然没有 GUI但有网络流量、磁盘 I/O、定时中断等熵源基本够用容器部署熵源被大幅削减加上多容器竞争极易触发阻塞解决方案方案一改用 ThreadLocalRandom推荐适用场景推荐算法、游戏逻辑、A/B 测试等不需要密码学安全的场景方案二使用非阻塞的 SecureRandom适用场景必须用强随机数但不能接受阻塞方案三增加容器熵源治标不治本如果确实需要用 SecureRandom.getInstanceStrong()可以优化容器熵池1. 安装 haveged熵守护进程# DockerfileFROM openjdk:21-slimRUN apt-get update \apt-get install -y haveged \apt-get cleanCMD [haveged, -w, 1024, -v, 1, --Foreground]# docker-compose.ymlservices:app:image: myappcap_add:- SYS_ADMIN # haveged 需要特权2. 挂载宿主机的 /dev/random# docker-compose.ymlservices:app:volumes:- /dev/random:/dev/random- /dev/urandom:/dev/urandom什么时候必须用 SecureRandom必须用的场景密码学安全要求生成加密密钥AES、RSA生成 JWT Token 签名密钥生成密码盐值salt生成 CSRF Token生成一次性验证码防止暴力破解彩票/赌博系统开奖法律要求不可预测不需要用的场景伪随机即可推荐算法随机排序游戏中的随机掉落A/B 测试分组负载均衡随机选择模拟数据生成任何即使被猜到也没关系的场景随机数生成器选型指南场景推荐方案理由密钥 / Token 生成new SecureRandom()需要强随机性但频率低阻塞可接受验证码生成new SecureRandom()防暴力破解需要不可预测性推荐 / 游戏 / A-B 测试ThreadLocalRandom.current()高频调用性能优先伪随机够用SSL / TLS 握手new SecureRandom()JDK 内部已优化无需手动干预⚠️ 绝对不能用除非有特殊强随机需求且能接受阻塞SecureRandom.getInstanceStrong()可能严重阻塞导致应用超时或线程池耗尽在 Docker 容器等低熵环境中即使你用了new SecureRandom()也建议配置-Djava.security.egdfile:/dev/urandom避免因熵池不足导致阻塞。如果你用的是物理服务器且业务对性能极度敏感如高并发网关对于非安全类随机如路由分发、采样优先用ThreadLocalRandom。SecureRandom.getInstanceStrong()在容器环境几乎等于自杀式阻塞除非你明确知道自己在做什么否则坚决避开。以后再也不乱抄网上的了嘤嘤嘤为什么 Java 不默认用非阻塞的这是一个历史遗留问题安全性优先Java 设计者认为宁可慢不能不安全向后兼容改变默认行为可能影响现有应用开发者责任框架提供工具具体选型由开发者决定其他语言的类似陷阱Pythonos.urandom() vs random.SystemRandom()Node.jscrypto.randomBytes()异步非阻塞vs crypto.pseudoRandomBytes()Gocrypto/rand阻塞vs math/rand非阻塞通用原则区分密码学安全随机数和普通伪随机数的使用场景。