最直接有效的手段是靠连接池自动回收空闲连接，需合理配置 idletimeout（建议2～5分钟）、maxlifetime（设为数据库 wait_timeout 的70%～90%）、leakdetectionthreshold（如60秒）及 minidle/maxpoolsize（如3～5和预留余量）。

靠连接池自动回收空闲连接，是防止资源被恶意占满最直接有效的手段。关键不是“等它出问题再处理”，而是提前用好 idleTimeout 和 maxLifetime 这两个参数，让连接在没人用、不该用的时候及时退出。

设置合理的空闲超时时间（idleTimeout）

这是防“占着不还”的第一道防线。只要连接归还后闲置超过设定时间，连接池就会主动关闭它。

• 默认值通常是 10 分钟（600000 毫秒），但生产环境建议调低到 2～5 分钟，尤其对响应敏感或连接数受限的系统
• 配置方式（以 HikariCP 为例）：config.setIdleTimeout(300000); // 5分钟
• 注意：这个值必须小于 maxLifetime，否则可能还没等到空闲回收，连接就因寿命到期被强制清理了

限制单个连接最大存活时间（maxLifetime）

哪怕连接一直被“假使用”（比如没真正执行 SQL，只 keep-alive），也要让它有个终点。这是防“长命僵尸连接”的兜底机制。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 推荐设为数据库服务端 wait_timeout 的 70%～90%（例如 MySQL 默认 wait_timeout=28800 秒即 8 小时，可设 maxLifetime=21600000 毫秒即 6 小时）
• 配置示例：config.setMaxLifetime(21600000);
• 避免设为 0 或 Long.MAX_VALUE，否则连接可能长期滞留，最终被数据库主动断开，而连接池还不知道，导致后续报 “Connection closed” 错误

配合连接泄漏检测与日志告警

空闲回收治标，泄漏检测治本。HikariCP 提供了连接未归还的追踪能力，能帮你揪出真正的问题代码。

• 开启泄漏检测：config.setLeakDetectionThreshold(60000); // 超过 60 秒未归还即告警
• 该阈值应明显大于业务最长 SQL 执行时间，但远小于 idleTimeout，避免误报
• 配合日志监控（如输出到 SLF4J），一旦发现泄漏，立刻定位到具体调用栈，而不是靠“重启缓解”

最小/最大连接数要匹配实际负载

空闲回收再快，也救不了配置失当的池子。如果 minIdle 设得过高、maxPoolSize 又没节制，照样会被撑满。

• minIdle 建议设为 3～5，够应对突发小流量，又不至于常年白占资源
• maxPoolSize 不要盲目设大，参考数据库允许的最大并发连接数（如 MySQL 的 max_connections），留出余量给其他服务
• 可通过监控观察 activeConnections / maxPoolSize 比率，持续高于 80% 就说明要么调大池子，要么优化慢 SQL 或连接持有逻辑

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南