已经一个多月没有写东西了，不过最近确实很忙。前两天在线上碰到一个C3P0的链接死锁的异常，话说这个上古神物 ,我已经是很久不碰了。先贴异常

异常截图

"apparent deadlocks"：名词解释是说c3p0拿到链接之后，最终使用之后没有返回到pool,导致死链检测失败。经过在stack Overflow检索,https://stackoverflow.com/questions/3730844/c3p0-apparent-deadlock-when-the-threads-are-all-empty.发现增加一个statementCacheNumDeferredCloseThreads该参数的定义，就可以避免这个问题。

经过查看官方文档：http://www.mchange.com/projects/c3p0/#statementCacheNumDeferredCloseThreads

解释：如果把该值设为超过1，statement的缓存就会自动跟踪当前可用的connections,如果没有再用，就会自动销毁掉。如果需要另外的线程来专门销毁缓存的statement,则还需要设置maxStatements与maxStatementsPerConnection。

再贴一个官方的说明：

Configuring Statement Pooling

c3p0 implements transparent PreparedStatement pooling as defined by the JDBC spec. Under some circumstances, statement pooling can dramatically improve application performance. Under other circumstances, the overhead of statement pooling can slightly harm performance. Whether and how much statement pooling will help depends on how much parsing, planning, and optimizing of queries your databases does when the statements are prepared. Databases (and JDBC drivers) vary widely in this respect. It's a good idea to benchmark your application with and without statement pooling to see if and how much it helps.

You configure statement pooling in c3p0 via the following configuration parameters:

maxStatements

maxStatementsPerConnection

statementCacheNumDeferredCloseThreads

maxStatementsis JDBC's standard parameter for controlling statement pooling.maxStatementsdefines the total numberPreparedStatementsa DataSource will cache. The pool will destroy the least-recently-used PreparedStatement when it hits this limit. This sounds simple, but it's actually a strange approach, because cached statements conceptually belong to individual Connections; they are not global resources. To figure out a size formaxStatementsthat does not "churn" cached statements, you need to consider the number offrequently usedPreparedStatements in your application,and multiply that by the number of Connections you expect in the pool (maxPoolSizein a busy application).

maxStatementsPerConnectionis a non-standard configuration parameter that makes a bit more sense conceptually. It defines how many statements each pooled Connection is allowed to own. You can set this to a bit more than the number ofPreparedStatementsyour applicationfrequentlyuses, to avoid churning.

If either of these parameters are greater than zero, statement pooling will be enabled. If both parameters are greater than zero, both limits will be enforced. If only one is greater than zero, statement pooling will be enabled, but only one limit will be enforced.

大概意思就是这两个，有一个值如果大于0，c3p0的statement pool就会发生作用。

以上所有的配置都是基于c3p0的最新版本。PS一下，还是2015年的JAR。

通过引入最新的C3P0包，另外增加了两段配置，线上观察两天，问题解决。

最后打个小广告，JAVA世界最快的JDBC连接池，非HikariCP莫属。已经甩c3p0好几个街角，有图有真像。