MySQL连接未释放，本质是应用层没有正确关闭数据库连接，导致连接数持续增长，最终可能耗尽连接池或达到MySQL的
max_connections上限，引发“Too many connections”错误。关键不在MySQL本身，而在应用程序的连接使用逻辑。
确认是否真有连接泄漏
先别急着改代码，用MySQL命令验证当前连接状态：
登录MySQL执行：SHOW PROCESSLIST;，观察大量处于
Sleep状态且
Time值持续增长的连接（尤其是远超应用正常等待时间的） 查总连接数：
SHOW STATUS LIKE 'Threads_connected';，对比业务低峰期与高峰期的差异 检查历史峰值：
SHOW VARIABLES LIKE 'max_connections';，如果
Threads_connected频繁接近该值，风险已存在
常见泄漏场景和修复方向
绝大多数泄漏源于开发中对连接生命周期的疏忽：
忘记调用 close()：JDBC中未在finally块或try-with-resources中关闭
Connection、
Statement、
ResultSet异常绕过关闭逻辑：try块抛出异常后，若关闭代码只写在try末尾而没进finally，连接就卡住了 连接被意外“持有”：比如把Connection存入静态变量、ThreadLocal未清理、或DAO对象长期缓存连接 连接池配置不当：如HikariCP的
connection-test-query未设、
leak-detection-threshold未开启，导致泄漏难以及时发现
快速定位泄漏点的方法
不依赖日志也能高效排查：
启用连接池的泄漏检测：HikariCP加配置leak-detection-threshold=60000（单位毫秒），超时未关闭会打印堆栈 MySQL端配合：设置
wait_timeout和
interactive_timeout为较低值（如60秒），让空闲Sleep连接更快被MySQL主动断开，暴露问题 应用侧加监控：通过Actuator（Spring Boot）或Micrometer暴露连接池指标，观察
active、
idle、
total变化趋势 代码扫描：搜索项目中所有
new Connection、
DriverManager.getConnection或
dataSource.getConnection()调用，逐个检查是否有配套close
预防比修复更重要
从工程实践层面减少人为失误：
强制使用try-with-resources（Java 7+），自动关闭资源，语法清晰不易遗漏 统一使用连接池（如HikariCP），禁用DriverManager直连；连接池本身具备连接回收、心跳检测、泄露预警能力 单元测试中模拟异常路径，验证连接是否仍能释放 上线前做连接数压测：单接口反复调用，观察
Threads_connected是否回归基线
连接泄漏不是MySQL的问题，而是应用与数据库交互契约的断裂。盯住连接获取与释放的配对关系，再辅以工具辅助，基本就能稳住连接健康度。
