自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被关闭了,如下