java - c3p0中的资源无法 check out 的原因是什么？

Question

因此，我正在研究 c3p0 API 来调试我们的一个生产问题，该问题导致在检查连接时出现堆栈溢出错误。

我在 BasicResourcePool 类的 checkoutResource 方法中发现了以下注释:

    /*
 * This function recursively calls itself... under nonpathological
 * situations, it shouldn't be a problem, but if resources can never
 * successfully check out for some reason, we might blow the stack...
 *
 * by the semantics of wait(), a timeout of zero means forever.
 */

我想知道该池中的资源永远无法成功 check out 的原因是什么。

答案可能会帮助我调查我的应用程序中可能出现的问题。

Answer 1

因此，尽管这是一个合理的猜测，但仅仅池耗尽(如果泄漏或忘记 close() 连接会发生什么)不会导致堆栈溢出。

当checkoutResource(...)时发生堆栈溢出

1. 找到一个可供 checkout 的连接，并“初步” checkout 它；那么
2. 出现问题，表明初步 checkout 的Connection不可用；所以
3. 函数“回到井中”，递归地调用自身以使用新的连接再次尝试

谜团在于“出了问题”部分。实际上有两件事可能会出错:

1. (很可能!)您将 testConnectionOnCheckout 设置为 true 并且所有连接都未通过其连接测试
2. 在结帐过程中，连接碰巧从池中删除(例如，由于超过 maxIdleTime 或 maxConnectionAge 而过期)

如果您看到此情况，首先要检查的是您的连接或连接测试机制是否存在问题。尝试...

1. 在 DEBUG 或 FINE 处记录 com.mchange.v2.resourcepool.BasicResourcePool 并查找指示无法 checkout 的异常。您可以 grep 查找无法翻新资源以进行结账。 或者，switch Connection testing regimes测试空闲连接和连接 checkin 而不是 checkout ，并以一种可能不那么破坏性的方式观察问题的出现。
2. 如果您所做的事情会迫使池真正搅动连接，设置非常短的超时或其他什么，可以想象竞争条件会很严重。检查 configuration properties 的值maxConnectionAge、maxIdleTime 和 maxIdleTimeExcessConnections 并确保它们合理或未设置(即保留合理的默认值)。