SecureRandom 更适合密码学场景，因其依赖操作系统熵源（如 /dev/urandom），具备抗预测、抗重放特性，满足密码学不可预测性要求；而 Random 是伪随机、种子可预测、输出可重现。
SecureRandom 为什么比 Random 更适合密码学场景
因为 Random 是伪随机，种子可预测、输出可重现；SecureRandom 则依赖操作系统熵源（如 /dev/urandom 或 Windows 的 BCryptGenRandom），抗预测、抗重放，满足密码学意义的“不可预测性”。
常见错误现象：new Random().nextInt() 被用于生成 API token、盐值（salt）或一次性验证码，结果被批量碰撞或逆向推导。
- 使用场景：生成加密密钥、会话 ID、密码重置令牌、加盐哈希的 salt
- 不要在高安全要求场合用
Math.random()或Random，哪怕只是“临时用一下” - Java 8+ 中
SecureRandom.getInstanceStrong()会优先选最强算法（如DRBG），但可能阻塞——它会等足够熵，尤其在容器或低负载虚拟机中
如何正确初始化 SecureRandom 实例
直接调用 new SecureRandom() 看似简单，但底层可能 fallback 到不安全的 PRNG（比如某些 Android 版本或旧 JDK），且无法控制熵源行为。
推荐显式指定算法和提供种子（可选）：
立即学习“Java免费学习笔记（深入）”；
SecureRandom sr = SecureRandom.getInstance("SHA1PRNG"); // Java 8 默认，兼容性好
// 或更现代的选择（JDK 9+）：
SecureRandom sr = SecureRandom.getInstance("DRBG");
- 避免无参构造：它不保证算法强度，不同 JDK 版本行为不一致
-
"SHA1PRNG"在 Oracle/OpenJDK 中是确定性实现，但需注意：若传入相同种子，输出完全相同——所以除非你明确要可重现（如测试），否则**不要手动 setSeed()** - 生产环境别用
setSeed(System.currentTimeMillis())，时间戳熵极低，容易被爆破
生成字节数组、整数、长整数时的典型写法与坑
最常用的是生成随机字节，再转成 hex 或 base64；直接调 nextInt() 或 nextLong() 容易出边界或分布偏差问题。
- 生成 32 字节密钥：
byte[] key = new byte[32]; new SecureRandom().nextBytes(key); - 生成 0–999999 的 6 位验证码？别用
sr.nextInt(1000000)——虽然看起来没问题，但它基于内部 int 均匀分布，而nextInt(n)在 n 不是 2 的幂时存在轻微偏差（虽小但不符合密码学严谨性）；更稳妥是用字节 + 模运算并拒绝采样，或直接用RandomStringUtils.randomAlphanumeric(6)（Apache Commons） -
nextLong()返回的是全范围 long，但如果你只想要正数，别用Math.abs(sr.nextLong())——Long.MIN_VALUE取 abs 还是负数，会导致负值漏出
容器环境（Docker/K8s）下 SecureRandom 的卡顿与解决方案
Java 进程启动时，SecureRandom 首次调用可能卡住几秒甚至几十秒，尤其在无外设、无网络、低负载的容器里——因为默认尝试读 /dev/random，而该设备在熵不足时会阻塞。
- 典型错误现象：Spring Boot 应用启动慢、JWT 密钥生成超时、单元测试 hang 住
- 根本原因：JDK 默认配置为
securerandom.source=file:/dev/random（老版本）或依赖系统熵池 - 解决方式（任选其一）：
- JVM 启动参数加
-Djava.security.egd=file:/dev/urandom（注意是egd，不是seed） - 修改
$JAVA_HOME/jre/lib/security/java.security中的securerandom.source行 - 代码中提前触发一次
new SecureRandom().nextBytes(new byte[1])，在应用初始化早期“预热”
- JVM 启动参数加
真正麻烦的不是怎么选算法，而是很多人根本没意识到：容器里那台“空荡荡”的 Linux，连 1 bit 真随机都拿不出来。
