UOW等待IBM DB2内存占用异常及数据库服务器频繁挂起问题排查咨询

这种连接泄漏引发的连锁问题我碰到过不少，咱们一步步来拆解排查和解决：

一、精准定位连接泄漏的根源 #

1. 先查看JBoss连接池实时状态 #

• 登录JBoss管理控制台，找到对应数据源，重点关注这几个核心指标：ActiveCount（当前活跃连接数）、AvailableCount（可用连接数）、MaxCount（连接池最大容量）。如果活跃数长期接近最大值，可用数持续为0，基本可以判定存在连接未释放的问题。
• 嫌控制台操作麻烦的话，用JBoss CLI命令直接查询：

  /subsystem=datasources/data-source=YourDataSourceName:read-resource(include-runtime=true)
  

2. 让JBoss帮你锁定泄漏代码 #

• 修改JBoss的数据源配置文件（standalone.xml或domain模式下的对应配置文件），开启连接泄漏检测：

  <pool>
      <leak-detection>true</leak-detection>
      <leak-detection-interval>60000</leak-detection-interval> <!-- 每分钟检测一次 -->
  </pool>
  <validation>
      <validate-on-match>true</validate-on-match>
  </validation>
  

• 开启后，JBoss会在日志中打印泄漏连接的完整调用栈，比如你会看到类似Connection leak detected的警告，跟着栈信息就能精准定位到代码中未正确关闭连接的位置。

3. 数据库端交叉验证 #

• 登录数据库服务器，查询来自JBoss节点的连接状态（以PostgreSQL为例）：

  SELECT pid, client_addr, state, query FROM pg_stat_activity WHERE client_addr = '你的JBoss服务器IP';
  

• 如果发现大量连接长期处于active状态，且对应的查询是早已执行完成的旧语句，说明这些连接确实未被JBoss回收。

二、针对性解决问题 #

1. 修复代码层面的连接泄漏 #

• 优先使用Java try-with-resources语法（Java 7+支持），它会自动关闭Connection、Statement、ResultSet等资源，从根源避免遗漏：

  try (Connection conn = dataSource.getConnection();
       PreparedStatement stmt = conn.prepareStatement("SELECT * FROM your_table");
       ResultSet rs = stmt.executeQuery()) {
      // 业务逻辑处理
  } catch (SQLException e) {
      // 异常处理逻辑
  }
  

• 若项目基于Java 6及以下，必须在finally块中手动关闭资源，即使抛出异常也要执行：

  Connection conn = null;
  PreparedStatement stmt = null;
  ResultSet rs = null;
  try {
      conn = dataSource.getConnection();
      stmt = conn.prepareStatement("SELECT * FROM your_table");
      rs = stmt.executeQuery();
      // 业务逻辑处理
  } catch (SQLException e) {
      // 异常处理逻辑
  } finally {
      // 按倒序关闭资源，避免依赖问题
      if (rs != null) try { rs.close(); } catch (Exception ignored) {}
      if (stmt != null) try { stmt.close(); } catch (Exception ignored) {}
      if (conn != null) try { conn.close(); } catch (Exception ignored) {}
  }
  

2. 优化JBoss连接池配置 #

• 给连接池添加超时回收机制，即使代码存在疏漏，也能自动回收闲置过久的连接：

  <pool>
      <max-pool-size>20</max-pool-size> <!-- 根据业务并发量调整，建议20-50之间 -->
      <min-pool-size>5</min-pool-size>
      <idle-timeout-minutes>10</idle-timeout-minutes> <!-- 闲置10分钟自动回收 -->
      <remove-abandoned>true</remove-abandoned>
      <remove-abandoned-timeout>300</remove-abandoned-timeout> <!-- 5分钟无活动标记为废弃并回收 -->
      <log-abandoned>true</log-abandoned> <!-- 打印废弃连接的调用栈，方便后续排查 -->
  </pool>
  

• 针对数据库STMM内存重分配加剧挂起的情况，可临时调整数据库内存参数（以DB2为例）：

  UPDATE DB CFG FOR your_db USING MEMORY_HEAP_SZ 4096; -- 根据服务器内存调整，例如设置为4G
  

  注意：STMM是自动调优机制，调整后需持续观察负载，避免过度限制影响其他业务。

3. 紧急情况的临时救急方案 #

• 若数据库已出现挂起，先重启JBoss实例，快速释放所有泄漏的连接，缓解数据库内存压力；
• 临时增大数据库内存配置（比如PostgreSQL调大shared_buffers，MySQL调大innodb_buffer_pool_size），撑到代码修复完成。

内容的提问来源于stack exchange，提问作者Tiesto