jedisPool使用遇到的bug

这个是今天发现一个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

你可能感兴趣的:(jedisPool使用遇到的bug)