jedis 2.9.0 - 2.10.2

强几天我们用的redis突然报错：Could not get a resource from the pool

看了好多 都是说 jedis的连接池 不能自动关闭连接，需要手动关闭

  Jedis jedis = null;
        try {
            jedis = JredisClient.getJedis();
            jedis.hset(SsojcProperty.getConfig("sso.skey"), key, value);
        } finally {
            if (jedis != null) {
                //SingleJredisPool.jredisPoolINS.getJedisPool().returnResource(jedis);
                jedis.close();
            }
        }

需要自己在finally 里面自己关闭连接。
从2.1 到 2.9 分别
需要用上面两个关闭的方法

我这边看了一遍代码逻辑，发现我这边的代码是没有问题的，都是在finally 关闭了这个连接，但是我用2.1版本 进行测试环境压测的时候，发现用300压了1个半小时后，会出现上述问题，但是系统不会彻底down掉，停掉压测后，系统可以正常访问。但是我用300压了两个小时后，测试服务器由于io太高彻底宕机了。

但是从目前的现象上来看，明显是有一个连接释放的过程。说明从程序逻辑上来讲，我这里是不涉及到连接没有释放的，这种逻辑上的硬伤。
所以我这边能做的只能是将jedis版本升级一波看看，第一次想着升级直接升级到3.7 虽然不是4.0吧，但是我觉得靠谱，
主要是系统jdk还是1.7 感觉有点不行。但是用3.7上了一版后，发现是真的不行，3.7支持1.8，不支持1.7.瞬间就无了。那个时候还是下班时间，没有办法寻找运维，我就把3.7降级为3.1
。上线了一波 成功了。
为了预防服务器宕机，我这边就把redis连接数改为10 ，然后用5个线程 开始压测，压了一个半小时后，该问题开始重复出现，然后继续压测，压到两个多小时后 ，发现服务redis连接池彻底满了。说实话，我慌了。。 这明显是程序出了问题，连接没有释放或者程序泄露，我在网上查了很久，最后在githb这个链接上面看到了说是2.10有问题，2.10.2的话实验上目前没问题，但是还有人回复说是用了一段时间后出现了问题。

然后我用了2.9 开始一波测试，测了一天，用10个线程压测了一天 没有任何问题，当时的我开心的一笔，当时就称 2.9 永远的神
然后这边要求压测出一个最大的并发数量。我就开始用 50 30 20 发现当用20的压测了 2个小时 线程池满了 。
只能说 jedis yyds 人已经傻了，最后 只能是接受 jedis 本来就是 线程不安全的

改成
redis Lettuce 链接吧 。

jedis的话 只能希望有大佬给一个比较稳定的版本。
但是从程序设计上来看，jedis本来就无法满足高并发的需求 从根源上就是错的