这个是今天发现一个bug：在测试redis并发读写的时候（jedis作为客户端，并使用了连接池），总是报用完jedis无法返回jedisPool

Caused by: redis.clients.jedis.exceptions.JedisException: Could not return the resource to the pool
    at redis.clients.util.Pool.returnResourceObject(Pool.java:69)
    at redis.clients.jedis.JedisPool.returnResource(JedisPool.java:253)
    ... 14 more
Caused by: java.lang.IllegalStateException: Object has already been returned to this pool or is invalid
    at org.apache.commons.pool2.impl.GenericObjectPool.returnObject(GenericObjectPool.java:538)
    at redis.clients.util.Pool.returnResourceObject(Pool.java:67)
    ... 15 more

或者

Exception in thread "Thread-71" java.lang.ClassCastException: java.lang.Long cannot be cast to [B
    at redis.clients.jedis.Connection.getBinaryBulkReply(Connection.java:259)
    at redis.clients.jedis.Connection.getBulkReply(Connection.java:248)
    at redis.clients.jedis.Jedis.lpop(Jedis.java:1055)
    at us.codecraft.webmagic.scheduler.RedisScheduler.poll(RedisScheduler.java:77)
    at us.codecraft.webmagic.Spider.run(Spider.java:308)
    at java.lang.Thread.run(Thread.java:748)

类似的错误，就是返回值类型和文档上的返回值类型不相符，感觉很不应该；开始怀疑是jedis实现的一个bug，后来发现一个现象，当抛一个超时异常的时候，后面就连续的出现一个类似上面的错误，最后终于发现了问题所在。
原先的代码是这样的：

 public void releaseResource() {
        if (this.jedis != null) {
            jedisPool.returnResource(jedis);
        }
    }

发现returnResource被标记为废弃，查看jedis源代码发现了close()方法

    public void close() {
        if (this.dataSource != null) {
            if (this.client.isBroken()) {
                this.dataSource.returnBrokenResource(this);
            } else {
                this.dataSource.returnResource(this);
            }
        } else {
            this.client.close();
        }

    }

这个问题已经有前辈遇到过了，其解释：

查看 Jedis 源码发现它的Connection中对网络输出流做了一个封装（RedisInputStream），其中自建了一个buffer。当发生异常的时候，这个buffer里还残存着上次没有发送或者发送不完整的命令。这个时候没有做处理，直接将该连接返回到连接池，那么重用该连接执行下次命令的时候，就会将上次没有发送的命令一起发送过去，所以才会出现上面的错误“返回值类型不对”。

所以，正确的写法应该是：在发送异常的时候，销毁这个连接，不能再重用！
于是修改代码为

    public void releaseResource() {
        if (this.jedis != null) {
            try {
                jedis.close();
            } catch (Exception e) {
                log.error("释放jedis资源出错，将要关闭jedis，异常信息：" + e.getMessage());
                if (jedis != null) {
                    try {
                        // 2. 客户端主动关闭连接
                        jedis.disconnect();
                    } catch (Exception e1) {
                        log.error("disconnect jedis connection fail: " , e);
                    }finally {
                    }
                }
            }
        }
    }

这样经过测试解决了jedis用完无法返回jedisPool的问题。但是java.lang.ClassCastException: java.util.ArrayList cannot be cast to java.lang.Long 类型转换的错误依然存在。
于是把多线程的测试环境改为单线程，单个线程调用jedis不再出现问题。但是违背了初衷。把使用jedis的对象加锁，同时只有一个对象使用同一个jedis，如果因为

 Jedis “Socket读取超时”导致“返回值类型错误”

还是可能出现这个问题（不过几率较小了），调用releaseReource方法销毁jedis对象，重新从jedisPool获得一个，不要用之前的jedis对象，问题解决

参考：

http://bert82503.iteye.com/blog/2184225
https://github.com/xetorthio/jedis/issues/186