为何Java应用Oracle连接池会耗尽_检查连接泄漏点-Oracle-PHP中文网

连接池耗尽主因是连接“借出未还”，根源在代码未关闭资源或配置未兜住异常；connection.close()仅通知归还，实际回收取决于池状态，oracle场景下tns超时等易致连接“假活”；resultset/statement未关会先触发ora-01000；hikaricp需配leak-detection-threshold并debug日志定位泄漏点；dba应查v$session确认是否真泄漏。

连接池耗尽不是数据库连不上，而是连接“借出去没还”，根源几乎都在代码没关资源或配置没兜住异常路径。

Connection.close() 不等于连接归还给池

调用 connection.close() 只是通知连接池“我用完了”，实际是否回收、何时回收，取决于池的状态和配置。如果池已满、连接处于半开状态（比如网络中断后 Oracle 未主动断开），close() 可能静默失败或阻塞，连接就卡在“活跃但不可用”状态。

典型现象：ORA-01000: maximum open cursors exceeded 或监控显示 activeConnections 持续上涨，但 QPS 平稳
Oracle 场景下尤其危险：TNS 超时、防火墙空闲断连、RAC VIP 切换都可能让连接在池里“假活”
不要依赖 close() 的返回值或日志判断是否成功——它不抛异常，也不保证归还

未关闭 ResultSet/Statement 是泄漏高发区

很多人只记得关 Connection，却漏掉 ResultSet 和 Statement。Oracle 驱动中，这两个对象持有游标（cursor），不显式关闭会直接触发 ORA-01000，且这种泄漏会先于连接池耗尽暴露出来。

反例：ResultSet rs = stmt.executeQuery(...); 后没调 rs.close() 或 stmt.close()
try-with-resources 必须把三者都包进去：try (Connection c = ds.getConnection(); Statement s = c.createStatement(); ResultSet rs = s.executeQuery(...)) { ... }
若用 PreparedStatement，注意 Oracle 驱动 12.2.0.1+ 默认开启 implicitCachingEnabled=true，缓存绑定在 Connection 上；上一个使用者没调 clearCache()，复用时可能膨胀游标

HikariCP 泄漏检测必须配 leak-detection-threshold

光靠肉眼或日志很难定位哪段代码漏关——因为泄漏往往发生在异常分支。HikariCP 的 leak-detection-threshold 是唯一能自动抓出“借了不还”现场的机制，它会在连接被借用超过阈值后打印完整堆栈。

Gradle 9.8.0

Gradle 9.8.0 官方二进制分发包，适用于 Windows、macOS 与 Linux 的 Java、Kotlin 和 Android 项目构建。

下载

设为 60000（60 秒）较稳妥：太短会误报（如慢查询），太长则问题已蔓延
必须配合日志级别为 DEBUG 或 TRACE，否则堆栈不输出
启用后首次触发时，日志末尾会出现类似 Connection leak detection triggered for com.zaxxer.hikari.pool.HikariProxyConnection@12345678, stack trace follows，后面就是泄漏点代码行
注意：该参数仅用于诊断，上线后可保留但建议不低于 30000，避免高频日志冲垮磁盘

DBA 端查 `v$session` 能确认是否真泄漏

应用层看到连接池满，不等于数据库真满了。Oracle 的 v$session 是唯一权威来源，对比它和连接池的活跃数，才能区分是泄漏还是配置过小。

执行：SELECT COUNT(*) FROM v$session WHERE type = 'USER'
若结果远大于 HikariCP 的 getActiveConnections()，说明有连接被数据库端“挂起”（如 long-running query、锁等待），不是泄漏
若两者接近且持续增长，再结合 leak-detection-threshold 日志，基本可锁定泄漏代码
特别注意 STATUS = 'INACTIVE' 但 LAST_CALL_ET > 300 的会话——大概率是应用没关连接，Oracle 还没超时清理

真正难处理的不是“怎么关”，而是“关了但驱动或池没认账”。Oracle 的隐式缓存、TNS 层超时、连接池验证逻辑，三者叠加会让一次 close() 的语义变得模糊。排查时必须从数据库端 v$session 出发，再倒推应用日志和配置，不能只盯着代码找 close()。