c3p0 DataSource 监视器死锁 - 所有线程挂起 - 如何修复
c3p0 DataSource monitor deadlock - all threads hang - how to fix
我们有一个基于 Spring 的应用程序，最近我们投入生产。我们使用的 Spring @Controller 最终命中了使用 JDBCTemplate 的 DAO。它正在使用 c3p0 的 ComboPooledDataSource
在负载增加时（大约 150 个并发用户），所有用户的应用程序都会挂起 - DataSource 被某些东西锁定 - 在线程转储上，大约有 200 个线程说 - 显然 DataSource 已死锁。
"http-bio-8080-exec-440" - Thread t@878
java.lang.Thread.State: WAITING
at java.lang.Object.wait(Native Method)
- waiting on <146d984e> (a com.mchange.v2.resourcepool.BasicResourcePool)
at com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1418)
at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:606)
at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:526)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutAndMarkConnectionInUse(C3P0PooledConnectionPool.java:756)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:683)
at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:140)
at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111)
at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77)
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:573)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:637)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:666)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:674)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:718)
在那之后，除非重新启动，否则应用程序将无法使用。发生这种情况时，DBA 团队没有观察到数据库上有任何负载。
当时c3p0是这样配置的：
app_en.driverClass=com.mysql.jdbc.Driver
app_en.user=tapp_en
app_en.password=tapp_en
app_en.jdbcUrl=jdbc:mysql://10.10.0.102:3306/tapp_en?useUnicode=true&characterEncoding=utf-8&autoReconnect=true
app_en.acquireIncrement=5
app_en.maxIdleTime=3600
app_en.maxIdleTimeExcessConnections=300
app_en.unreturnedConnectionTimeout=3600
app_en.numHelperThreads=6
app_en.minPoolSize=20
app_en.maxPoolSize=100
app_en.idleConnectionTestPeriod=120
app_en.testConnectionOnCheckin=true
之后，我如下更改了 c3p0 的配置 - 并为 com.mchange.v2.c3p0 包启用了 DEBUG 日志记录：
app_en.driverClass=com.mysql.jdbc.Driver
app_en.user=tapp_en
app_en.password=tapp_en
app_en.jdbcUrl=jdbc:mysql://10.10.0.102:3306/tapp_en? useUnicode=true&characterEncoding=utf-8&autoReconnect=true
app_en.acquireIncrement=5
app_en.maxIdleTime=180
app_en.maxIdleTimeExcessConnections=60
app_en.unreturnedConnectionTimeout=30
app_en.checkoutTimeout=10000
app_en.numHelperThreads=12
app_en.debugUnreturnedConnectionStackTraces=true
app_en.initialPoolSize=10
app_en.maxPoolSize=100
app_en.idleConnectionTestPeriod=120
app_en.preferredTestQuery="select 1 from tbl_users"
有了这个配置，我再次 运行 负载测试，应用程序仍然挂起...尽管线程在无法获得与数据库的连接后恢复。尽管如此，尽管线程已恢复，但与以前的配置不同，游戏因太多用户而挂起 - 因此他们不得不重新启动客户端。
尽管启用了所有日志记录，但 c3p0 日志不记录任何死锁消息。我看到的错误消息是：
[06/24/2015 12:20:54] [C3P0PooledConnectionPoolManager[identityToken->1oed6dl9a9ak8qsgqfvdu|4d6145af]-HelperThread-#10] DEBUG NewPooledConnection - com.mchange.v2.c3p0.impl.NewPooledConnection@7f0bc55a closed by a client.
java.lang.Exception: DEBUG -- CLOSE BY CLIENT STACK TRACE
at com.mchange.v2.c3p0.impl.NewPooledConnection.close(NewPooledConnection.java:659)
at com.mchange.v2.c3p0.impl.NewPooledConnection.closeMaybeCheckedOut(NewPooledConnection.java:255)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPoolPooledConnectionResourcePoolManager.destroyResource(C3P0PooledConnectionPool.java:621)
at com.mchange.v2.resourcepool.BasicResourcePoolDestroyResourceTask.run(BasicResourcePool.java:1024)
at com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:696)
应用程序中没有任何 t运行saction，我们也没有使用任何 T运行sactionManager 或 T运行sactionTemplate。我想知道这是否可能是所用框架中的某种错误或配置错误。这些是使用的相关框架：
c3p0-0.9.5-pre8
mysql-connector-java-5.1.24
spring-core-3.2.1.RELEASE
spring-web-3.2.1.RELEASE
mchange-commons-java-0.2.7
我们非常感谢任何帮助，因为这阻碍了我们发布产品的努力。
P.S。编辑： 这里是数据源的配置：
<bean id="app_en_DataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
destroy-method="close">
<property name="driverClass" value="${app_en.driverClass}" />
<property name="jdbcUrl" value="${app_en.jdbcUrl}" />
<property name="user" value="${app_en.user}" />
<property name="password" value="${app_en.password}" />
<property name="acquireIncrement" value="${app_en.acquireIncrement}"></property>
<property name="maxIdleTime" value="${app_en.maxIdleTime}"></property>
<property name="maxIdleTimeExcessConnections" value="${app_en.maxIdleTimeExcessConnections}"></property>
<property name="unreturnedConnectionTimeout" value="${app_en.unreturnedConnectionTimeout}"></property>
<property name="checkoutTimeout" value="${app_en.checkoutTimeout}"></property>
<property name="numHelperThreads" value="${app_en.numHelperThreads}"></property>
<property name="debugUnreturnedConnectionStackTraces" value="${app_en.debugUnreturnedConnectionStackTraces}"></property>
<property name="initialPoolSize" value="${app_en.initialPoolSize}"></property>
<property name="maxPoolSize" value="${app_en.maxPoolSize}"></property>
<property name="idleConnectionTestPeriod" value="${app_en.idleConnectionTestPeriod}"></property>
<property name="preferredTestQuery" value="${app_en.preferredTestQuery}"></property>
</bean>
这里是应用程序内部的一些代码，没有直接使用 jdbcTemplate。没有别的东西可以做到这一点，其他一切都是 jdbcTemplate.update, jdbcTemplate.query:
Connection conn = null;
ResultSet getItemsRS = null;
try {
JdbcTemplate jdbcTemplate = getJdbcTemplate(database);
conn = jdbcTemplate.getDataSource().getConnection();
UserItems items;
if (!action.areItemsNew()) {
conn.setAutoCommit(false);
conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
PreparedStatement getItemsPS = conn.prepareStatement("select * from tbl_items where ownerId = ? for update",
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_UPDATABLE);
getItemsPS.setLong(1, userId);
getItemsRS = getItemsPS.executeQuery();
getItemsRS.next();
items = new UserItemsRowMapper().mapRow(getItemsRS, getItemsRS.getRow());
} else {
items = new UserItems();
}
action.doUserItemsAction(items);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(items.getItemContainers());
oos.close();
byte[] data = baos.toByteArray();
Blob blob = conn.createBlob();
blob.setBytes(1, data);
if (!action.areItemsNew()) {
getItemsRS.updateBlob("data", blob);
getItemsRS.updateRow();
} else {
jdbcTemplate.update("insert into tbl_items(ownerId,data) values(?,?)", userId, data);
}
} catch (Exception e) {
logger.error(e);
throw new RuntimeException(e);
} finally {
if (!action.areItemsNew()) {
try {
conn.commit();
conn.close();
} catch (SQLException e) {
logger.error(e);
throw new RuntimeException(e);
}
}
}
此代码的原因是我想在通过此操作 action.doUserItemsAction(items) 更新用户项目之前阻止 reading/writing 如上所述。
所以，有几件事。
1) 你看到的 "error" 消息不是错误，当 c3p0 记录一个消息以 DEBUG 开头的异常时，这意味着你正在记录 DEBUG 级别并且 c3p0 生成了异常只是为了捕获堆栈跟踪。 （c3p0 是一个旧库；Thread.getStackTrace() 当时不存在，创建异常是捕获和转储堆栈的便捷方式。）您只是记录了由于过期或测试失败。一般来说，c3p0 期望在 INFO 记录，在 DEBUG 级别会非常冗长。
2) 你没有死锁 c3p0 的线程池。如果是，您会看到 APPARENT DEADLOCK 条消息，然后是恢复。您遇到池耗尽的情况：客户端正在等待连接，但池处于 maxPoolSize 且无法获取它们。
3) 池耗尽的通常原因是连接泄漏：在应用程序代码路径中的某个地方，在某些（可能是异常的）情况下，连接被获取，然后永远不会关闭（）。您需要非常小心，以确保 Connections 在 finally 块中可靠地关闭（），其方式不能由于 finally 块中的先前故障而被跳过。在 Java 7+ 中，使用 try-with-resources。在旧版本中，使用 reliable resource cleanup idiom.
4) 要测试连接泄漏是否是问题所在，请设置 c3p0 配置参数 unreturnedConnectionTimeout and debugUnreturnedConnectionStackTraces。 unreturnedConnectionTimeout 会解决这个问题，但是糟糕。更重要的是，debugUnreturnedConnectionStackTraces 会告诉你问题出在哪里，以便你可以修复它，记录在 INFO 打开未关闭异常的堆栈跟踪。 （您必须为 debugUnreturnedConnectionStackTraces 设置 unreturnedConnectionTimeout 才能产生任何效果；当连接超时时堆栈跟踪被记录为已放弃。）
5) 尽管 0.9.5-pre8 可能没问题，但 c3p0 的当前生产版本是 c3p0-0.9.5.1（取决于 mchange-commons-java v.0.2.10）。您可能会考虑使用它。我不认为这与您的问题有任何关系，但仍然。
希望对您有所帮助！
更新： 由于您现在发布了显示可能的连接泄漏的代码，这里有一个关于如何修复它的建议。将您的 finally 块替换为：
} finally {
if ( conn != null ) {
try { if (!action.areItemsNew()) conn.commit(); }
catch (SQLException e) {
logger.error(e);
throw new RuntimeException(e);
} finally {
conn.close()
}
}
}
更新 2： 重做上面的 finally 块将解决连接泄漏，但如果我是你，我也会更改此代码关于 commit() 的逻辑.这是建议的修订：
Connection conn = null;
ResultSet getItemsRS = null;
try {
JdbcTemplate jdbcTemplate = getJdbcTemplate(database);
conn = jdbcTemplate.getDataSource().getConnection();
UserItems items;
if (!action.areItemsNew()) {
conn.setAutoCommit(false);
conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
PreparedStatement getItemsPS = conn.prepareStatement("select * from tbl_items where ownerId = ? for update",
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_UPDATABLE);
getItemsPS.setLong(1, userId);
getItemsRS = getItemsPS.executeQuery();
getItemsRS.next();
items = new UserItemsRowMapper().mapRow(getItemsRS, getItemsRS.getRow());
} else {
items = new UserItems();
}
action.doUserItemsAction(items);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(items.getItemContainers());
oos.close();
byte[] data = baos.toByteArray();
Blob blob = conn.createBlob();
blob.setBytes(1, data);
if (!action.areItemsNew()) {
getItemsRS.updateBlob("data", blob);
getItemsRS.updateRow();
conn.commit();
} else {
jdbcTemplate.update("insert into tbl_items(ownerId,data) values(?,?)", userId, data);
}
} catch (Exception e) {
logger.error(e);
throw new RuntimeException(e);
} finally {
try { if ( conn != null ) conn.close(); }
catch ( Exception e )
{ logger.error(e); }
}
现在 commit() 将只被调用 if (!action.areItemsNew()) 并且所有预期的操作都已成功。在 commit() 之前即使出现问题也会被调用。资源清理代码也更简单、更清晰。请注意，在建议的版本中，如果 close() 上有异常，它会被记录下来，但不会被包装并作为 RuntimeException 重新抛出。通常，如果 close() 上有异常，那么之前会有一个信息更丰富的异常，这就是您想要看到的异常。如果唯一发生异常的地方是 close()，这意味着所有数据库操作都已成功，因此尽管有错误，您的应用程序仍可以正确执行。 （如果 close() 上有很多异常，最终你会耗尽连接池，但实际上只有当你的数据库或网络出现严重问题时才会发生这种情况。）
您的代码有潜在的危险并且有连接泄漏，当您自己检查连接时，您应该始终关闭它，可能会出现关闭连接失败的情况。
相反，我强烈建议使用 Spring 来管理您的事务和连接。
首先用 @Transactional(isolation=SERIALIZABLE) 注释您的方法。接下来将 DataSourceTransactionManager 和 <tx:annotation-driven /> 添加到您的配置中。这些更改后重写您拥有的数据访问代码。
JdbcTemplate jdbcTemplate = getJdbcTemplate(database);
final UserItems items;
if (!action.areItemsNew()) {
items = jdbcTemplate.queryForObject("select * from tbl_items where ownerId = ? for update", userId, new UserItemsRowMapper());
} else {
items = new UserItems();
}
action.doUserItemsAction(items);
String query = !action.areItemsNew() ? "update tbl_items set data=? where ownerId=?" : "insert into tbl_items(data,ownerId) values(?,?)";
byte[] data = SerializationUtils.serialize(items.getItemContainers());
jdbcTemplate.update(query, new SqlLobValue(data), userId);
类似的东西（连同上述修改应该有效）。 （这或多或少来自我的脑海，因此可能需要一些调整）。使用适当的事务管理可确保一切都重用同一个连接而不是多个连接，它还确保连接在完成或出现问题时返回到池中。
我仍然建议使用不同的数据源，因为 C3P0 已经很旧了。
我们有一个基于 Spring 的应用程序，最近我们投入生产。我们使用的 Spring @Controller 最终命中了使用 JDBCTemplate 的 DAO。它正在使用 c3p0 的 ComboPooledDataSource
在负载增加时（大约 150 个并发用户），所有用户的应用程序都会挂起 - DataSource 被某些东西锁定 - 在线程转储上，大约有 200 个线程说 - 显然 DataSource 已死锁。
"http-bio-8080-exec-440" - Thread t@878
java.lang.Thread.State: WAITING
at java.lang.Object.wait(Native Method)
- waiting on <146d984e> (a com.mchange.v2.resourcepool.BasicResourcePool)
at com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1418)
at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:606)
at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:526)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutAndMarkConnectionInUse(C3P0PooledConnectionPool.java:756)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:683)
at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:140)
at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111)
at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77)
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:573)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:637)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:666)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:674)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:718)
在那之后，除非重新启动，否则应用程序将无法使用。发生这种情况时，DBA 团队没有观察到数据库上有任何负载。
当时c3p0是这样配置的：
app_en.driverClass=com.mysql.jdbc.Driver
app_en.user=tapp_en
app_en.password=tapp_en
app_en.jdbcUrl=jdbc:mysql://10.10.0.102:3306/tapp_en?useUnicode=true&characterEncoding=utf-8&autoReconnect=true
app_en.acquireIncrement=5
app_en.maxIdleTime=3600
app_en.maxIdleTimeExcessConnections=300
app_en.unreturnedConnectionTimeout=3600
app_en.numHelperThreads=6
app_en.minPoolSize=20
app_en.maxPoolSize=100
app_en.idleConnectionTestPeriod=120
app_en.testConnectionOnCheckin=true
之后，我如下更改了 c3p0 的配置 - 并为 com.mchange.v2.c3p0 包启用了 DEBUG 日志记录：
app_en.driverClass=com.mysql.jdbc.Driver
app_en.user=tapp_en
app_en.password=tapp_en
app_en.jdbcUrl=jdbc:mysql://10.10.0.102:3306/tapp_en? useUnicode=true&characterEncoding=utf-8&autoReconnect=true
app_en.acquireIncrement=5
app_en.maxIdleTime=180
app_en.maxIdleTimeExcessConnections=60
app_en.unreturnedConnectionTimeout=30
app_en.checkoutTimeout=10000
app_en.numHelperThreads=12
app_en.debugUnreturnedConnectionStackTraces=true
app_en.initialPoolSize=10
app_en.maxPoolSize=100
app_en.idleConnectionTestPeriod=120
app_en.preferredTestQuery="select 1 from tbl_users"
有了这个配置，我再次 运行 负载测试，应用程序仍然挂起...尽管线程在无法获得与数据库的连接后恢复。尽管如此，尽管线程已恢复，但与以前的配置不同，游戏因太多用户而挂起 - 因此他们不得不重新启动客户端。 尽管启用了所有日志记录，但 c3p0 日志不记录任何死锁消息。我看到的错误消息是：
[06/24/2015 12:20:54] [C3P0PooledConnectionPoolManager[identityToken->1oed6dl9a9ak8qsgqfvdu|4d6145af]-HelperThread-#10] DEBUG NewPooledConnection - com.mchange.v2.c3p0.impl.NewPooledConnection@7f0bc55a closed by a client.
java.lang.Exception: DEBUG -- CLOSE BY CLIENT STACK TRACE
at com.mchange.v2.c3p0.impl.NewPooledConnection.close(NewPooledConnection.java:659)
at com.mchange.v2.c3p0.impl.NewPooledConnection.closeMaybeCheckedOut(NewPooledConnection.java:255)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPoolPooledConnectionResourcePoolManager.destroyResource(C3P0PooledConnectionPool.java:621)
at com.mchange.v2.resourcepool.BasicResourcePoolDestroyResourceTask.run(BasicResourcePool.java:1024)
at com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:696)
应用程序中没有任何 t运行saction，我们也没有使用任何 T运行sactionManager 或 T运行sactionTemplate。我想知道这是否可能是所用框架中的某种错误或配置错误。这些是使用的相关框架：
c3p0-0.9.5-pre8
mysql-connector-java-5.1.24
spring-core-3.2.1.RELEASE
spring-web-3.2.1.RELEASE
mchange-commons-java-0.2.7
我们非常感谢任何帮助，因为这阻碍了我们发布产品的努力。
P.S。编辑： 这里是数据源的配置：
<bean id="app_en_DataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
destroy-method="close">
<property name="driverClass" value="${app_en.driverClass}" />
<property name="jdbcUrl" value="${app_en.jdbcUrl}" />
<property name="user" value="${app_en.user}" />
<property name="password" value="${app_en.password}" />
<property name="acquireIncrement" value="${app_en.acquireIncrement}"></property>
<property name="maxIdleTime" value="${app_en.maxIdleTime}"></property>
<property name="maxIdleTimeExcessConnections" value="${app_en.maxIdleTimeExcessConnections}"></property>
<property name="unreturnedConnectionTimeout" value="${app_en.unreturnedConnectionTimeout}"></property>
<property name="checkoutTimeout" value="${app_en.checkoutTimeout}"></property>
<property name="numHelperThreads" value="${app_en.numHelperThreads}"></property>
<property name="debugUnreturnedConnectionStackTraces" value="${app_en.debugUnreturnedConnectionStackTraces}"></property>
<property name="initialPoolSize" value="${app_en.initialPoolSize}"></property>
<property name="maxPoolSize" value="${app_en.maxPoolSize}"></property>
<property name="idleConnectionTestPeriod" value="${app_en.idleConnectionTestPeriod}"></property>
<property name="preferredTestQuery" value="${app_en.preferredTestQuery}"></property>
</bean>
这里是应用程序内部的一些代码，没有直接使用 jdbcTemplate。没有别的东西可以做到这一点，其他一切都是 jdbcTemplate.update, jdbcTemplate.query:
Connection conn = null;
ResultSet getItemsRS = null;
try {
JdbcTemplate jdbcTemplate = getJdbcTemplate(database);
conn = jdbcTemplate.getDataSource().getConnection();
UserItems items;
if (!action.areItemsNew()) {
conn.setAutoCommit(false);
conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
PreparedStatement getItemsPS = conn.prepareStatement("select * from tbl_items where ownerId = ? for update",
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_UPDATABLE);
getItemsPS.setLong(1, userId);
getItemsRS = getItemsPS.executeQuery();
getItemsRS.next();
items = new UserItemsRowMapper().mapRow(getItemsRS, getItemsRS.getRow());
} else {
items = new UserItems();
}
action.doUserItemsAction(items);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(items.getItemContainers());
oos.close();
byte[] data = baos.toByteArray();
Blob blob = conn.createBlob();
blob.setBytes(1, data);
if (!action.areItemsNew()) {
getItemsRS.updateBlob("data", blob);
getItemsRS.updateRow();
} else {
jdbcTemplate.update("insert into tbl_items(ownerId,data) values(?,?)", userId, data);
}
} catch (Exception e) {
logger.error(e);
throw new RuntimeException(e);
} finally {
if (!action.areItemsNew()) {
try {
conn.commit();
conn.close();
} catch (SQLException e) {
logger.error(e);
throw new RuntimeException(e);
}
}
}
此代码的原因是我想在通过此操作 action.doUserItemsAction(items) 更新用户项目之前阻止 reading/writing 如上所述。
所以，有几件事。
1) 你看到的 "error" 消息不是错误，当 c3p0 记录一个消息以 DEBUG 开头的异常时，这意味着你正在记录 DEBUG 级别并且 c3p0 生成了异常只是为了捕获堆栈跟踪。 （c3p0 是一个旧库；Thread.getStackTrace() 当时不存在，创建异常是捕获和转储堆栈的便捷方式。）您只是记录了由于过期或测试失败。一般来说，c3p0 期望在 INFO 记录，在 DEBUG 级别会非常冗长。
2) 你没有死锁 c3p0 的线程池。如果是，您会看到 APPARENT DEADLOCK 条消息，然后是恢复。您遇到池耗尽的情况：客户端正在等待连接，但池处于 maxPoolSize 且无法获取它们。
3) 池耗尽的通常原因是连接泄漏：在应用程序代码路径中的某个地方，在某些（可能是异常的）情况下，连接被获取，然后永远不会关闭（）。您需要非常小心，以确保 Connections 在 finally 块中可靠地关闭（），其方式不能由于 finally 块中的先前故障而被跳过。在 Java 7+ 中，使用 try-with-resources。在旧版本中，使用 reliable resource cleanup idiom.
4) 要测试连接泄漏是否是问题所在，请设置 c3p0 配置参数 unreturnedConnectionTimeout and debugUnreturnedConnectionStackTraces。 unreturnedConnectionTimeout 会解决这个问题，但是糟糕。更重要的是，debugUnreturnedConnectionStackTraces 会告诉你问题出在哪里，以便你可以修复它，记录在 INFO 打开未关闭异常的堆栈跟踪。 （您必须为 debugUnreturnedConnectionStackTraces 设置 unreturnedConnectionTimeout 才能产生任何效果；当连接超时时堆栈跟踪被记录为已放弃。）
5) 尽管 0.9.5-pre8 可能没问题，但 c3p0 的当前生产版本是 c3p0-0.9.5.1（取决于 mchange-commons-java v.0.2.10）。您可能会考虑使用它。我不认为这与您的问题有任何关系，但仍然。
希望对您有所帮助！
更新： 由于您现在发布了显示可能的连接泄漏的代码，这里有一个关于如何修复它的建议。将您的 finally 块替换为：
} finally {
if ( conn != null ) {
try { if (!action.areItemsNew()) conn.commit(); }
catch (SQLException e) {
logger.error(e);
throw new RuntimeException(e);
} finally {
conn.close()
}
}
}
更新 2： 重做上面的 finally 块将解决连接泄漏，但如果我是你，我也会更改此代码关于 commit() 的逻辑.这是建议的修订：
Connection conn = null;
ResultSet getItemsRS = null;
try {
JdbcTemplate jdbcTemplate = getJdbcTemplate(database);
conn = jdbcTemplate.getDataSource().getConnection();
UserItems items;
if (!action.areItemsNew()) {
conn.setAutoCommit(false);
conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
PreparedStatement getItemsPS = conn.prepareStatement("select * from tbl_items where ownerId = ? for update",
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_UPDATABLE);
getItemsPS.setLong(1, userId);
getItemsRS = getItemsPS.executeQuery();
getItemsRS.next();
items = new UserItemsRowMapper().mapRow(getItemsRS, getItemsRS.getRow());
} else {
items = new UserItems();
}
action.doUserItemsAction(items);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(items.getItemContainers());
oos.close();
byte[] data = baos.toByteArray();
Blob blob = conn.createBlob();
blob.setBytes(1, data);
if (!action.areItemsNew()) {
getItemsRS.updateBlob("data", blob);
getItemsRS.updateRow();
conn.commit();
} else {
jdbcTemplate.update("insert into tbl_items(ownerId,data) values(?,?)", userId, data);
}
} catch (Exception e) {
logger.error(e);
throw new RuntimeException(e);
} finally {
try { if ( conn != null ) conn.close(); }
catch ( Exception e )
{ logger.error(e); }
}
现在 commit() 将只被调用 if (!action.areItemsNew()) 并且所有预期的操作都已成功。在 commit() 之前即使出现问题也会被调用。资源清理代码也更简单、更清晰。请注意，在建议的版本中，如果 close() 上有异常，它会被记录下来，但不会被包装并作为 RuntimeException 重新抛出。通常，如果 close() 上有异常，那么之前会有一个信息更丰富的异常，这就是您想要看到的异常。如果唯一发生异常的地方是 close()，这意味着所有数据库操作都已成功，因此尽管有错误，您的应用程序仍可以正确执行。 （如果 close() 上有很多异常，最终你会耗尽连接池，但实际上只有当你的数据库或网络出现严重问题时才会发生这种情况。）
您的代码有潜在的危险并且有连接泄漏，当您自己检查连接时，您应该始终关闭它，可能会出现关闭连接失败的情况。
相反，我强烈建议使用 Spring 来管理您的事务和连接。
首先用 @Transactional(isolation=SERIALIZABLE) 注释您的方法。接下来将 DataSourceTransactionManager 和 <tx:annotation-driven /> 添加到您的配置中。这些更改后重写您拥有的数据访问代码。
JdbcTemplate jdbcTemplate = getJdbcTemplate(database);
final UserItems items;
if (!action.areItemsNew()) {
items = jdbcTemplate.queryForObject("select * from tbl_items where ownerId = ? for update", userId, new UserItemsRowMapper());
} else {
items = new UserItems();
}
action.doUserItemsAction(items);
String query = !action.areItemsNew() ? "update tbl_items set data=? where ownerId=?" : "insert into tbl_items(data,ownerId) values(?,?)";
byte[] data = SerializationUtils.serialize(items.getItemContainers());
jdbcTemplate.update(query, new SqlLobValue(data), userId);
类似的东西（连同上述修改应该有效）。 （这或多或少来自我的脑海，因此可能需要一些调整）。使用适当的事务管理可确保一切都重用同一个连接而不是多个连接，它还确保连接在完成或出现问题时返回到池中。
我仍然建议使用不同的数据源，因为 C3P0 已经很旧了。