c3p0----获取不到链接

最近别人的项目，因为经常获取不到链接出错，我好奇也就跟着摆弄了一把，使用的插件是：c3p0+spring+ibatiS，当然事务管理部分也配置上了配置如下：

 <bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
         destroy-method="close">
             <property name="driverClass" value="${jdbc.driverClassName}" />
             <property name="jdbcUrl" value="${jdbc.url}" />
             <property name="user" value="${jdbc.username}" />
             <property name="password" value="${jdbc.password}" />
             <property name="minPoolSize" value="${datasource.minPoolSize}" />
             <property name="maxPoolSize" value="${datasource.maxPoolSize}" />
             <property name="initialPoolSize" value="${datasource.initialPoolSize}" />
             <property name="maxIdleTime" value="${datasource.maxIdleTime}" />
             <property name="maxStatements" value="${datasource.maxStatements}" />
             <property name="idleConnectionTestPeriod" value="${datasource.idleConnectionTestPeriod}" />
             <property name="acquireIncrement" value="${datasource.acquireIncrement}" />
             <property name="acquireRetryAttempts" value="${datasource.acquireRetryAttempts}" />
             <property name="breakAfterAcquireFailure" value="${datasource.breakAfterAcquireFailure}" />
                 <property name="checkoutTimeout" value="${datasource.checkoutTimeout}" />
                 <property name="numHelperThreads" value="${datasource.numHelperThreads}" />
     </bean>

 <!-- 事务管理 -->
     <bean id="transactionManager"
         class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
         <property name="dataSource" ref="dataSource" />
     </bean>

     <!-- 事务拦截器 -->
     <bean id="transactionInterceptor"
         class="org.springframework.transaction.interceptor.TransactionInterceptor">
         <property name="transactionManager" ref="transactionManager" />
         <property name="transactionAttributes">
             <!-- 下面定义事务传播属性:key表示 service中的方法 -->
             <props>
                 <prop key="insert*">PROPAGATION_REQUIRED</prop>
                 <prop key="update*">PROPAGATION_REQUIRED</prop>
                 <prop key="delete*">PROPAGATION_REQUIRED</prop>
                 <prop key="select*">PROPAGATION_REQUIRED,readOnly</prop>
                 <prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
                 <prop key="query*">PROPAGATION_REQUIRED,readOnly</prop>
                 <prop key="pageQuery*">PROPAGATION_REQUIRED,readOnly</prop>
                 <prop key="*">PROPAGATION_REQUIRED</prop>
             </props>
         </property>
     </bean>
     <!-- BeanName auto proxy to define the interceptor -->

     <bean
         class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
         <property name="beanNames">
             <list>
             <!-- 配置需要事务管理的service -->
                 <value>*Service</value>
                 <value>*ServiceImpl</value>
             </list>
         </property>
         <property name="interceptorNames">
             <list>
                 <value>transactionInterceptor</value>
             </list>
         </property>
     </bean>

上面的配置有点长，捡几个比较重要的项说明吧：

datasource.minPoolSize=30
datasource.maxPoolSize=80
datasource.initialPoolSize=40
datasource.maxIdleTime=60
datasource.acquireIncrement=5

datasource.idleConnectionTestPeriod=60
datasource.maxStatements=0
datasource.acquireRetryAttempts=30
datasource.breakAfterAcquireFailure=false
datasource.testConnectionOnCheckout=false
datasource.checkoutTimeout=20000
datasource.numHelperThreads=10

配置都很常规，任务线程数从默认的3加大到10，这也比较可取，因为minpoolSize是30，初始化的时候建的pool是40，每次增加5个链接数。

趁此机会，又看了把c3p0的源码，我写了个很简单的测试，当然配置完全一模一样，不过结构上使用的是mybatis，然后只是使用了get方法，假定所有的业务逻辑都走了正常的transaction拦截器：即所有的链接在用完都把链接还回去了。

