java应用连接泄漏表现为v$session活跃会话数远超连接池maxpoolsize，根本原因是resultset/statement/connection未用try-with-resources或finally正确关闭，导致连接无法归还，结合hikaricp activeconnections持续上涨、idleconnections长期为0及oracle侧program/machine字段可精准定位泄漏模块。
查 v_$session 时发现会话数远超应用连接池配置
这基本说明 Java 应用没正确释放连接，而不是数据库侧配置问题。先确认当前活跃会话数：SELECT COUNT(*) FROM v_$session WHERE status = 'ACTIVE' AND type = 'USER'。如果结果明显高于你设置的 HikariCP 或 Druid 的 maximumPoolSize（比如池设为 20，但查出 150+ 活跃会话），就不是连接池“不够用”，而是连接泄漏。
ResultSet / Statement / Connection 没用 try-with-resources 包裹
这是最常见原因：JDBC 查询后没显式关闭资源，尤其在异常分支里容易漏掉。哪怕只读查询，Connection 不 close 就不会归还给池，Statement 和 ResultSet 不关可能让 Oracle 侧会话状态卡住。
- 错误写法：
Connection conn = dataSource.getConnection(); Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("..."); // 忘了 close - 正确写法：必须三层嵌套
try-with-resources，或至少保证finally中按rs → stmt → conn逆序关闭 - 注意：Spring 的
JdbcTemplate默认自动管理，但手写 JDBC 或用了DataSourceUtils时仍要自查
连接池监控指标暴露真实泄漏点
光看数据库会话数不够，得结合连接池运行时指标。以 HikariCP 为例，访问 /actuator/metrics/hikaricp.connections.active（Spring Boot Actuator）或 JMX 的 ActiveConnections、IdleConnections、ThreadsAwaitingConnection。
- 如果
ActiveConnections持续上涨不回落，且IdleConnections长期为 0，基本确定有连接未归还 -
ThreadsAwaitingConnection非零 +ActiveConnections达上限，说明新请求被阻塞，不是泄漏是池太小；但若它为 0 而ActiveConnections还在涨，就是泄漏 - Druid 提供
/druid/index.html控制台，重点关注 “ActiveCount” 和 “PoolingCount” 差值是否稳定
Oracle 侧 v_$session 中的 program 和 machine 字段能快速归因
执行：SELECT sid, serial#, username, program, machine, osuser, logon_time FROM v_$session WHERE status = 'ACTIVE' AND type = 'USER' ORDER BY logon_time。重点看：
-
program：Java 应用通常显示为jdbc thin client或具体类名（如MyAppService），若大量会话 program 相同，对应模块大概率有问题 -
machine：确认是不是来自同一台应用服务器，排除多实例误配 -
logon_time：如果一批会话登录时间集中在某几分钟内，和某次发布/定时任务触发时间吻合，就能锁定代码变更点 - 注意：
username为空的会话可能是后台线程，别误杀；真正要盯的是username有值且program可识别的那些
真正难的是区分“短时激增”和“持续累积”——前者可能是突发流量，后者才是泄漏。不要只截一张 v_$session 快照，至少每分钟采样一次，持续 5 分钟看趋势。会话数随时间线性增长，比绝对数值更有说服力。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
