带有 C3P0 或 DBCP 的 Spring ORM 正在泄漏连接

Question

在 DBCP 和 C3P0 的最新版本上，使用 Spring 的 Ibatis 支持，我遇到了两个泄漏连接的问题。

场景是有一个日志运行SQL，它锁定了多个表。当用户触发命中锁定表的查询时，这会导致我的池中的连接最大化。最后，管理员进入 MySQL 并在长时间运行的 SQL 上执行kill query <id>。

如果有足够多的线程（在我的情况下大约 50 个或更多）正在等待将 DB 线程检入池中，那么我会在线程转储中看到类似以下内容：

 java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1315)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:557)
    - locked <0x00002aaacbb01118> (a com.mchange.v2.resourcepool.BasicResourcePool)
    at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:477)
    at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525)
    at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128)
    at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113)
    at 

或

  java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:485)
    at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1104)
    - locked <0x00002aab0f030620> (a org.apache.commons.pool.impl.GenericObjectPool$Latch)
    at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)
    at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
    at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113)
    at 

这些线程永远等待。

如果池已满，并且只有少数（大约 5 个）线程正在等待池中的空闲连接，则不会发生这种情况。

我知道有可以解决这个问题的配置（设置超时等），但我很感兴趣为什么会发生这种情况？当有 50 个或更多线程在等待连接并且我终止了长时间运行的 SQL 时，为什么没有将活动线程返回到池中？

更新：我应该明确表示我使用的是 Spring 3.0.2 和 伊巴蒂斯 2.3。我使用管理我的 SqlMapClientTemplate 为我连接。在这一点上，我开始认为它是 Ibatis 2.3 无法正确处理重负载。

Answer 1

就像@BalusC 所问的一样，你要关闭你的连接吗？它们应该在 Java try-catch-finally 的 finally 子句中关闭。将每个 connection.close() 方法包装在自己的 try { con.close() } catch (Exception ignore) {} 中

您可以选择为ResultSet 然后Statement 然后Connection 这样做。在初始 try 块之外将 Connection、Statement 和 ResultSet 声明为 null 并在 try 块中实例化。

Connection con = null;
Statement stmt = null;
ResultSet rs = null;

try {

    con = getConnectionFromPoolMethod();

    // ...
    // instantiate your statement and result set as normal
    // make your sql call; 
    // extract data from result set to appropriate POJO

} catch (Exception ex) {
    // handle your exception, log, wrap, enhance or rethrow or whatever
} finally {
    if (rs != null) try { rs.close(); } catch (Exception ignore) {}
    if (stmt != null) try { stmt.close(); } catch (Exception ignore) {}
    if (con != null) try { con.close(); } catch (Exception ignore) {}
}

如果您愿意，而不是在包装 SQL 调用的每个 finally 中的所有上述代码，您可以选择使用 DbUtils 实用程序类 Apache Commons DbUtils。

import org.apache.commons.dbutils.DbUtils;

并应用closeQuietly 方法。 finally 块将如下所示：

} finally {
    DbUtils.closeQuietly(con, stmt, rs);
}

Answer 2

只是添加到@BalusC 的评论和@JoshDM's answer，当您在 Java 代码中对 Connection 调用 close() 时，在幕后这实际上只是将该连接检查回您的连接池，而不是物理关闭它。这就是为什么始终通过 Java 代码关闭连接很重要，无论底层 JDBC 驱动程序是否正在池化它们。

更多关于这个的讨论在this post。

Answer 3

在使用 c3po 时，我强烈建议您试试这个feature。当您在事务之外执行数据库修改时，通常会出现连接泄漏。带有未提交写入的连接不能被重用，并且会从池中丢失。如果您启用此调试并具有相当长的超时时间，您将能够看到带有可疑数据库操作的堆栈跟踪。

确保堆栈跟踪中看到的操作正确管理事务。还可以通过将 c3p0 记录器设置为调试级别来监控连接池的使用情况。