connection.close() 并非真正释放连接，而是标记为可复用；是否归还取决于连接池状态，配置不当易致泄漏，需结合 oracle 网络超时、驱动隐式缓存及池参数（如 maxlifetime、connection-timeout）综合调优。
connection.close() 不等于连接真的归还给池
java 应用里调用 connection.close()，只是把连接标记为“可复用”，实际是否立刻归还、甚至是否真能归还，取决于连接池实现和当前状态。如果连接池已满、或连接处于异常状态（比如网络中断后未清理的半开连接），close() 可能静默失败或阻塞，导致连接长期滞留——这就是泄漏的起点。
常见错误现象：ORA-01000: maximum open cursors exceeded 或连接池监控显示活跃连接数持续上涨，但业务 QPS 并没明显增加。
- 必须确保
close()在finally块或 try-with-resources 中执行，不能只靠逻辑分支判断 - HikariCP 默认启用
connection-test-query（如SELECT 1 FROM DUAL），但 Oracle 12c+ 推荐用isValid(1)，更轻量且绕过 SQL 解析开销 - 若使用 Druid，注意
removeAbandonedOnBorrow=true已废弃，应改用removeAbandonedOnMaintenance=true+removeAbandonedTimeoutMillis
HikariCP 的 connection-timeout 和 validation-timeout 怎么配才不拖慢请求
connection-timeout 是从池里拿连接的等待上限，不是数据库响应超时；validation-timeout 是验证连接有效性的单次耗时上限。两者设得太小会导致频繁抛 HikariPool$PoolInitializationException 或 SQLTimeoutException，设太大又会让故障感知延迟。
Oracle 场景下特别要注意：TNS 超时、防火墙空闲断连、RAC VIP 切换都可能让连接在池中“假活”。单纯依赖 testOnBorrow 会在线上放大延迟。
-
connection-timeout建议设为 30000（30 秒），低于 DBA 设置的 OracleSQLNET.EXPIRE_TIME（通常 10 分钟） -
validation-timeout必须 ≤connection-timeout，推荐 3000（3 秒）——太短会误判健康连接，太长会让单个请求卡死 - 禁用
testOnBorrow，改用connection-init-sql=ALTER SESSION SET CURRENT_SCHEMA=xxx（轻量初始化） + 定期keepaliveTime（HikariCP 4.0.3+ 支持）
Oracle JDBC 驱动版本与 implicit caching 的冲突
Oracle 官方驱动从 12.2.0.1 开始默认开启 implicitCachingEnabled=true，它会在 Connection 内部缓存 PreparedStatement，但这个缓存生命周期绑定 Connection 实例——如果连接被池复用，而上一个使用者没显式 clearCache()，缓存可能膨胀或错乱，最终触发 ORA-01000。
立即学习“Java免费学习笔记（深入）”；
这不是连接池问题，是驱动层行为，但表现和连接泄漏高度相似。
- 显式关闭隐式缓存：
jdbc:oracle:thin:@//host:port/service?implicitCachingEnabled=false&cachePrepStmts=false - 若需预编译语句性能，改用连接池级的
statement-cache-size（HikariCP 不支持，Druid 支持maxOpenPreparedStatements） - Oracle 21c 后驱动引入
oracle.jdbc.autoCommitSpecCompliant=false，避免某些 autocommit 场景下连接状态污染，建议加上
连接泄漏排查：别只看 close()，先查物理连接是否真断开
很多团队花时间 audit 代码里的 close() 调用，却忽略 Oracle 侧的连接状态。应用层认为“已归还”，但 Oracle v$session 里仍显示 ACTIVE 或 INACTIVE，说明连接根本没真正释放。
原因常是：连接池配置了 maxLifetime 过长（如 30 分钟），而 Oracle 网络层因 SQLNET.EXPIRE_TIME 主动断连，池内连接变成“僵尸”，后续 close() 无法清理。
- 在 Oracle 执行：
SELECT sid, serial#, status, schemaname, osuser, machine, program FROM v$session WHERE type='USER' AND status='INACTIVE'，观察 idle 时间是否远超应用设置 - HikariCP 必须配
maxLifetimeSQLNET.EXPIRE_TIME * 60（单位毫秒），例如 DBA 设了 10 分钟，这里就设 540000 - 加 JVM 参数
-Doracle.net.disableOob=true防止某些 JDK 版本下 OOB 包干扰连接检测
最麻烦的泄漏往往发生在跨线程传递 Connection、或者用 CompletableFuture 异步执行后忘记 close ——这时候池监控看不出异常，但 v$session 里会慢慢堆起一堆 “INACTIVE” 连接，直到 DBA 报警。
