使用Jedis连接池导致Redis连接无限增长问题（答案）

接上文，压测反馈的Redis-Server连接用尽，由于测试用例非常简单，所以直接对Jedis源码进行分析

1. 源码分析

包类相关继承系细节不再多说，大家可以下源码参照。

JedisSharding继承UnifiedJedis使用ShardedConnectionProvider，这种设计模式比早期Jedis2.x要规整太多了，使用也更加便捷。

无论是UnifiedJedis还是ShardedConnectionProvider都实现了AutoCloseable，所以如果没有低级错误，不会出现源码层面的连接泄漏，再往下看

如果要调用Redis的get方法，调用链路： JedisSharding::get -> UnifiedJedis:get -> DefaultCommandExecutor::executeCommand(CommandObjects::get)，所以池内申请一定是在executeCommand中完成

代码没有问题，try() 自动释放 AutoCloseable资源。

2. 分析结论

所以对于源码分析结论，完全没有任何问题，全部使用AutoClosable，并由try()包裹。那会不会是连接池本身在不停的增长，测试中因为代码BUG产生了多个连接池？

3. 根因定位

排除外部问题后，那说明问题一定出在我们简单的测试用例上（很简单，如果出错一定是低级错误），上代码（核心片段）

1) 连接池初始化部分

看似没有问题 

2) 方法调用

因为公司的资源都是通过zookeeper配置中心获得的

如果出现问题一定是在这里，会初始化多次连接池，且每一次初始化不会关闭原有池，但是如果网络稳定应该不会，但真的网络稳定吗？

检查日志 ，看看几天内有没有相关网络变动日志输出

WTF，WTF, WTF ..., 公司测试内网不稳？？！！！

最终问题定位了，在这里，一个BUG

4. 修改

上代码

测试一周后，连接池不高于最大值64，问题解决

5. 总结 

        在稳定性压测过程中，因为一个白盒测试人员的低级错误引发的资源泄漏问题，让开发忙乎了不少时间。当然在此过程中，同学们也加深了对Jedis源码的理解，在此分享出来，接上文从如何通过运维命令进行排查到本文对于源码的分析，帮新入坑的同学少走一点弯路。