Jedis是Redis的Java客户端实现，封装了对Redis的通信和命令处理等。
Jedis提供了资源池，可以很方便地实现对Redis的API调用。
之前是通过组内对Jedis封装的Spring Bean来获取和使用Jedis的，现在希望自行实现类似功能，设计目标如下：
具体思路就是针对设计目标而定的：
由于需求比较基础，还没有太多应用场景，实现也没考虑太复杂。整体逻辑不到50行，可以在 我的GitHub 上大致看一下。
后续使用可以直接使用Spring将Bean注入。
由于不按常规方法使用JedisPool可能背离了JedisPool设计的使用场景，因此在其中踩了不少坑。
其次，虽然平常常用组内的Jedis组件，但实际上对Jedis的API不了解，本次根据平常使用过程中的一些感受进行“黑盒临摹”，在爬坑过程中其实也学习了其他一些方面的经验，比如Guava Reflections等。
背景
最开始通过FactoryBean提供的连接并未使用动态代理，也就是说仅提供了一个Jedis，所有线程使用同一个Jedis连接。
现象
业务中较频繁地报异常，异常信息为 java.lang.ClassCastException: java.util.ArrayList cannot be cast to [B 等，基本是 ClassCastException ，异常抛出位置为调用Jedis的位置。
原因
最终在另一篇资料指引下来到jedis/issues，在 参考资料 中发现了最可信最合理的原因：Jedis并非线程安全，不应当并发操作。
正确使用
正如参考资料中回答提到的，每个线程（每次调用）都从JedisPool中获取一个连接，并在使用后归还。
也正是因为这一点跟最初的FactoryBean封装方式冲突了，后来才改用提供动态代理类的方式封装FactoryBean。
背景
我使用的Jedis版本为3.0.1，网上的不少资料指出在使用连接后归还可以使用JedisPool的 void returnResource(Jedis resource) 方法，但在3.0.1版本中这个方法是protected可见的，没有间接调用方法。
另外Jedis源码中找不到注释，这有点奇怪，我想当然地认为版本升级后可以自动归还资源了，于是仅在设置最大连接数之后就部署到业务中了。
现象
业务线程启动后每访问一定次数（调用Jedis达到一定次数）后就完全不响应请求了：
还是在 参考资料 的指引下查看Tomcat监听的端口，的确很多连接处于 CLOSE_WAIT 状态，表明客户端已断开连接（我自己测试的时候刷新页面太多，很多就中途断开了）。
原因
结合TCP四次挥手过程，应该是中间有资源释放不了导致没有进入 LAST_ACK 状态，推测是Jedis连接资源未归还而总连接数有限制，导致很多线程在等待获取Jedis资源。
正确使用
在Jedis连接使用完毕后，需要调用Jedis的 close() 方法将资源归还JedisPool， close 方法是用于替代 returnResource 方法的。
这个方法语义比较奇怪，真实作用是“ 归还或 关闭连接”，最开始其实就是考虑到资源复用的问题才没有考虑使用这个 close 方法的。
对比了一下组内的组件，思路差不多，还有以下的点能够扩展：
ClassCastException - B cannot be cast to java.lang.Long · Issue #186 · xetorthio/jedis
nginx 499状态码 - 微信-大数据从业者 - 博客园
深入分析Tomcat无响应问题及解决方法 - 月下狼的个人页面 - OSCHINA
jedis:连接池(JedisPool)使用示例 - 10km的专栏 - CSDN博客
Jedis使用|returnBrokenResource|returnResource废弃替代 - 诗人不写诗 - CSDN博客
本文搬自 我的博客 ，欢迎参观！
Jedis使用总结前段时间细节的了解了Jedis的使用，Jedis是redis的java版本的客户端实现。
本文做个总结，主要分享如下内容：
【pipeline】【分布式的id生成器】【分布式锁【watch】【multi】】【redis分布式】
好了，一个一个来。
一、 Pipeline
官方的说明是：starts a pipeline,which is a very efficient way to send lots of command and read all the responses when you finish sending them。简单点说pipeline适用于批处理。当有大量的操作需要一次性执行的时候，可以用管道。
示例：
Jedis jedis = new Jedis(String, int)
Pipeline p = jedis.pipelined()
p.set(key,value)//每个操作都发送请求给redis-server
p.get(key,value)
p.sync()//这段代码获取所有的response
这里我进行了20w次连续操作（10w读，10w写），不用pipeline耗时：187242ms，用pipeline耗时：1188ms，可见使用管道后的性能上了一个台阶。看了代码了解到，管道通过一次性写入请求，然后一次性读取响应。也就是说jedis是：request response，request response，...；pipeline则是：request request... response response的方式。这样无需每次请求都等待server端的响应。
二、 跨jvm的id生成器
使用方法代码样例如下，使用前，注意打开redis的server程序。代码样例packageRedisExampleimportredis.clients.jedis.JedispublicclassTestRedis{publicstaticvoidmain(String[]args){Jedisredis=newJedis("localhost")//SimpleExample(redis)//ListExample(redis,20000)PublishExample(redis,20000)}//简单添加信息publicstaticvoidSimpleExample(Jedisredis){redis.set("key1","Iamvalue1")Stringss=redis.get("key1")System.out.println(ss)}//队列添加信息publicstaticvoidListExample(Jedisredis,intnumber){StringmessageStr=""intcount=0while(count++
