Java应用高负载下Oracle连接池泄露原因与排查

在Java应用与Oracle数据库的交互中，“连接池泄漏”这个词常常让人如临大敌，但真正诡异的是：很多时候，你的代码已经把close()写得妥妥帖帖，数据库连接数却仍在蹭蹭上涨。这背后的根源，远非一句“忘记调用close”那么简单。

本质上，Connection.close()只做了一件事：在JDBC驱动的层面，把这连接标记为“可复用”。至于它是否真的归还给连接池、归还后能否被再次成功使用，完全取决于HikariCP或Druid等连接池的具体实现，以及Oracle网络层的当前状态。比如，TNS层留下的半开连接——网络中断时驱动没感知到断连，close()可能就默默阻塞甚至失败。再比如，HikariCP检测到连接异常时，会直接丢弃而不是回收，这就造成了“已close但活跃数不降”的假象。更隐蔽的是，从Oracle JDBC驱动12.2.0.1+开始，implicitCachingEnabled默认开启。如果上一个业务没调用preparedStatement.clearCache()，复用该连接时隐式缓存不断膨胀，最终触发ORA-01000: maximum open cursors exceeded。这还没完，连接池的超时参数如果和Oracle网络层的SQLNET.EXPIRE_TIME不匹配，连接在池里“假活”数小时也是常有的事。

高负载下，泄漏的放大效应

低流量时岁月静好，一旦请求激增，那些隐性缺陷就集中爆发了。这里有三个关键放大器需要留意：

第一，超时参数的错位。如果connection-timeout设得太小，比如1000毫秒，大量线程会卡在“取连接”阶段，监控显示活跃连接数不涨，但应用整体已经僵住。反过来，如果设得太大，比如60000毫秒，故障感知严重滞后，DBA那边看到会话数飙升，却一时找不到源头。

第二，校验机制缺失。禁用testOnBorrow后，如果没配connection-init-sql或keepaliveTime，连接复用前就没有轻量校验。等到第一次执行SQL时，TNS错误才暴露出来，但此时已经进入了业务逻辑，finally块里的close()很可能因为异常而跳过。

第三，废弃配置的后患。Druid的removeAbandonedOnBorrow=true早该退役了，但如果老配置还残留，它会在借连接时强制回收“疑似泄漏”的连接。高负载下判断失准，频繁回收健康连接，引发雪崩式的重连和游标泄漏。

别猜了，直接问数据库

排查泄漏问题，别只盯着应用日志，数据库侧的真实连接状态才是铁证。直接查v$session视图，找到那些last_call_et大于300秒且状态依然是ACTIVE的会话——这就是典型的“假活”连接。再交叉对比v$open_cursor里各个会话的游标数，如果某几个sid的游标数持续超过300，基本可以锁定对应的应用线程没清理PreparedStatement。

同时检查v$process的pga_used_mem和v$session的program字段，确认高内存占用进程是否来自Java应用。更聪明的一招是结合AWR报告，看“SQL ordered by Parse Calls”指标。如果某条简单SQL的解析次数远高于执行次数，说明应用在反复创建新的PreparedStatement，而不是复用——这往往是隐式缓存失效或压根没使用预编译语句缓存的信号。

三处配置硬伤，必须改

下面这几条不是“建议”，而是Oracle生产环境连接池的底线配置。

• HikariCP参数：connection-timeout=30000（建议小于等于DBA设置的SQLNET.EXPIRE_TIME * 1000），validation-timeout=3000，keepaliveTime=300000（5分钟心跳），禁用testOnBorrow，启用connection-init-sql，比如ALTER SESSION SET CURRENT_SCHEMA=xxx。
• Oracle JDBC URL：必须显式关闭隐式缓存，加上implicitCachingEnabled=false&oracle.jdbc.useFetchSizeWithLongColumn=true，避免驱动层缓存干扰连接池管理。
• 代码写法：所有Connection获取必须包裹在try-with-resources语句中，禁止在if/else分支里手写close()。如果不得已用finally，务必加上双重检查：connection != null && !connection.isClosed()。

最容易忽略也最关键的一点是：Oracle连接池泄漏往往不是单点代码bug，而是连接池参数、驱动行为、数据库网络策略、应用编码习惯四者错位叠加的结果。所以查问题时，别先急着翻Java堆栈。先去数据库里跑一遍v$session和v$open_cursor——数据库比你的应用更清楚到底是谁拿了连接不还。