📌 摘要

某生产环境Oracle 11g数据库正常运行一段时间后，PL/SQL突然无法连接，应用后台报“连接超时”。DBA排查发现数据库会话数达到上限（150），紧急处理后恢复。本文详细复盘了整个排查过程，从数据库参数、连接池配置、代码泄漏等多个维度抽丝剥茧，最终定位到根本原因——默认HikariCP连接池配置过于保守且缺少泄漏检测，并结合业务特点给出了生产级的连接池推荐配置。如果你也曾被“连接池爆满”困扰，这篇文章或许能帮你少走弯路。

---

1️⃣ 问题现象

• 时间线：Oracle 11g数据库运行一段时间后（约数小时至数天），新的数据库连接请求失败。
• 具体表现：
  • PL/SQL Developer提示“监听无法访问”。
  • Spring Boot应用后台报错：Connection is not available, request timed out after 30000ms。
• DBA初步反馈：数据库会话数已达上限（原值150），需要临时扩容或清理会话。
• 临时措施：DBA将sessions参数从150调大至500，并重启数据库，系统恢复正常。

---

2️⃣ 环境与配置

• 数据库：Oracle 11g
• 应用框架：Spring Boot 2.x + MyBatis
• 连接池：HikariCP（Spring Boot默认）
• 驱动：ojdbc7 (12.1.0.2)
• 关键配置（问题发生前）：

  spring:
    datasource:
      driver-class-name: oracle.jdbc.OracleDriver
      url: jdbc:oracle:thin:@182.10.100.117:1525:db
      username: xxx
      password: xxx
      # 未显式配置任何连接池参数
  

• 数据库参数变更：

  SHOW PARAMETER sessions;  -- 原值150，改为500
  

---

3️⃣ 排查过程（层层递进）

3.1 会话快照分析（问题恢复后）

DBA在重启数据库后执行了以下查询：

SELECT MACHINE, PROGRAM, STATUS, LAST_CALL_ET 
FROM v$session WHERE USERNAME='appuser';

结果：

MACHINE            PROGRAM              STATUS   LAST_CALL_ET
localhost.localdomain JDBC Thin Client   INACTIVE   1414
localhost.localdomain JDBC Thin Client   INACTIVE   1414
...（共10条记录）

结论：当前只有10个来自应用的会话，全部空闲（INACTIVE），完全符合HikariCP默认最大连接数10。这说明问题发生时一定存在远超10个的额外会话，但已经被重启清空。

3.2 排除多应用/多实例干扰

用户确认：只有一个Spring Boot应用，没有其他程序连接同一数据库。
那么，单应用如何用尽150个会话？可能性指向：应用代码存在连接泄漏，且泄漏的连接绕过了连接池管理。

3.3 排查代码中的“显式连接获取”

• 全局搜索SqlSessionFactory.openSession() → 未发现。
• 全局搜索DriverManager.getConnection → 未发现。
• 使用MyBatis-Plus版本2.1.4（稳定版，无已知泄漏Bug）。

矛盾点：如果所有数据库操作都通过MyBatis + HikariCP，那么最大连接数应被限制在10，不可能达到150。除非……

3.4 真正的元凶：默认配置的“温柔陷阱”

Spring Boot默认的HikariCP配置如下：

• maximumPoolSize = 10
• minimumIdle = 10（与最大值相同）
• idleTimeout = 600000（10分钟）
• maxLifetime = 1800000（30分钟）
• leakDetectionThreshold = 0（禁用泄漏检测）

这意味着：

1. 连接池会始终保持10个活跃连接，即使业务空闲也不释放。
2. 一旦代码中某处偶然创建了物理连接（例如通过JNDI、原生JDBC、某些第三方库）且忘记关闭，这些连接不会被连接池管理，就会永驻数据库，直到会话数爆满。
3. 由于泄漏检测未开启，应用日志中没有任何线索。

推测的问题发生路径：

• 某次代码发布引入了一个小众场景（比如调用存储过程返回游标、使用Oracle的某些专有API），每次调用都新建一个Connection但未关闭。
• 该场景触发频率不高，每天泄漏几个连接，运行数周后累积到150。
• 数据库拒绝新连接，应用报错，DBA扩容+重启，问题暂时消失。

