我所使用的 SSM 框架自动整合了 C3P0 连接池，但是怎奈对 C3P0 不大熟悉，绕了不少圈子，在这里把自己的经验分享一下：
C3P0 连接错误
An attempt by a client to checkout a Connection has timed out
根本原因是连接池中连接耗尽或者连接时间设置得太小，所以要避免这一情况的发生。
我是直接采用 XML 的形式来配置 C3P0 的：
<!--适当加大maxPoolSize和minPoolSize -->
<property name="maxPoolSize" value="5000" />
<property name="minPoolSize" value="10" />
<!--自动超时回收 Connection,单位s,默认为0 -->
<property name="unreturnedConnectionTimeout" value="25" />
<!--配置超时自动断开 Connection,单位s,默认为0 -->
<property name="maxIdleTimeExcessConnections" value="20" />
<property name="maxConnectionAge" value="20" />
<!--设置成0，这样就不会有缓存的 preparedstatement -->
<property name="maxStatements" value="0" />
<!--每隔时间段检测一下 Connection-->
<property name="idleConnectionTestPeriod" value="50" />
<!--Connection 最大等待时间-->
<property name="checkoutTimeout" value="5000" />C3P0 参数详解
初始化时创建的连接数，应在minPoolSize与maxPoolSize之间取值。默认为3
initialPoolSize=20
接池中保留的最大连接数。默认为15
maxPoolSize=30
minPoolSize=20
当连接池中的连接用完时，C3P0一次性创建新连接的数目 默认 3
acquireIncrement=10
定义在从数据库获取新连接失败后重复尝试获取的次数，默认为30
acquireRetryAttempts=100
两次连接中间隔时间，单位毫秒，默认为1000
acquireRetryDelay=1000
连接关闭时默认将所有未提交的操作回滚。默认为false
autoCommitOnClose=false
获取连接失败将会引起所有等待获取连接的线程抛出异常。但是数据源仍有效保留，并在下次调用getConnection()的时候继续尝试获取连接。如果设为true，那么在尝试获取连接失败后该数据源将申明已断开并永久关闭。默认为false
breakAfterAcquireFailure=false
当连接池用完时客户端调用getConnection()后等待获取新连接的时间，超时后将抛出 SQLException，如设为0则无限期等待。单位毫秒，默认为0。时间设置过小时会出现连接超时.这样会抛出异常,设置时间时自己小心.按照实际情况设置适当的值.
checkoutTimeout=20000
最大空闲时间，超过空闲时间的连接将被丢弃。为0或负数则永不丢弃。默认为0
maxIdleTime=60
checkoutTimeout表示连接对象多长时间应该被销毁， 注意，是”应该“，但是谁来销毁它呢，需要一个线程按照idleConnectionTestPeriod设定的时间间隔去自动校验这些链接对象并销毁timeout的每60秒检查连接池中所有的空闲连接。Default: 0
idleConnectionTestPeriod=60
C3P0是异步操作的，缓慢的JDBC操作通过帮助进程完成。扩展这些操作可以有效的提升性能通过多线程实现多个操作同时被执行。默认为3
numHelperThreads=3
用户修改系统配置参数执行前最多等待的秒数。默认为300
propertyCycle=300
c3p0在同时关闭statement和connection的时候，或者关闭他们之间的时间很短的时候，有时候connection并没有被关闭，因为有些preparedstatement还在被cached住。这样就会有很多connection并没有真正的被关闭，连接池的连接都给耗尽了，就会产生异常。解决的方案就是把缓存关闭，也就是把c3p0.max_statements 设置成0，这样就不会有缓存的preparedstatement
maxStatements=0