Java应用启动卡在SecureRandom初始化是因为默认使用阻塞的/dev/random熵源，解决方案首选JVM参数-Djava.security.egd=file:/dev/./urandom。
Java应用启动卡在SecureRandom初始化上
这是最典型的表象：应用日志停在drivermanager.getconnection()或连接池（如hikaricp、druid）初始化阶段，cpu很低，线程堆栈里反复看到securerandom.nextbytes()阻塞在nativeprng或sha1prng的enginenextbytes调用。根本原因是jvm在linux容器或无gui服务器上默认用/dev/random作为熵源，而该设备在熵不足时会**阻塞等待**，不是慢，是真卡住。
- 验证方法：执行
cat /proc/sys/kernel/random/entropy_avail，低于100就大概率出问题 - 常见场景：Docker容器（尤其Alpine镜像）、Kubernetes Pod、最小化安装的CentOS/RHEL
- 别指望“等一会儿”——它可能卡几十秒甚至几分钟，取决于系统有没有其他随机事件（键盘、鼠标、磁盘IO等）触发熵积累
绕过/dev/random阻塞的三种实操方案
核心思路是让SecureRandom不依赖/dev/random，改用非阻塞熵源。优先级按稳定性排序：
-
首选：JVM启动参数强制指定
SecureRandom算法
加-Djava.security.egd=file:/dev/./urandom（注意/dev/./urandom这个写法，斜杠+点+斜杠是绕过OpenJDK某些版本校验的惯用技巧） -
次选：修改
$JAVA_HOME/jre/lib/security/java.security
把securerandom.source=file:/dev/random改成file:/dev/urandom；但容器环境常不可写，且多实例共用JRE时有风险 -
慎用：代码里显式构造
SecureRandom
比如new SecureRandom(new byte[20])或SecureRandom.getInstance("SHA1PRNG")，但数据库驱动内部仍可能走默认路径，治标不治本
为什么/dev/urandom在现代Linux上是安全的
老教程常说“/dev/urandom不够安全”，这早过时了。Linux内核2.6.12+（2005年发布）起，/dev/urandom已采用密码学安全的重播种机制，只要初始熵够（启动时一次），后续输出就是加密安全的。JDK 8u161+也默认将NativePRNG的Blocking模式改为NonBlocking，但旧版本或特定配置下仍会退回到/dev/random。
- 关键点：
/dev/urandom不阻塞 ≠ 不安全，它只是不等待新熵，而是复用已有熵池并用密码学算法扩展 - 对比
/dev/random：后者在熵耗尽时返回EAGAIN或阻塞，对服务端应用毫无意义 - 如果硬要合规审计，FIPS 140-2允许
/dev/urandom用于密钥生成，NIST SP 800-90A也认可CTR_DRBG等基于/dev/urandom的实现
Docker/K8s环境必须检查的三个地方
光改JVM参数还不够，容器运行时本身可能加剧熵短缺：
- 确认基础镜像是否禁用了
RDRAND指令（如某些Alpine镜像）——加cat /proc/cpuinfo | grep rdrand看有无输出；没有的话，SecureRandom更依赖系统熵源 - K8s Pod要挂载
/dev/random和/dev/urandom（默认已挂，但有些安全策略会删）；检查securityContext.privileged: false下设备是否可读 - 避免在容器里跑
haveged或rng-tools这类服务——它们确实能补熵，但引入额外运维负担，且可能被安全团队否决；JVM参数方案更轻量、更可控
真正麻烦的是那些没权限改启动参数的老系统，或者数据库驱动自己偷偷调用SecureRandom（比如某些MySQL Connector/J版本在SSL握手时），这时候得盯紧strace -e trace=open,read -p $PID看它到底在读哪个设备文件。
立即学习“Java免费学习笔记（深入）”；
