java jdbc超时配置需分层协同：建连阶段用connecttimeout（mysql）或oracle.net.connect_timeout（oracle）；传输阶段统一设sockettimeout；连接池层配max-lifetime、keepalive-time并与服务端wait_timeout错配，禁用autoreconnect。
Java JDBC 配置超时时间，核心是分层控制：建连阶段、传输阶段、连接池管理阶段各司其职。单设一个参数无法防卡死，必须协同配置，否则容易出现“看着没报错，但线程一直挂住”的假死现象。
建连超时：防止DNS卡住或TCP连不上
只靠 connectTimeout 不够——它只管 TCP 三次握手，不处理 DNS 解析失败或 RAC 节点不可用。
- MySQL：在 JDBC URL 中加
?connectTimeout=3000（单位毫秒），建议 2~5 秒 - Oracle：优先用私有参数
oracle.net.CONNECT_TIMEOUT=5000，写在 TNS 描述符末尾，能覆盖 DNS + TCP 全流程 - 别混用
connectTimeout和oracle.net.CONNECT_TIMEOUT，驱动会以私有参数为准，混用行为不可预测
读写超时：避免查询卡在 socket 等待响应
这是“卡死”最常见原因：连接已建好，但 SQL 执行慢、结果集大、网络抖动，驱动还在等下一批数据。
- 统一用 socketTimeout（MySQL/Oracle/DM 均支持），例如
&socketTimeout=30000（30 秒） - Oracle 大结果集必须配
setFetchSize(Integer.MIN_VALUE)，否则默认缓存整结果集，极易触发超时 - socketTimeout 不能设为 0（禁用），也不宜过大（如 300000），否则掩盖慢 SQL 问题，让故障延迟暴露
连接池保活：防空闲连接被 MySQL 主动断开
即使 JDBC 层设了超时，若连接池长期复用同一条连接，而 MySQL 的 wait_timeout（默认 8 小时）先到期，下次使用就会抛 Communications link failure。
- HikariCP 推荐配置：
max-lifetime=1800000（30 分钟，比 MySQL 的wait_timeout少 2~5 分钟）keepalive-time=30000（心跳保活，需服务端开启 tcp_keepalive）validation-timeout=3000（校验连接有效性最多等 3 秒） - 禁用
autoReconnect=true：MySQL 8.0+ 已废弃，启用会导致事务不一致，重连逻辑应由连接池接管 - Druid 可配
testOnBorrow=true，但会降低性能；更推荐testWhileIdle=true+timeBetweenEvictionRunsMillis定期检测
服务端配合：超时配置必须两端对齐
Java 端再精细，若 MySQL 或 Oracle 服务端参数不协调，照样出问题。
- MySQL：调低
wait_timeout和interactive_timeout至 600~1800 秒（10~30 分钟），与连接池max-lifetime错开 - Oracle：检查监听器状态和数据库实例是否存活，
connectTimeout再小也救不了崩溃的实例——此时需要的是socketTimeout快速失败 - 所有数据库都建议关闭防火墙长连接自动中断策略，或确保中间设备（如 SLB）的 idle timeout > 连接池
max-lifetime
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
