HikariCP需配置keepalive-time（如240000）并确保小于MySQL wait_timeout（如300），配合minimum-idle>0、驱动支持isValid()，才能主动保活空闲连接，避免通信中断。
Java应用连MySQL后空闲几分钟就断连？先看是不是HikariCP没配活检
不是数据库主动踢人，就是连接池自己“睡死”了——hikaricp默认不发心跳，空闲连接靠数据库端dcd（dead connection detection）或tcp keepalive被动清理，但这两者通常都太慢（linux默认2小时），导致应用一用就报 communications link failure 或 connection reset。
解决路径很明确：让HikariCP主动探测空闲连接是否还活着，而不是等它断了再重连。
-
connection-test-query在旧版HikariCP中可用，但v5.0+已废弃，别再写 - 真正起效的是
connection-init-sql+keepalive-time组合，且必须配合数据库支持的轻量探测语句 - MySQL 8.0.22+ 推荐用
SELECT 1；老版本确认SELECT 1能走快速路径（不触发权限检查、不进查询缓存） -
keepalive-time不是“每X秒发一次心跳”，而是“空闲连接存活多久后触发一次验证”，单位毫秒，建议设为30000（30秒），比数据库wait_timeout小至少1分钟
HikariCP keepalive-time 和 MySQL wait_timeout 怎么对齐
如果 keepalive-time 设得比MySQL的 wait_timeout 还大，那等于没做——连接早被MySQL关了，HikariCP才去探，结果还是报错。
查MySQL当前设置：SHOW VARIABLES LIKE 'wait_timeout';，常见值是300秒（5分钟）或28800秒（8小时）。生产环境建议调低到300~600秒，再让HikariCP在它之前探活。
- 设
keepalive-time=240000（4分钟），wait_timeout=300（5分钟）：安全，留出1分钟缓冲 - 设
keepalive-time=600000（10分钟），wait_timeout=300：必断，HikariCP永远赶不上 - 注意：MySQL的
interactive_timeout对连接池无效，不用管它 - PostgreSQL用户请换用
validation-timeout+connection-init-sql=SELECT 1，PG原生不支持keepalive-time
为什么加了 keepalive-time 还是断连？检查这三处硬伤
配置写了不等于生效。HikariCP的keepalive机制有隐含前提，漏掉一个就白配。
立即学习“Java免费学习笔记（深入）”；
- HikariCP v4.0.3+ 才正式支持
keepalive-time，旧版本（如3.x）写了也忽略，升级前先查HikariDataSource.class.getPackage().getImplementationVersion() -
minimum-idle必须 > 0，否则没有空闲连接可保活；设成5比0更稳妥 - 数据库驱动必须支持
isValid(int)方法，MySQL Connector/J 8.0.23+ 没问题，但某些定制JDBC驱动可能返回false或抛异常，导致keepalive失败后直接丢弃连接 - 日志里搜
keepalive关键字，HikariCP在DEBUG级别会打印 “Keep alive check passed/failed for connection”，没看到说明根本没触发
要不要开 TCP keepalive？和 HikariCP keepalive-time 冲不冲突
要开，但不是替代方案，是兜底手段。HikariCP的 keepalive-time 是应用层探测，TCP keepalive 是内核层保活，两者作用域不同，不冲突。
Linux下通过JVM参数打开：-Dsun.net.client.defaultConnectTimeout=5000 -Dsun.net.client.defaultReadTimeout=30000 -Dnetworkaddress.cache.ttl=60，但这只是DNS缓存，不是TCP keepalive。
- 真正开启TCP keepalive需操作系统级配置：修改
/proc/sys/net/ipv4/tcp_keepalive_time（默认7200秒），建议调到600（10分钟） - JVM无法直接控制TCP keepalive，但可通过
Socket.setKeepAlive(true)委托给OS，HikariCP底层连接创建时已自动设置 - 如果你的网络中间有NAT网关或云LB（如AWS ALB），它们常自带连接空闲超时（默认350秒），这时光靠应用层keepalive不够，必须同步调低LB的idle timeout
最麻烦的情况是：数据库设了300秒wait_timeout，云LB设了350秒idle timeout，HikariCP keepalive-time设了240秒，但驱动层 isValid() 因网络抖动偶尔超时失败——这时候连接会被池回收，下次取用时才发现已断。这种瞬时故障没法完全避免，只能靠重试逻辑兜住。