1. 先是从100线程数，并发调用使用c3p0链接的service方法，发现毫无压力。显然100太小儿科了。
2. 大力一把，将线程数加到1000，这样一来，就有一些（为数不多的几个线程获取不到connection了），即c3p0内部获取链接的方法：

    private synchronized Object prelimCheckoutResource( long timeout )
        throws TimeoutException, ResourcePoolException, InterruptedException
        {
            try
            {
                ensureNotBroken();
   
                int available = unused.size();
                if (available == 0)
                {
                    int msz = managed.size();
   
                    if (msz < max)
                    {
                        // to cover all the load, we need the current size, plus those waiting already for acquisition,
                        // plus the current client
                        int desired_target = msz + acquireWaiters.size() + 1;
   
                        if (logger.isLoggable(MLevel.FINER))
                            logger.log(MLevel.FINER, "acquire test -- pool size: " + msz + "; target_pool_size: " + target_pool_size + "; desired target? " + desired_target);
   
                        if (desired_target >= target_pool_size)
                        {
                            //make sure we don't grab less than inc Connections at a time, if we can help it.
                            desired_target = Math.max(desired_target, target_pool_size + inc);
   
                            //make sure our target is within its bounds
                            target_pool_size = Math.max( Math.min( max, desired_target ), min );
   
                            _recheckResizePool();
                        }
                    }
                    else
                    {
                        if (logger.isLoggable(MLevel.FINER))
                            logger.log(MLevel.FINER, "acquire test -- pool is already maxed out. [managed: " + msz + "; max: " + max + "]");
                    }
   
                    awaitAvailable(timeout); //throws timeout exception
                }

   直接到39行进行等待，其实也不难看出，available==0了，然后不管是否进行 _recheckResizePool();这个操作都需要等着。这里的等待时间，是配置的checkoutTimeout=2000，这么长时间的等待都木有资源可用。按照以往的理解，c3p0的实际上有进行连接池的扩展和收缩链接数的操作的对不，往下看，其实能看出来在_recheckResizePool()方法中就有进行扩容的判断的操作的：

      int desired_target = msz + acquireWaiters.size() + 1;
   
                        if (logger.isLoggable(MLevel.FINER))
                            logger.log(MLevel.FINER, "acquire test -- pool size: " + msz + "; target_pool_size: " + target_pool_size + "; desired target? " + desired_target);
   
                        if (desired_target >= target_pool_size)
                        {
                            //make sure we don't grab less than inc Connections at a time, if we can help it.
                            desired_target = Math.max(desired_target, target_pool_size + inc);
   
                            //make sure our target is within its bounds
                            target_pool_size = Math.max( Math.min( max, desired_target ), min );
   
                            _recheckResizePool();
                        }

   当等待的任务过大时，target_pool_size = Math.max( Math.min( max, desired_target ), min );会进行将target_pool_size置为max值。

      if ((shrink_count = msz - pending_removes - target_pool_size) > 0)
                    shrinkPool( shrink_count );
                else if ((expand_count = target_pool_size - (msz + pending_acquires)) > 0)
                    expandPool( expand_count );

   这里的target_pool_size是业务当前需要的目标size，这里会有歧义，msz是当前的poolsize，

   pending_acquires是当前等待获取资源的任务数，有可能很大，expand_count = target_pool_size - (msz + pending_acquires)) > 0这个条件的结果：expand_count= 80 - (40+ 40) <=0 ，所以当等待资源过大，但是当业务线程数过大时，链接并未被扩容，原因就在这里。瞬间并发到超峰值。所以当等待资源都timeout到很小值或者有资源使用完并还回链接后，新的请求进来时，该判断条件满足后，会进行资源的重新添加任务。至于如何添加任务，也是很常规的，即一个链接资源的新建需要一个线程，所以上面的配置10个线程，同时间内（理论上）只能创建10个链接，不过task的run方法都很瞬时，也能满足一定量的创建。

   而在创建资源的线程中，有一个竞争条件：synchronized ( ThreadPoolAsynchronousRunner.this )，所以这里可以说是并发创建资源的瓶颈，而当线程池都满了后，c3p0的expand就没什么作用了，它没有expand的作用，这时候只能通过回收现有资源重复使用，或者某个链接坏了，重新创建