2

我已经为此做了很多小时，但没有成功。我在多线程应用程序中实例化一个 DataSource。所有线程都从 DataSource 获取连接并在 finally 块中关闭它们（我逐行检查以确保释放连接）。我遇到的问题是，即使在每个连接上都调用了 close 方法，但它们并没有被 DataSource 释放。我知道这一点是因为我有一个从 DBCP 数据源打印source.getNumActive()的不同线程。

这是基本设置。 

public class DataSourceHolder {
  private static DataSource source;
  static {
    get the data source either from jndi or created from scratch
  }
  public DataSource getDataSource() { return source; }
}

我有一个简单的 JdbcPattern（像 springs JdbcTemplate 但非常简单）来封装所有样板代码。这是这样定义的：

public class JdbcPattern {
  private DataSource source;
  public JdbcPattern(DataSource source) {
    this.source = source;
  }
  public int executeMethods(....) {
    Connection c = source.getConnection();
    try {
      .. do the statements
    } finally {
      try { c.close(); } catch (SQLException ignore) { }
    }
  }
  public List<?> queryMethods(....) {
  }
}

最后，我有四个线程在程序开始时启动。该线程会休眠一段时间，并在唤醒时使用 DataSourceHolder 提供程序 DataSource 实例化一个 JdbcPattern 并开始做一些事情。事情完成了，当连接关闭时，数据源并没有真正释放它。在 DataSource 最大连接数之后，由于无法实例化更多连接，程序冻结。

您将如何诊断？

编辑。这是在tomcat上运行的。所有常用方法都由 catalina common loader 加载，并且线程在其中一个 Web 应用程序中运行。我一直在想这可能是一个类加载器问题。

4

1 回答 1

2

您不应该忽略关闭失败。将其包装在未经检查的异常中或将其记录下来，但不要忽略。如果尝试释放与池的连接时出现一些奇怪的错误，您将不知道。

我建议为池数据源创建自己的包装器。您可以记录对 getConnection 的调用以及堆栈跟踪和连接的唯一标识符。当它调用 close 时，也以相同的方式在 JdbcPattern 中记录。查找未关闭的连接的标识符，注意从 getConnection 堆栈跟踪中将它们从池中取出的位置。您也可以让您的 DataSource 包装器在服务器内部进行此分析，但这需要更多代码和更多出错的机会。我会先尝试简单的日志记录。考虑将此日志记录保留在产品中，但低于正常的日志记录阈值。您将再次需要它。

于 2012-06-10T00:30:37.360 回答