2、超时参数总览：常见的超时参数

说到连接池的超时参数，说白了就是给每个环节定一个“等待上限”。没这些参数，连接池一旦遇到网络抖动或服务端变慢，整个系统就可能挂掉。我刚接手一个金融项目时，就因为 readTimeout 没设好，生产上大批请求阻塞——嗯，从那以后我对每个超时参数都特别敏感。

这一节我们把最常见的几个参数过一遍。你想想看，一个连接从创建到销毁，会经历几个阶段：建立连接、发送请求、等待响应、空闲闲置、然后被回收。每个阶段都有一个对应的超时参数在管着。下面这张图能帮你快速建立整体认知：

2.1 connectTimeout —— 连接超时

这个参数管的是客户端与服务端建立 TCP 连接的最大等待时间。我遇到过好几次线上事故，都是因为 connectTimeout 设得太大（比如 30 秒），服务端挂了之后客户端还在傻等——白白浪费线程。

个人习惯：内网服务我一般设 1~2 秒，公网或跨机房设 3~5 秒。超过这个时间还没连上，基本可以认为网络有问题或服务挂了，不如快速失败。

2.2 readTimeout —— 读取超时

连接建立后，发送请求后等待服务端响应数据的时间。这其实是最容易被忽略的参数。有一次，我团队里一个同事把 readTimeout 设成 60 秒，结果数据库有慢查询时，连接池很快就被占满了，其他请求全排着队等——死锁了。

我的建议：readTimeout 应该与服务端接口的 TP99 响应时间对齐，再留个 1.5~2 倍的余量。比如接口 TP99 是 200ms，设 500ms 就够。别动不动就搞 30 秒，那是给自己埋雷。

2.3 idleTimeout —— 空闲超时

连接在池子里啥也不干，空闲太久就会被清理掉。为什么要有这个参数？因为数据库或中间件服务器可能会主动断开空闲连接（比如 MySQL 的 wait_timeout），如果连接池不知道，拿着一个已经断开的连接去用就会报错。

我踩过的坑：之前有一个项目把 idleTimeout 设成了 8 小时，而数据库那边 4 小时就踢空闲连接了。结果每天晚上定时任务跑完就会炸一波。后来我把 idleTimeout 改成 30 分钟，再配合 testOnBorrow 验证连接，问题就消失了。

2.4 其他重要超时参数

除了上面三个，实际中还会遇到几个参数，我简要列一下：

参数名	作用	典型值	备注
acquireTimeout	从连接池获取连接的最大等待时间	1000~5000 ms	超过则抛出异常，防止请求无限排队
maxWait	连接池无可用连接时线程等待的最大毫秒数	3000 ms	很多框架里就是 acquireTimeout 的别名
removeAbandonedTimeout	连接被占用但未归还的最大时间（防止泄漏）	60~300 s	要配合 removeAbandonedOnBorrow 使用
timeBetweenEvictionRunsMillis	后台线程清理空闲连接的间隔	30000 ms	通常与 idleTimeout 配合

你想想看，这些参数其实就是一个“等待矩阵”——每个环节都有个超时兜底，防止恶意慢查询或网络抖动拖垮整个系统。

2.5 参数之间的关系与调优思路

这几个参数不是孤立的。举个例子，如果把 idleTimeout 设得很小（比如 5 秒），而 timeBetweenEvictionRunsMillis 却很大（比如 60 秒），那空闲连接实际上会在池里待满 60 秒才被清理——跟设了个 60 秒的 idleTimeout 效果一样。所以调整时要一起考虑。

我常用的做法：先确定 connectTimeout 和 readTimeout（这两个直接影响外部调用），然后再根据业务空闲特征调 idleTimeout 和 acquireTimeout。最后通过压测观察连接池活跃数、等待队列长度，微调参数。