因此，我正在研究 c3p0 API 来调试我们的一个生产问题，该问题导致在检查连接时出现堆栈溢出错误。
我发现下面的评论BasicResourcePool班级的checkoutResource method:
/*
* 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.
*/
我想知道该池中的资源永远无法成功检出的原因可能是什么。
答案可能会帮助我调查我的应用程序中可能出现的问题。
因此，尽管这是一个合理的猜测，但仅仅池耗尽（如果泄漏或忘记 close() 连接会发生什么）不会导致堆栈溢出。
堆栈溢出发生在以下情况checkoutResource(...)
- 找到一个可供签出的连接，并“初步”签出它；然后
- 出了问题，说明初步签出的Connection不可用；所以
- 该函数“回到井中”，递归地调用自身以使用新的连接再次尝试
谜团在于“出了问题”部分。实际上有两件事可能会出错：
- （最有可能！）你有
testConnectionOnCheckout set to true并且所有连接都未通过连接测试
- 连接碰巧被删除（例如因超过而过期
maxIdleTime or maxConnectionAge）在结帐过程中从池中取出
如果您看到此情况，首先要检查的是您的连接或连接测试机制是否存在问题。尝试...
- Log
com.mchange.v2.resourcepool.BasicResourcePool at DEBUG or FINE并查找指示无法结帐的异常。你可以 grep 查找A resource could not be refurbished for checkout.或者，开关连接测试制度 http://www.mchange.com/projects/c3p0/#simple_advice_on_connection_testing测试空闲连接和连接签入而不是签出，并以一种可能不那么破坏性的方式观察问题的出现。
- 如果你正在做一些会迫使池真正搅动连接的事情，设置非常短的超时或其他什么，可以想象竞争条件会很严重。检查您的价值观配置属性 http://www.mchange.com/projects/c3p0/#configuration_properties
maxConnectionAge, maxIdleTime, and maxIdleTimeExcessConnections并确保它们合理或未设置（即保留合理的默认值）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