---

4️⃣ 解决方案（生产级推荐配置）

4.1 显式配置HikariCP并开启泄漏检测

在application.yml中添加以下配置（针对业务最长查询≤2分钟的场景）：

spring:
  datasource:
    hikari:
      # 连接池大小（根据实际并发调整，建议20~50）
      maximum-pool-size: 20
      minimum-idle: 5
      # 超时控制
      connection-timeout: 30000
      idle-timeout: 600000
      max-lifetime: 1800000
      # 泄漏检测（关键！）
      leak-detection-threshold: 180000   # 3分钟
      # 其他
      auto-commit: true
      validation-timeout: 5000

4.2 参数解释

参数	推荐值	理由
maximum-pool-size	20	单应用10可能偏小，20可应对中等并发，且数据库会话上限500有足够余量。
minimum-idle	5	保持少量空闲连接即可，避免资源浪费。
leak-detection-threshold	180000（3分钟）	业务最长查询≤2分钟，设置3分钟可避免误报；一旦连接被持有超过3分钟，日志会打印堆栈，精准定位泄漏代码。
connection-timeout	30秒	连接池繁忙时，最多等待30秒后快速失败，避免线程阻塞。
max-lifetime	30分钟	防止数据库或网络设备强制断开长期闲置的连接。

4.3 为什么是3分钟？

• 正常查询最长2分钟，加上网络、GC等抖动，2分钟内应归还连接。
• 设置3分钟提供了1分钟的缓冲，既能捕获泄漏（比如连接被持有4、5分钟），又不会干扰正常业务。

---

5️⃣ 监控与验证

5.1 部署会话监控脚本

使用Python脚本定期采集v$session数据（脚本代码见附录），观察user_sessions趋势：

• 稳定在maximum-pool-size附近 → 正常。
• 持续缓慢增长 → 仍有泄漏，需根据泄漏检测日志修复。

5.2 观察应用日志

配置生效后，如果出现：

Connection leak detection: a connection was held for 180000 ms and not returned ...

堆栈信息会直接指出哪一行代码获取了连接但未归还。

5.3 压力测试

在测试环境使用JMeter模拟高并发，观察会话数是否受控。

---

6️⃣ 总结与建议

问题	根本原因	解决方案
数据库会话被占满	应用代码中存在连接泄漏 + HikariCP默认关闭泄漏检测	开启leak-detection-threshold，修复泄漏代码
单应用为何能突破最大连接数限制	泄漏的连接绕过连接池（如直接DriverManager.getConnection）	代码审查 + 统一使用@Autowired DataSource
重启后问题消失但复发	重启清空了泄漏会话，但源头未修复	持续监控 + 配置检测 + 代码修复

给开发者的三点忠告：

1. 永远不要依赖默认配置：显式设置连接池大小和泄漏检测阈值。
2. 任何获取Connection的地方都必须使用try-with-resources或finally关闭。
3. 定期查看数据库会话数：一个简单的SELECT COUNT(*) FROM v$session WHERE TYPE='USER'就能提前预警。

---

附录：简易会话监控脚本（Python）

import oracledb
import time
import csv
from datetime import datetime

# 配置数据库连接（使用环境变量）
conn = oracledb.connect(user=os.getenv('DB_USER'), password=os.getenv('DB_PWD'), dsn="host:port/sid")
cursor = conn.cursor()
while True:
    cursor.execute("SELECT COUNT(*) FROM v$session WHERE TYPE='USER'")
    count = cursor.fetchone()[0]
    with open('sessions.csv', 'a') as f:
        f.write(f"{datetime.now()},{count}\n")
    time.sleep(300)  # 每5分钟采集一次

---

关键词：Oracle会话爆满、Spring Boot连接池、HikariCP泄漏检测、MyBatis连接泄漏、生产故障复盘

如果你也遇到过类似问题，欢迎在评论区分享你的排查经历。技术路上，我们一起避坑。

👉 点击关注我，更新后第一时间收到推送！