testonborrow应在强一致性、网络不稳定或连接泄漏风险高时启用，每次获取连接必验但增加1–3ms延迟；testonreturn不推荐开启，因回收时校验加重性能负担且必要性低。
testOnBorrow：用连接前必检，安全高、代价实
设为 true 时，每次调用 getConnection()，连接池都会执行一次 validationQuery（如 SELECT 1）确认连接还活着。这能拦截被数据库主动断开（如 MySQL 的 wait_timeout 触发）或网络闪断导致的失效连接。
但它带来确定性开销：每获取一次连接就多一次网络往返，在高并发场景下可能增加 1–3ms 延迟，QPS 显著下降——压测中 DB CPU 突增常源于此误配。
- 适合场景：金融类强一致性事务、数据库网络不稳定（如跨云/边缘节点）、遗留系统连接泄漏风险高
- 不推荐场景：常规 Web API、读多写少的后台服务、已启用
testWhileIdle且 idleTime - 配套必须配置：
validationQuery（如SELECT 1），validationQueryTimeout（建议 ≤ 1 秒，防 hang）
testOnReturn：归还时校验，意义有限、慎用
设为 true 时，连接在 close() 归还给池之前会做一次有效性检查。但实际价值很低：
- 业务代码通常不会在异常路径下归还连接（比如 SQLException 后直接丢弃连接）
- 即使校验失败，也只是销毁该连接，不解决“下个线程借到坏连接”的问题
- 额外增加一次 DB 往返，却没换来实质可用性提升
生产环境几乎从不开启。Druid 官方文档和京东云、阿里中间件团队实践均明确指出：testOnReturn 应保持 false。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
更合理的替代方案：靠 testWhileIdle + 合理超时组合
真正兼顾性能与健壮性的主流做法是：
-
testWhileIdle = true：启用空闲连接后台巡检 -
timeBetweenEvictionRunsMillis = 30000（30 秒跑一次） -
minEvictableIdleTimeMillis = 60000（空闲超 60 秒才参与检测） -
validationQuery = SELECT 1+validationQueryTimeout = 1
这样既避免每次借连接都查库，又确保空闲连接在被重用前大概率已被清理。只要巡检间隔小于数据库的 wait_timeout（如设为 240 秒，而 MySQL wait_timeout=300 秒），就能覆盖绝大多数连接失效场景。
异常兜底：应用层捕获并重试比配置更可靠
即使所有检测都关闭，也不代表系统脆弱。更推荐的做法是：
- DAO 层统一捕获
SQLException中的连接异常码（如 MySQL 的CommunicationsException、Connection refused） - 对这类错误做轻量级重试（最多 1 次），再抛出业务异常
- 配合监控告警（如 Druid 的
ConnectionErrorCount指标突增）快速定位网络或 DB 问题
这种“检测下沉 + 快速恢复”策略，比把压力全压给连接池配置更可控、更可观测。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
