情景复现
当jedis的连接池不够，或者网络抖动请求redis超时，出现JedisConnectionException，会导致NullPointerException、ClassCastException等一些灵异异常
示例代码：
ShardedJedisPool jedisPool = JedisUtils.getJedisPool();
ShardedJedis shardedJedis = jedisPool.getResource();
shardedJedis.setex("key",60,"value");
System.out.println(shardedJedis.get("key"));
System.out.println("Make SocketTimeoutException. cmd: sudo iptables -A INPUT -p tcp --dport 6379 -j DROP ");
System.in.read();
try{
System.out.println(shardedJedis.get("hi"));
}catch(JedisConnectionException e){
e.printStackTrace();
}
System.out.println("Recover from SocketTimeoutException. cmd: sudo iptables -F ");
System.in.read();
System.out.println(shardedJedis.get("key"));
System.out.println(shardedJedis.get("key"));
System.out.println(shardedJedis.get("hi"));
最后的返回值分别为：null,value,value
创建一个Socket套接字实例，操作系统就会为其分配缓冲区以存放接收和要发送的数据。JAVA可以设置读写缓冲区的大小，Socket类setReceiveBufferSize(int size)、setSendBufferSize(int size)
向输出流写数据并不意味着数据实际上已经被发送，它们只是被复制到发送缓冲区队列SendQ，就是在Socket的OutputStream上调用flush()方法，也不能保证数据能够立即发送到网络。真正的数据发送是由操作系统的TCP协议栈模块从缓冲区中取数据发送到网络来完成的
当有数据从网络来到时，TCP协议栈模块接收数据并放入接收缓冲区队列RecvQ，输入流InputStream通过read方法从RecvQ中取出数据
jedis与redis-server的通信主要是通过对RedisInputStream和RedisOutputStream的读写操作来完成
jedis调用Protocol类的sendCommand方法，发送命令字节流到RedisOutputStream。获取数据时，调用Connection类的getBinaryBulkReply方法，先进行flush，将RedisOutputStream里的命令复制到环形缓冲区SendQ等待发送，之后RedisInputStream复制环形缓冲区RecvQ数据，解析字节流获取redis数据
当jedis连接超时，flush方法会继续write命令到缓冲区，直到SendQ队列填满。SendQ保留了断线超时时间段的所有命令。当连接恢复后，SendQ发送命令请求数据，RedisInputStream获取到之前所有超时的命令数据，并将超时的错误数据返回给当前jedis调用
比如共发送6条命令，前1、2条命令超时，当第3条命令时恢复连接，则3获取到1的数据，4获取到2的数据，5获取到3的数据，6获取到4的数据。超时导致数据窜位，获取到脏数据
当出现JedisConnectionException，为了避免RedisInputStream缓冲区的脏数据，不应该使用broken的连接，而是需要return回连接池，然后remove掉broken连接
try{
System.out.println(shardedJedis.get("hi"));
}catch(JedisConnectionException e){
e.printStackTrace();
}finally{
shardedJedis.close();
}
只要最后finally里close即可，官方支持的，妈妈再也不用担心我的学习。close方法有个broken的标志位，会循环去回收异常的connection。
总结：异常时returnBrokenResource，正常时returnResource即可。两者只能执行一个！
为什么returnBrokenResource就能解决上面的问题呢？
原因：1.returnBrokenResource把jedispoll里面是当前异常连接remove掉了
2.returnBrokenResource 把等待队列的异常连接remove掉了。
3.returnBrokenResource 会把之前的socket连接关闭。即客户端发起关闭FIN请求。开始执行socket断开四次握手。（为了关闭客户端socket，和服务器端socket端断开，减少服务端资源开销。）
4.如果网络是持续断开，那么这个FIN到不了服务端，则服务端的socket将继续打开。（TCP连接称为半打开）。
若连接池配置了testOnBorrow=true，每次取jedis时，都会测试jedis.isConnected和ping一下服务端，但这样会造成redis的压力，testOnBorrow和testOnReturn在生产环境一般是不开启的，主要是性能考虑。失效连接主要通过testWhileIdle保证，如果获取到了不可用的数据库连接，一般由应用处理异常
参考配置：
jedis对connection的test源码：
jedis.isConnected() && jedis.ping().equals("PONG")
作者：GreenMountains
链接：http://www.jianshu.com/p/610415223f1d
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。