连接池配置不当不直接导致泄漏，但会掩盖或加剧泄漏：maxLifetime超数据库wait_timeout致“僵尸连接”；leakDetectionThreshold过松使借而不还难发现；validation-timeout大于connection-timeout造成连接“悬停”；禁用testOnBorrow又无替代机制引入“假活连接”；maxPoolSize过大与idleTimeout过短引发高频重建及残留。
连接池配置不当本身不直接“造成”连接泄露，但它会掩盖、放大或加速泄露的后果，让本可快速发现的问题变成缓慢积累的系统隐患。真正泄漏的源头是代码里没归还连接，而错误的配置会让这个过程悄无声息、难以察觉，甚至让连接池“帮倒忙”。
maxLifetime 设得比数据库 wait_timeout 还长
比如 MySQL 的 wait_timeout=28800秒（8小时），你却把 HikariCP 的 maxLifetime 设为 36000秒（10小时）。连接在池里“活”得比数据库允许的还久，等它被借出去时，数据库早把它关了——应用一执行 SQL 就报 “Connection is closed”。此时连接池通常不会主动回收它，而是等下次验证失败才处理，中间这段时间连接就卡在“活跃”状态却不干活，监控上看就是活跃数涨了、空闲数少了，像在悄悄泄漏。
leakDetectionThreshold 关得太松或干脆关了
这个参数是连接池的“哨兵”，用来抓那些借了不还的连接。默认值通常是 0（关闭），很多项目也从不启用。就算设了，如果阈值设成 60000 毫秒（1分钟），而某段代码因为死循环或阻塞卡住连接 90 秒，它也逃过了检测。结果就是：连接被借走后长期不归还，池子里可用连接越来越少，直到新请求拿不到连接，报 Cannot acquire connection from pool。
connection-timeout 和 validation-timeout 配反了
当 validation-timeout（验证超时）大于 connection-timeout（取连接超时），会出现一种诡异现象：线程在池里等连接，等了 3 秒（connection-timeout）就超时抛异常，但池子还在后台花 5 秒（validation-timeout）去验证一个刚失效的连接——这期间连接既没被用上，也没被及时清理，等于“悬停”在半空。高并发下这种悬停连接积少成多，监控指标里活跃数虚高，实际业务却卡在等待上。
立即学习“Java免费学习笔记（深入）”；
禁用 testOnBorrow 又没配替代机制
为减少性能损耗，有人直接关掉 testOnBorrow。但如果网络抖动、防火墙断连或 Oracle 的 SQLNET.EXPIRE_TIME 不匹配，池中就会混入一批“假活连接”——它们能通过 close()，但无法执行任何 SQL。应用拿到这种连接后，往往在业务逻辑深处才暴露错误，而此时 try-with-resources 的 finally 已经跳过，连接没真正归还。看起来是代码没关，根子其实是配置放过了坏连接。
maxPoolSize 过大 + idleTimeout 过短，引发高频重建
比如设 maxPoolSize=200，idleTimeout=60000（1分钟），连接刚空闲 60 秒就被强制销毁，紧接着又有请求进来，池子就得新建连接。频繁建连会加重数据库负担，更关键的是：每次新建都可能因网络或认证问题失败，而失败的连接对象若没被池子彻底清理干净，就可能滞留在内部集合中，表现为连接数缓慢爬升，就像在泄漏。
