SecureRandom 为什么比 Random 更适合加密场景
因为 Random 是伪随机、可预测的线性同余算法，种子一旦暴露或被猜中，整个序列都能还原；而 SecureRandom 默认从操作系统采集熵（如 /dev/urandom 或 Windows 的 BCryptGenRandom），输出不可预测、抗回溯，满足密码学强度要求。
常见错误现象：用 Random 生成 JWT 密钥、API token、盐值（salt），导致系统被批量破解。
使用场景包括：generateKeyPair() 前的随机数、MessageDigest 加盐、OAuth2 code verifier、一次性验证码（非短信类）。
初始化 SecureRandom 的三种方式及风险差异
不同构造方式直接影响熵源和性能，尤其在容器或低熵环境（如 Docker 容器、CI 环境）下表现差异极大。
立即学习“Java免费学习笔记（深入）”；
-
new SecureRandom()：默认使用最佳可用算法（JDK 8+ 通常是SHA1PRNG或NativePRNG），但某些旧 JDK 在容器里会卡住或退化为SHA1PRNG+ 时间种子 → 不安全 -
SecureRandom.getInstance("SHA1PRNG")：明确指定但依赖用户种子，若未调用setSeed()，可能复用默认时间种子 → 可预测 -
SecureRandom.getInstance("NativePRNG")或"NativePRNGNonBlocking"：直连 OS 熵池，更可靠；但NativePRNG在读取/dev/random时可能阻塞，NativePRNGNonBlocking则始终用/dev/urandom→ 推荐用于生产
实操建议：JDK 8u161+ 直接用 new SecureRandom() 即可；老版本或容器环境，显式指定 SecureRandom.getInstance("NativePRNGNonBlocking")。
生成固定长度的随机字节数组（最常用操作）
几乎所有加密级随机需求都落在「获取 n 字节随机数据」上，比如生成 32 字节 AES 密钥、16 字节 IV、64 字节 token。
错误写法：new BigInteger(128, new SecureRandom()).toString(16) —— 长度不固定、高位零丢失、十六进制编码引入偏差。
正确做法是直接操作字节数组：
byte[] bytes = new byte[32]; new SecureRandom().nextBytes(bytes); // ✅ 安全、定长、无偏移
注意点：
- 不要重复复用同一个
SecureRandom实例做大量nextBytes()—— 虽然线程安全，但某些算法（如SHA1PRNG）内部状态更新慢，高并发下可能成为瓶颈 - 避免在循环里反复新建
SecureRandom实例 —— 初始化开销大（尤其 NativePRNG），应复用 - 若需 Base64 编码结果，用
Base64.getEncoder().encodeToString(bytes)，别手写 hex 或自定义编码
SecureRandom 在 Spring Boot 和单元测试中的典型陷阱
Spring Boot 自动配置的 SecureRandom Bean 默认是单例且无参构造，看似省事，但在测试环境下容易出问题。
常见错误现象：
- JUnit 测试并行执行时，多个 test class 共享同一
SecureRandom实例，导致部分测试因熵不足失败（尤其 macOS CI） - Mockito mock
SecureRandom后忘记重置，后续测试拿到空实例或错误状态 - Spring 的
@Bean定义没加@Scope("prototype")，导致 WebFlux 多线程请求共用一个实例，吞吐下降
实操建议：
- 测试中用
SecureRandom.getInstanceStrong()替代默认构造（它强制选最强实现，且不缓存） - 生产 Bean 定义时显式指定算法：
@Bean public SecureRandom secureRandom() { return SecureRandom.getInstance("NativePRNGNonBlocking"); } - 避免在 @PostConstruct 或 static 块里提前触发
SecureRandom初始化 —— 容器启动阶段熵可能不足
真正难处理的是冷启动时的首次调用延迟，特别是在 Kubernetes Init Container 或 Serverless 环境里，/dev/urandom 初始化可能卡几十毫秒，这点很容易被监控忽略。
