背景

之前在压测一个用java写的应用时，偶尔会报如下的错误：

org.springframework.transaction.CannotCreateTransactionException: Could not open JDBC Connection for transaction; nested exception is java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30002ms.
    at org.springframework.jdbc.datasource.DataSourceTransactionManager.doBegin(DataSourceTransactionManager.java:305)
    at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:378)
    at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:474)
    at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:289)
    at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:98)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:185)
    at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)
    at com.quantil.cm.api.service.PurgeTaskService$$EnhancerBySpringCGLIB$$b4db5835.create(<generated>)

排查过程

1. MySQL最大连接数排查

show variables like '%conn%'

image.png

MySQL设置的最大连接数为32768，API开启的连接池也只有100个，因此排除这个原因

2. MySQL连接池泄露

百度找了一下相关资料，发现有可能是因为MyBatis自定义拦截器没有释放连接的原因。

因为这个java应用也自定义了一个拦截器用来分页，但是连接本地数据库进行压测的时候并没有出现这个错误，因此也排除了连接池泄露的原因

3. 源码研究

直接在IDEA查找关键字Connection is not available，发现只有在HikariPool.java的方法getConnection里面会抛错throw createTimeoutException(startTime)
方法代码如下：

public Connection getConnection(final long hardTimeout) throws SQLException
   {
      suspendResumeLock.acquire();
      final long startTime = currentTime();

      try {
         long timeout = hardTimeout;
         do {
            PoolEntry poolEntry = connectionBag.borrow(timeout, MILLISECONDS);
            if (poolEntry == null) {
               break; // We timed out... break and throw exception
            }

            final long now = currentTime();
            if (poolEntry.isMarkedEvicted() || (elapsedMillis(poolEntry.lastAccessed, now) > ALIVE_BYPASS_WINDOW_MS && !isConnectionAlive(poolEntry.connection))) {
               closeConnection(poolEntry, poolEntry.isMarkedEvicted() ? EVICTED_CONNECTION_MESSAGE : DEAD_CONNECTION_MESSAGE);
               timeout = hardTimeout - elapsedMillis(startTime);
            }
            else {
               metricsTracker.recordBorrowStats(poolEntry, startTime);
               return poolEntry.createProxyConnection(leakTaskFactory.schedule(poolEntry), now);
            }
         } while (timeout > 0L);

         metricsTracker.recordBorrowTimeoutStats(startTime);
         throw createTimeoutException(startTime);
      }
      catch (InterruptedException e) {
         Thread.currentThread().interrupt();
         throw new SQLException(poolName + " - Interrupted during connection acquisition", e);
      }
      finally {
         suspendResumeLock.release();
      }
   }

大概看了一下这个方法做的事情，其实就是从连接池里面去borrow一个连接，然后返回。如果borrow了30s还没borrow到，那么就会抛错了。

这个时候真相呼之欲出了，什么情况会造成获取连接池连接超时？

• 连接泄露
  某些线程拿到了连接后没有归还，持续久了就出问题
• 连接归还连接池太慢
  极端点，数据库响应时间要花1s，10个连接池1秒也只能处理10个请求。这个时候如果有500个并发那得50s才能处理完，这不就超时了
• 连接归还连接池很快，但是借的线程太多
  数据库响应很快，无奈并发太高，远超连接池大小。假设连接池只有10个连接，但是有100个线程在borrow连接的话，是不是有可能会出现某些倒霉的线程30s一直borrow不到连接的情况？

本例排除了前两种可能，因此猜测是第三种原因。 并发数远大于连接池大小，导致有可能出现某些线程30s内一直获取不到连接，从而抛错

bug本地复现

既然是怀疑并发数大于连接池大小大致的，那我们将hikari的线程数设置成10（设置小点避免引入数据库的干扰），然后开500并发来测试本地java应用
spring.datasource.hikari.maximum-pool-size=10
ab压测命令
ab -c 500 -n 50000 -p body.json http://127.0.0.1:8080/api/test

1. 本地数据库复现
   无法复现？？？？！！！！
   10个连接，500个并发都能完美处理过来！！！
   怀疑是因为本地通信太快了，500个并发可能还不足以看出来。（这里没有再往上调并发数，理论上应该调大也能复现，就是不知道得多大。。。）

2. 远程数据库复现
   换成和java应用不在同一个内网的外网数据库
   ab刚启动没一会，java应用就抛出了这个可爱的错误！
   nice！

如何解决

既然问题是因为并发数远大于连接池大小导致的，那么有以下几个解决方案：

• 增加连接池大小
  简单暴力，如果你可以预见并发数的上限的话
• 数据库和api部署在同一个内网
  加快单个请求的响应速度，较少线程等待时间

其实个人以为这个问题基本无解，要是并发数无限提高的话还是一样会出问题。

这个问题就和偶尔网络抽风一样，概率挺小的，感觉可以不用管~

后话

该错误的本质原因其实就是线程去borrow连接超时抛出的，超时的原因说白了就是超时时间内一直拿不到可用连接，因此可以从这方面下手去排查。