maxIdleTimeExcessConnections 与 c3p0 中的 maxIdleTime 有何不同？答案

【问题标题】：How is maxIdleTimeExcessConnections different from maxIdleTime in c3p0?maxIdleTimeExcessConnections 与 c3p0 中的 maxIdleTime 有何不同？
【发布时间】：2014-05-06 21:05:41
【问题描述】：

我想配置我的 c3p0 连接池，以使至少 2 个连接始终处于活动状态，最多 5 个，而前 2 个之后的空闲连接将在合理的时间内（比如一个小时）过期。

这一切听起来很简单，除了文档似乎暗示函数 maxIdleTime 和 maxIdleTimeExcessConnections 之间没有区别，这让我感到困惑。

Basic pool configuration 状态：

在 minPoolSize 和 maxPoolSize 之间的范围内，池中的连接数根据使用模式而变化。每当用户请求连接、没有可用的连接以及池中管理的连接数尚未达到 maxPoolSize 时，连接数就会增加。由于连接获取速度非常慢，因此分批急切地增加连接数量几乎总是有用的，而不是在负载增加时强制每个客户端等待新连接来引发单个连接。 acquireIncrement 确定当池用完连接时，c3p0 池将尝试获取多少连接。（不管acquireIncrement，池永远不会允许超过maxPoolSize。）

和minPoolSize 用法：

一个池在任何给定时间将保持的最小连接数。

好的，太好了。而对于配置连接时间：

maxIdleTimeExcessConnections 是关于在池未加载时最小化 c3p0 池持有的连接数。默认情况下，c3p0 池会在负载下增长，但只有在连接测试失败或通过上述参数过期时才会缩小。一些用户希望他们的池在强制使用大池大小的使用高峰后快速释放不必要的连接。您可以通过将 maxIdleTimeExcessConnections 设置为比 maxIdleTime 短得多的值来实现此目的，如果连接闲置超过很短的时间，则强制释放超出设置的最小大小的连接。

因此暗示minPoolSize 仅在与maxIdleTimeExcessConnections 一起使用时才有意义，否则将被完全忽略。

证实maxIdleTime 的文档没有提到minPoolSize：

在被丢弃之前，连接可以保持池化但未使用的秒数。零表示空闲连接永不过期。

maxIdleTimeExcessConnections 说得通：

应允许超过 minPoolSize 的连接在被剔除之前在池中保持空闲的秒数。适用于希望积极最小化打开连接数的应用程序，如果在达到峰值后负载水平降低并且不再需要获取的连接数，则将池缩回到 minPoolSize。如果设置了 maxIdleTime，则 maxIdleTimeExcessConnections 应该更小才能使参数生效。零表示不强制执行，多余的连接不会闲置。

我觉得很奇怪minPoolSize，一个基本功能，只有在与我认为更高级的功能一起使用时才重要。这一切都正确吗？

【问题讨论】：

标签： java jdbc connection-pooling c3p0

【解决方案1】：

多么仔细和有法律依据的读物！

但不，这是不正确的。

连接有几种方式会死掉。正如你所引用的：

c3p0 pools...shrink 如果连接未通过连接测试或通过上述参数过期。

“上述参数”包括maxConnectionAge、maxIdleTime 和maxIdleTimeExcessConnections。连接也可以从池中删除，因为它们在空闲时未通过连接测试（请参阅idleConnectionTestPeriod），因为它们在签入或签出时未通过测试（testConnectionOnCheckin，testConnectionOnCheckout），或者因为它们未通过测试客户端使用过程中异常触发。

然而，池缩小了，minPoolSize 很重要，因为如果池缩小到 minPoolSize 以下，销毁的连接将被替换，直到minPoolSize 恢复。

maxIdleTimeExcessConnections 的独特之处在于它的行为直接取决于池相对于minPoolSize 的大小。所有其他参数和测试只是做他们的事情。如果他们的事情恰好使池低于minPoolSize，则c3p0 将自动将池带回minPoolSize。但maxIdleTimeExcessConnections 不同。仅当池大于minPoolSize 时才有效。

正如您所说，maxIdleTimeExcessConnections 是一项高级功能。大多数用户从不也不需要使用它。添加它是因为一些用户想要积极地强制池缩回到 minPoolSize，但是使用非常短的无条件 maxIdleTime 这样做会导致不必要的连接流失，因为即使在 minPoolSize 池中的连接也会不断过期和替换。设置一个长的或不存在的maxIdleTime，而设置一个短的maxIdleTimeExcessConnections 会在池达到minPoolSize 时产生快速、积极的收缩而不会通过连接搅动的预期结果。

但即使没有设置maxIdleTimeExcessConnections，minPoolSize 也很重要。连接确实会被销毁并从池中清除，minPoolSize 确定一个阈值，低于该阈值将自动替换已销毁的连接，即使没有客户端负载引发池扩展。

我希望这是有道理的！

【讨论】：

所以如果我有 min = 2, maxIdleTime = 一个小时，并且有 2 个连接，其中一个已经闲置了一个小时，它将因为空闲而被杀死，然后立即更换以维护最低？
是的。（现在我必须输入 11 个字符。等等，这太多了。）
太有趣了，听起来我想使用maxIdleTimeExcessConnections。即使连接未使用并强制旋转，也没有任何理由至少终止连接。只有在他们高于最低限度时才想杀。这不是更明智的使用方式吗？
当然。这是一个很好的方法。无条件的 maxIdleTime 是防止连接超时的好方法，因为许多 dbms/jdbc 驱动程序不允许连接永远保持打开状态。但如果这对您来说不是问题（或者如果您乐于使用测试来懒惰地清除过期的连接），则无需设置 maxIdleTime。通常，我会将其设置为几个小时的值以防止材料流失。如果目标是保持池的占用空间小，maxIdleTimeExcessConnections 是一个更好的选择。
@SteveWaldman：感谢您的回答！当池中存在陈旧连接并且客户端调用失败并出现错误“连接已关闭”等时，c3p0 的行为如何。它是否使 c3p0 连接池缩小或这些陈旧连接保留在池中（即使在客户端调用失败后）？ TIA。

【解决方案2】：

Steve Walkdman 的回答很好，我只想添加一个简短的回答：

不同之处在于，即使在minPoolSize-d 池中，maxIdleTime 也会替换空闲连接，而maxIdleTimeExcessConnections 不会。

【讨论】：

嗨，Oleninikov，“替换空闲连接”和“中断空闲连接”有什么区别，“替换空闲连接”是指创建一个新的连接对象并删除旧的连接对象？断开空闲连接时，连接池的数量会减少一个吗？提前致谢。

【解决方案3】：

springboot - 1.5 x - application.properties -

server.session.timeout=3600

【讨论】：