mysql - 与 c3p0 连接池丢失 MySQL 连接

Question

我们正在使用 hibernate 和 MySql。我们使用c3p0创建连接池。根据我的研究，我在 persistence.xml 文件中提出了以下这些设置。据我了解，数据库连接数不应低于最小值 10，当连接生命周期达到 14400(4 小时)时，它将关闭并重新连接。

<property name="hibernate.c3p0.min_size" value="10" />
<property name="hibernate.c3p0.max_size" value="100" />
<property name="hibernate.c3p0.acquire_increment" value="10" />
<property name="hibernate.c3p0.max_statements" value="1000" />
<property name="hibernate.c3p0.numHelperThreads" value="30" />
<property name="hibernate.c3p0.timeout" value="14400" />
<property name="hibernate.c3p0.maxIdleTimeExcessConnections" value="1800" />
<property name="hibernate.c3p0.validate" value="false" />
<property name="hibernate.c3p0.idle_test_period" value="3600" />
<property name="hibernate.c3p0.preferredTestQuery" value="select id from contact limit 1" />
<property name="hibernate.c3p0.acquireRetryAttempts" value="100" />
<property name="hibernate.c3p0.acquireRetryDelay" value="1000" />
<property name="hibernate.c3p0.breakAfterAcquireFailure" value="true" />

使用此查询我可以监视连接。我看到连接数从 ar 10 开始，对于空闲连接，进程时间会根据idle_test_period 攀升至3600 并重置。但是一天左右后，我再次检查，发现连接数减少到了 9 个。到了周末，连接数减少到了 6 个。当连接数达到 1 时，程序将锁定，而不会抛出异常。尝试运行数据库查询时出现异常。

SELECT 
    performance_schema.threads.PROCESSLIST_ID,
    performance_schema.threads.PROCESSLIST_USER,
    performance_schema.threads.PROCESSLIST_HOST,
    performance_schema.threads.PROCESSLIST_TIME
FROM performance_schema.threads
WHERE performance_schema.threads.PROCESSLIST_USER = 'loginname'
ORDER BY performance_schema.threads.PROCESSLIST_HOST, performance_schema.threads.PROCESSLIST_TIME;

正如我所说，空闲连接的 PROCESS_TIME 高达 3600，但昨天我看到一个爬升至 17000 以上，到第二天早上该连接已关闭，总连接数已降至 5。

我在这里缺少什么吗？开放连接数应该至少保持在 10 个吗？这些设置中是否有某些内容导致连接无法保持打开状态或无法维持？

Answer 1

您很可能存在连接泄漏，也就是说，您的应用程序有时无法在其 checkout 的连接上调用close()。

c3p0 通常不会干扰已 checkout 并在客户端控制下的连接。特别是，hibernate.c3p0.timeout (c3p0.maxIdleTime) 不会被强制执行，因此最终泄漏的连接将在 mysql 端超时，但仍会在 c3p0 中永远使用看法。最终，所有连接都将被 check out 但已失效，并且新客户端将无限期挂起(除非设置了 c3p0.clientTimeout )，等待永远不可用的连接。

您的帖子中唯一与此假设不一致的地方是您将 hibernate.c3p0.max_size (c3p0.maxPoolSize) 设置为 100，因此当您卡住时已 check out 100 个连接，而不仅仅是 10 个，除非强制执行服务器端限制。但是，由于您正在查看服务器端打开的连接，因此这些连接与客户端打开的连接之间的映射并不清晰，因为您只能看到已打开但尚未超时的连接。但如果您从未看到超过 10 个打开的连接，我仍然会感到非常惊讶。

不过，我要做的第一件事是调试或至少解决连接泄漏问题。 c3p0 的“永不弄乱 checkout 连接”规则的主要异常(exception)是 unreturnedConnectionTimeout ，您可以将其配置为 hibernate.c3p0.unreturnedConnectionTimeout 。它将关闭已 checkout 但在您定义的一段时间过去后未返回的连接。

不过，最好是消除连接泄漏，而不仅仅是解决它们。设置配置属性 debugUnreturnedConnectionStackTraces ，当您还设置了 unreturnedConnectionTimeout 和生成连接的堆栈跟踪时，您可以将其配置为 hibernate.c3p0.debugUnreturnedConnectionStackTraces 为 true never close 将打印到您的日志中。然后您可以尝试了解导致某些连接打开但从未关闭的代码路径。通常，这与不使用对所有 Exception-al 情况稳健的 Connection.close() 策略有关。 Java 7 之后，try-with-resources构造对于解决这个问题非常有帮助。