JedisPool的close()方法执行后回收连接问题初探

自Jedis3.0版本后jedisPool.returnResource()遭弃用,官方重写了Jedis的close方法用以代替

官方建议应用redis.clients.jedis#Jedis的close方法进行资源回收

close()源码如下：

正常连接的回收，走的是3409行的returnResource(this)方法

而实际上这个方法也是被弃用了的

先不扯这些，过时就过时吧 ，我们往下看。

关闭方法里面，主要有这样一个标志的修改

从ALLOCATED(分配)状态改为了RETURNING(归还)状态，但是，在使用这个连接的时候，并没有对这个状态进行校验！

也就是说，回收之后的连接，依然可以继续使用。

见下图：

如图所示，连接jedis被回收后，重新分配到了jedis10上面，地址是一样的。

而这两个连接都可以使用，并都可以获取到值！

疑问：

如果这样设计的话 ，一个连接A被分配出去了，收回之后对A的使用毫无影响。

那会造成一个连接，可能同时在被N个用户使用，会有问题的。

我不知道是我不能理解JedisPool设计的精妙，还是这本身就是一个糟糕的设计或者bug呢？

求教！谢谢！

ps：有人问 一个连接，同时在被N个用户使用，会有什么问题。

我其实并不清楚具体会造成哪些问题，同问这个！

但我知道，连接池的设计就是为了避免频繁创建连接的开销，如果可以一个连接大家一起用，我完全可以new 一个final的连接一直不关闭，为什么还用连接池呢？是吧

有人提供了官网的文档，但好像对本问题没有什么帮助，给大家参考一下

这个文档只是说明了，分配后不关闭连接会导致连接池变慢，超时会自动回收。

不理解，提了一个issue

我的issue被关闭了，如下