根本原因是三层配置错位：JDBC驱动层socketTimeout=0默认无限等待、Docker容器时区未固化导致认证延迟、Oracle服务端sqlnet.inbound_connect_timeout=60秒与中间设备超时冲突，需同步调整socketTimeout≥60000、ENV TZ=Asia/Shanghai固化时区、服务端该参数调至120秒及以上。
Java 17 在 Docker 容器中连接 Oracle 经常超时，根本原因不是 Java 版本本身的问题，而是三层叠加的配置错位：JDBC 驱动层参数缺失、容器网络环境不稳定、Oracle 服务端限制未对齐。单纯升级 Java 或重试连接，大概率无效。
socketTimeout=0 是默认陷阱
Oracle JDBC Thin 驱动（ojdbc11.jar 或 ojdbc8.jar）在 Java 17 下仍默认 socketTimeout=0，即无限等待 TCP read。一旦遇到防火墙静默丢包、中间设备 kill 空闲连接、或数据库进程僵死，线程就永久卡住——表现为“连接超时”，但实际是卡在读响应阶段。
-
socketTimeout必须显式设置，单位毫秒，建议设为60000（60 秒） - 它必须大于
queryTimeout（SQL 执行超时，单位秒）+cancelQueryTimeout（取消指令耗时），否则 cancel 过程自身就触发 socket 断连 - JDBC URL 中加
?connectTimeout=30000对 Oracle 驱动无效，官方明确不支持
Docker 容器内时区错配引发隐性阻塞
报错 timezone region not found 表面是时区异常，实则会干扰 Oracle 认证流程：JDBC 驱动在构造连接时若无法解析本地时区，可能 fallback 到不兼容的时区处理逻辑，导致认证响应延迟或失败，最终被 sqlnet.inbound_connect_timeout 截断（默认 60 秒）。
- 必须在
Dockerfile中固化时区：ENV TZ=Asia/Shanghai+RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone - 仅靠
docker run -e TZ=Asia/Shanghai不可靠，部分基础镜像忽略该环境变量 - 验证方式：进容器执行
date和ls -l /etc/localtime，确认软链指向正确 zoneinfo 文件
连接池耗尽伪装成网络超时
错误信息 Connection request timed out（来自 Oracle.ManagedDataAccess.Client）或 Java 侧 java.sql.SQLTimeoutException: Connection could not be acquired from connection pool，90% 情况下不是连不上库，而是连接池空了。
立即学习“Java免费学习笔记（深入）”；
- 检查
ActiveConnections是否持续逼近Max Pool Size；同时查数据库端v$session，若会话数远小于池活跃数，说明连接没归还 -
Min Pool Size设太高（如 20）会导致冷启动时一次性建满连接，加重监听器压力 -
Connection Lifetime设太长（如 300 秒）会让已断开的连接滞留池中，复用时直接失败
服务端 sqlnet.inbound_connect_timeout 是关键瓶颈
看到 ORA-12170: TNS:Connect timeout occurred 或客户端卡在 “Connecting” 60 秒后失败，问题基本不在 JDBC 层——驱动甚至还没开始走用户名密码认证，TCP 连接就被拦住了。
- 真正控制“从 SYN 包发出到 Oracle 完成认证”的是服务端
sqlnet.ora中的sqlnet.inbound_connect_timeout，默认 60 秒 - 防火墙、F5、Nginx 等中间设备空闲超时也常设为 60 秒，若未启用 TCP keepalive 或未透传，必然触发此错
- 需同步调大服务端该参数（如设为
120），并确保容器到 DB 的路径上所有设备超时 ≥ 此值
最易被忽略的点：Java 17 的 TLS 1.3 默认启用，而老旧 Oracle 12c（尤其未打 PSU 补丁的）可能不兼容，导致握手卡顿，最终被 sqlnet.inbound_connect_timeout 终止。验证方式是抓包看 TLS handshake 是否完成，而非只盯着超时数字。
