为什么Java 8连接Oracle 12c会出现连接超时_检查Entropy源/dev/urandom配置-Oracle-PHP中文网

java 8 连接 oracle 12c 时快时慢的主因是 jvm 启动时阻塞于 /dev/random 熵不足，导致 jdbc 加密握手卡顿达 10+ 秒；应将 securerandom.source 统一设为 file:/dev/urandom 并升级至 ojdbc8 19.22+，同时检查数据库内置 jvm 和应用服务器配置。

java 8 连接 oracle 12c 时快时慢，大概率不是网络或 sql 问题，而是 jvm 启动时卡在 /dev/random 等待熵池填充 —— 这个阻塞会直接拖住 jdbc 建连，导致连接耗时从毫秒级跳到 10+ 秒。

为什么 `/dev/random` 会导致 JDBC 连接卡住

Oracle 12c JDBC 驱动（尤其是 ojdbc7/ojdbc8）在建立 SSL/TLS 或加密握手阶段，需要约 40 字节的强随机数。JVM 默认用 /dev/random 提供，而它在熵不足时会**阻塞读取**，直到内核收集够随机事件（键盘、磁盘、中断等）。容器环境、云主机、无外设虚拟机普遍熵低，strace 中常看到 open("/dev/random", O_RDONLY) 后卡在 futex 超时。

现象：SQL*Plus 连得快，Java 应用连得慢且不稳定 —— 因为 SQL*Plus 不走 JVM 随机数路径
验证方式：cat /proc/sys/kernel/random/entropy_avail，持续低于 100 就高风险
注意：改了 java.security 不生效？可能 JVM 是数据库内置 JVM（如 Oracle JVM）、或应用用了独立 JRE 但没改对路径

必须同时检查三处 `securerandom.source` 配置

只改 $JAVA_HOME/jre/lib/security/java.security 不够。Oracle 12c 的 JDBC 连接可能由不同 JVM 实例触发，尤其在 RAC、Data Guard 或中间件嵌入场景下：

$JAVA_HOME/jre/lib/security/java.security：主 JVM，改 securerandom.source=file:/dev/urandom
Oracle 数据库自身 JVM（如果启用了 JavaVM 组件）：需按 MOS 文档 ID 1594701.1 修改 init.ora 或用 DBMS_JAVA.SET_SYSTEM_PROPERTY 设置 securerandom.source
应用服务器（如 WebLogic、Tomcat）若自带 JRE，要确认它是否加载了自定义 java.security，或通过 -Djava.security.properties=... 指定了其他配置文件

`ojdbc8.jar` 和 Java 8 的兼容性陷阱

ojdbc8 要求 Java 8u121+，但某些旧版 ojdbc8（如 12.2.0.1）在 Java 8u151 上仍会回退使用 /dev/random —— 即使 java.security 已配 /dev/urandom。这不是 bug，是驱动内部对 SecureRandom 实例的硬编码初始化逻辑。

java-enterprise

Java企业开发专家，专注于Spring Boot、微服务架构和JVM优化。适用于：Java语言掌握、

下载

解决方案：升级到 ojdbc8 **19.22+** 或 ojdbc11（支持 Java 11+，但 Java 8 兼容模式下更稳定）
快速验证：启动时加 JVM 参数 -Djava.security.debug=secureRandom，看日志是否打印出实际使用的 SecureRandom 实现类和源路径
绕过方式（临时）：在连接前手动初始化一次 SecureRandom，例如 new SecureRandom().nextBytes(new byte[16])，可提前“唤醒”熵池

别漏掉 Oracle 网络层的协同超时

即使 JVM 层熵问题解决，SQLNET.EXPIRE_TIME 和防火墙空闲超时不匹配，也会造成连接“假死”，让连接池误判为可用连接，结果首次 query 时才暴露超时。

Linux 下检查：cat /proc/sys/net/ipv4/tcp_keepalive_time（默认 7200 秒），应远大于 SQLNET.EXPIRE_TIME
Oracle 侧设置：SQLNET.EXPIRE_TIME = 10（单位分钟），写入 $ORACLE_HOME/network/admin/sqlnet.ora
连接字符串里补上超时参数：connectTimeout=3000&socketTimeout=60000，避免单次操作无限挂起

真正棘手的是熵问题常被掩盖在连接池行为之下：连接池复用了一个看似“已建好”的连接，但底层 TCP 握手或 TLS 初始化阶段仍在等随机数 —— 此时你查不到任何 JDBC 日志，只能靠 strace -e trace=open,futex,connect -p <pid></pid> 抓系统调用。改完配置务必重启整个 JVM，不能只 reload 应用。