4、connectTimeout（连接超时）详解：定义、默认值、调优策略

4.1 到底什么是连接超时？

连接超时（connectTimeout），说白了就是客户端发起 TCP 握手后，愿意等待服务端响应的最长时间。

我给你拆解一下过程：

• 你的应用调用 getConnection()
• 连接池拿出一个空闲连接，或者新建一个 Socket
• Socket 开始三次握手 —— SYN、SYN-ACK、ACK
• 如果网络丢包、服务端负载过高、防火墙丢包…… 握手一直完不成
• 超过 connectTimeout 后，抛出超时异常，连接建立失败

这个参数控制的就是“我最多等多久”。

4.2 默认值是多少？

在 DSPM 场景下，连接池通常使用 Druid、HikariCP 或 DBCP。各框架的默认值差异很大：

你想想看，DBCP2 和 c3p0 的默认值其实挺危险的。我曾经在生产环境下吃过一次亏——凌晨流量上涨，数据库连接积压，DBCP2 默认不超时，线程全部 hang 住，最后 OOM 了。从那以后我接手项目第一件事：检查连接超时参数。

4.3 调优策略：核心原则与具体操作

调优没有万能公式，但有三个核心原则：

1. 不要用默认值 —— 尤其是无限等待的默认值。
2. 根据业务响应时间定 —— connectTimeout 应略小于业务方愿意等待的最长时间。
3. 结合重试次数一起决定 —— 超时后如果立即重试，总等待时间 = connectTimeout × 重试次数。

4.4 我常用的调优步骤

1. 确认网络基线：用 ping 或 tcping 测一下客户端到服务端的延迟。如果内网延迟 1ms，设置 3000ms 都嫌长。如果跨机房延迟 50ms，设置 5000ms 就还能接受。
2. 观察历史超时日志：翻一翻生产日志，之前发生超时的连接等待了多久？是刚好 10 秒还是 1 秒就断了？这能帮你找到合理的下限。
3. 从高往低调：我建议第一次调优时先设一个宽松的值（比如 8000ms），运行一周，观察超时比例。如果超时率低于 0.1%，可以再砍掉 20%。
4. 配合连接池其他参数：比如 maxWait（获取连接的最大等待时间）、validationQuery（连接有效性检查）。connectTimeout 和它们要协同。

4.5 避坑指南

• 我曾经遇到一个坑： 把 connectTimeout 设成 100ms，觉得反正内网快。结果数据库偶尔 GC 停顿 200ms，所有连接全部超时，业务直接熔断。后来我改成 2000ms，问题消失。
• 还有一个坑： 服务端开启了 TCP backlog 限制，大量连接排队。connectTimeout 设得再大也没用，因为连接根本不会被 accept。这时候要调的是服务端 backlog 和连接池的 maxActive。
• 注意 JDBC 驱动的差异： MySQL JDBC 驱动默认 connectTimeout 是 0（无限等待），需要显式设置 connectTimeout=3000。Oracle 的 thin 驱动也有类似行为。

4.6 什么时候该增大？什么时候该减小？