最近其他团队的开发人员告知我，我们项目有个feign接口调用失败了。我查看日志发现，其原因是尝试数据库连接超时，30秒内都没有连接成功。
我首先判断可能是网络不稳定，在一定时间内连接不上数据库。我登录到服务器环境看，尝试用命令行连接数据库，结果很快库连接上了，并没有命令行等待很久才有反应。后面再尝试使用ping命令测试网络，发现网络延迟很低。根据这些东西，我判断不太可能会有30秒都连接失败。
接下来我继续查看前一天的日志，发现了一个有意思的现象，这几天都是同一时间段发生了大量的database connect timeout 现象。以我对这项目的了解度，我马上就想到了这段时间有一两个定时任务，这两个定时任务都是多线程任务，并且有量的查询和写入数据，但之前都是20分钟左右跑完数据，一般会在这此事故发生段之前就执行完。看下xxl-job的执行日志，确实是在我预先的时间就开始跑任务，但是服务应用的日志却又发现在事故发生时还有定时任务在处理中，并且也都失败了，还进行了事务回滚。
大致可以判断是因为获取数据库连接的请求太多了，导致数据库连接超时。接下来我用sql脚本show GLOBAL VARIABLES like '%connect%'查看了下，数据库的最大总连接数、单用户最大连接数，结果如下图所示，八千多的连接上限，我想我的项目实时的连接数还不至于这么大。

不是数据库服务端的问题，就可能是数据库客户端的问题，所以我就只能去我的项目应用中去排查问题。根据应用错误日志，很快排定位到是com.zaxxer.hikari.pool.HikariPool#getConnection(long)方法的代码片段throw createTimeoutException(startTime);抛出的超时异常。
可以推测PoolEntry poolEntry = connectionBag.borrow(timeout, MILLISECONDS);这行代码应该是没获取到数据库连接，poolEntry是null，也就是说没有从连接池借到mysql connection .
com.zaxxer.hikari.util.ConcurrentBag#borrow方法的主要逻辑是：
先尝试在线程独占变量threadList中获取未被使用的mysql connection （速度快）,若失败则从多线程共享变量sharedList获取connection（速度慢）,若在失败就到同步队列handoff中阻塞超时等待(速度最慢)。

可以看出这里没有真正去创建数据库连接，只是在从变量、队列中去取出连接，此方法只是到连接池中去拿连接、不创连接。根据方法来看，如果连接池中的对象一直都在被使用中，就只能在同步队列handoff上阻塞等待，直到触及其超时时间线，返回一个null给调用方。事实上也确实如此，定时任务持有大量的mysql connection,并在一段时间内没有释放，最终导致无法从连接池获取有效的连接，实际上真正的连接Driver.connect并未超时。
找到了事故原因，那么解决起来就比较容易了，大致有连个方向：1、增加连接池超时时间，2、增加连接池的连接数。
其实方案一，不太可靠，因为我们不知道到那些定时任务要多久才能完成业务逻辑、并释放数据库连接，并且如果一直等待连接池也会导致http接口超时。所以增加连接池的链接数是个可行的方案。我初步将连接池的最小空闲数定为32，最大连接数定位64。