GraalVM原生模式下JFR显示sun.security.provider.SecureRandom高阻塞问题

问题场景 #

• 技术栈：Micronaut框架 + GraalVM JDK
• 核心功能：仅负责读取Cosmos文档并返回响应
• 触发路径：调用Cosmos数据库时，依赖sun.security.provider.SecureRandom生成随机数
• 观测到的问题（JFR结果）：
  • 线程区域存在Java监视器阻塞
  • sun.security.provider.SecureRandom的锁实例导致长时间阻塞
• 对比验证：相同代码在Azul Java JDK运行时无此阻塞问题

原因分析 #

GraalVM JDK与Azul JDK对SecureRandom的实现逻辑存在关键差异：

• GraalVM默认的sun.security.provider.SecureRandom采用了同步锁机制生成随机数，高并发场景下多个线程竞争同一锁实例，直接引发阻塞。
• Azul JDK对SecureRandom做了并发优化（比如内置ThreadLocalRandom适配、无锁生成逻辑等），从根源上避免了锁竞争问题。

解决方案 #

1. 切换非阻塞SecureRandom算法 #

通过JVM参数或代码显式指定非阻塞的随机数生成算法，绕过同步锁逻辑：

• JVM参数配置：

  -Djava.security.egd=file:/dev/./urandom
  -Dsecurerandom.source=file:/dev/./urandom
  

• 代码中显式初始化：

  SecureRandom secureRandom = SecureRandom.getInstance("NativePRNGNonBlocking");
  

2. 用ThreadLocalRandom替代（非加密场景） #

如果业务场景不需要加密级别的随机数，直接使用线程本地的ThreadLocalRandom，完全避免锁竞争：

ThreadLocalRandom.current().nextInt();

3. 升级GraalVM版本 #

部分旧版本GraalVM存在SecureRandom的并发性能缺陷，尝试升级到最新稳定版，官方可能已经修复相关锁阻塞问题。

4. 自定义Cosmos客户端的随机数生成器 #

检查Cosmos客户端的配置文档，看是否支持注入自定义的SecureRandom实例，通过Micronaut的配置类替换默认实现，从调用源头规避锁竞争。

内容的提问来源于stack exchange，提问作者deepak singh