0

使用 ojdbc6.jar、tomcat 7、tomcat-dbcp-8.0.3.jar（以及其他可能与此问题无关的 jar）、JDK 7 (u51) 的 java 应用程序

我们已经使用 v$session 报告确定存在连接泄漏，其中某些连接进入 INACTIVE 状态超过 7 小时。在冻结状态下进行的线程转储也证实了这一点。

堆转储（在冻结状态下拍摄）显示：

  1. Total PoolableConnection 和 DefaultPooledObject 等于 maxTotal（预期为耗尽池）
  2. 每个连接都关联到 PooledObjectState ALLOCATED（预期）
  3. lastReturnTime = lastUserTime = lastBorrowedTime（在 DefaultPooledObject 中），这对我来说意味着：THREAD-1（良好的工作流程）返回了由 THREAD-2 立即借用的连接（有泄漏的不良工作流程），而 THREAD-2 从未关闭连接，让它悬空！

上述所有观察都是有道理的，因为我们肯定有连接泄漏和最终耗尽的池 分配池状态

我的问题是：当我看到有关 PoolableConnection 的详细信息时，它具有关联的布尔值 _closed，它是“真”。为什么/怎么会有“_closed = true”。当我反编译 tomcat-dbcp jar 时，我可以看到每次 _close 被标记为 true 时，它​​也会将 IDLE 状态与连接对象相关联（而不是 ALLOCATED）。 _closed PoolableConnection

寻找关于为什么这个布尔值是真的理论。

PS：我们有各种想法（比如设置 logAbandoned）来找到负责连接泄漏的确切代码，我期待找到堆转储的原因（或理论）来捕获这些 PoolableConnection _closed=true 情况。

4

1 回答 1

1

查看DelegatingConnection 源代码可以看出，作为安全措施 ，closed=true可以将其设置为某些异常后的结果connection.close()或块中。finally

} finally {
    closed = true;
}

存在泄漏，连接处于不一致状态，因为它无法关闭并且可能已准备好在 ABANDONED 生命周期阶段进行处理。
通过 JMX 检查池可以提供另一个视角。
泄漏可能与处理不当的异常有关，否则会提示池不良状态。

于 2018-09-17T02:34:43.343 回答