本次问题相当的恶心,报错Could not get a resource from the pool，二话不说，先上图。
问题出现的背景
公司有个配置银行客户端首页的项目，通过web进行配置，开放几个客户端的接口给安卓获取首页的信息。由于银行一般并发比较大，客户端接口每一个接口都将数据缓存到了redis中，用来减少数据库的压力。通过jedis链接池配置redis，配置如下，版本为，springboot2.1.3.RELEASE，jedis版本为springboot版本自带的2.9.1。后来银行进行压测，发现链接池逐步升高，无法释放，最后导致链接数不足。
排查过程
通过排查发现如果仅仅如此配置jedis链接池无法生效，最大链接池为500，最小链接池为50，那么当项目运行起来的时候，redis应该最少有50个链接。后台通过redis命令发现，链接的数量只有8个，说明配置的jedis链接池没生效。那就好说了，我认为我的问题点已经发现了，接下来就开始解决链接池为什么不生效。通过各方查资料发现springboot2.1.3.RELEASE默认是使用的lettuce链接池，所以配置的jedis链接池自然无效，但是好像lettuce链接池网上风评不好，还是决定用jedis，那么就通过pom文件，将lettuce的包排除并加入jedis的包。如下图
将lettuce包排除完毕后，打包发布，发现redis中的连接数正常了，为52个链接。当我信心满满的以为搞定了的时候，行方再次压测十四个小时，又出现了链接池满了的情况。我很懵，明明链接池已经搞定为何还不释放链接，我接口加缓存的方式是通过@CacheAble注解加的缓存，也就是不需要手动关闭链接，那为何链接关不上呢？于是又是各种检查代码发现看不出问题。后来我根据Could not get a resource from the pool下面这个错误查询资料，终于让我发现了一个博客Jedis Timeout waiting for idle object | IOTXING。
上面写的是jedis2.9.1有bug，在高并发的情况下会有内存泄漏的bug。千算万算没算到包有问题，后来将jedis版本升到2.10.2，问题解决。
