在线上环境发现了一个工作线程异常终止，看日志先是一些sockettimeoutexception，然后突然有一个classcastexception
redis.clients.jedis.exceptions.jedisconnectionexception: java.net.sockettimeoutexception: read timed out ... java.lang.classcastexception: [b cannot be cast to java.lang.long at redis.clients.jedis.connection.getintegerreply(connection.java:208) at redis.clients.jedis.jedis.sismember(jedis.java:1307)
经过在本地人工模拟网络异常的情境，最终复现了线上的这一异常。又经过深入分析（提出假设–>验证假设），最终找出了导致这一问题的原因。见如下示例代码：
jedispool pool = ...; jedis jedis = pool.getresource(); string value = jedis.get("foo"); system.out.println("make sockettimeoutexception"); system.in.read(); //等待制造sockettimeoutexception try { value = jedis.get("foo"); system.out.println(value); } catch (jedisconnectionexception e) { e.printstacktrace(); } system.out.println("recover from sockettimeoutexception"); system.in.read(); //等待恢复 thread.sleep(5000); // 继续休眠一段时间 等待网络完全恢复 boolean ismember = jedis.sismember("urls", "baidu.com");
以及日志输出：
bar make sockettimeoutexception redis.clients.jedis.exceptions.jedisconnectionexception: java.net.sockettimeoutexception: read timed out recover from sockettimeoutexception at redis.clients.util.redisinputstream.ensurefill(redisinputstream.java:210) at redis.clients.util.redisinputstream.readbyte(redisinputstream.java:47) at redis.clients.jedis.protocol.process(protocol.java:131) at redis.clients.jedis.protocol.read(protocol.java:196) at redis.clients.jedis.connection.readprotocolwithcheckingbroken(connection.java:283) at redis.clients.jedis.connection.getbinarybulkreply(connection.java:202) at redis.clients.jedis.connection.getbulkreply(connection.java:191) at redis.clients.jedis.jedis.get(jedis.java:101) at com.tcl.recipevideohunter.jedistest.main(jedistest.java:23) caused by: java.net.sockettimeoutexception: read timed out at java.net.socketinputstream.socketread0(native method) at java.net.socketinputstream.read(socketinputstream.java:152) at java.net.socketinputstream.read(socketinputstream.java:122) at java.net.socketinputstream.read(socketinputstream.java:108) at redis.clients.util.redisinputstream.ensurefill(redisinputstream.java:204) ... 8 more exception in thread "main" java.lang.classcastexception: [b cannot be cast to java.lang.long at redis.clients.jedis.connection.getintegerreply(connection.java:208) at redis.clients.jedis.jedis.sismember(jedis.java:1307) at com.tcl.recipevideohunter.jedistest.main(jedistest.java:32)
分析：
等执行第二遍的get("foo")时，网络超时，并未实际发送 get foo 命令，等执行sismember时，网络已恢复正常，并且是同一个jedis实例，于是将之前的get foo命令（已在输出流缓存中）一并发送。
执行顺序如下所示：
127.0.0.1:9379> get foo"bar"127.0.0.1:9379> sismember urls baidu.com(integer) 1127.0.0.1:9379> get foo "bar" 127.0.0.1:9379> sismember urls baidu.com (integer) 1
故在上述示例代码中最后的sismember得到的结果是get foo的结果，即一个字符串，而sismember需要的是一个long型，故导致了classcastexception。
为什么线上会出现这一问题呢？原因是其执行redis的逻辑类似这样：
while(true){ jedis jedis = null; try { jedis = pool.getresource(); //some redis operation here. } catch (exception e) { logger.error(e); } finally { pool.returnresource(jedis); } }
因若是网络异常的话，pool.returnresource(jedis)仍能成功执行，即能将其返回到池中（这时jedis并不为空）。等网络恢复后，并是多线程环境，导致后续其他某个线程获得了同一个jedis实例（pool.getresource()），
若该线程中的jedis操作返回类型与该jedis实例在网络异常期间第一条未执行成功的jedis操作的返回类型不匹配（如一个是get，一个是sismember），则就会出现classcastexception异常。
这还算幸运的，若返回的是同一类型的话（如lpop("queue_order_pay_failed"),lpop("queue_order_pay_success")）,那我真不敢想象。
如在上述示例代码中的sismember前插入一get("nonexist-key")(redis中不存在该key,即应该返回空).
value = jedis.get("nonexist-key"); system.out.println(value); boolean ismember = jedis.sismember("urls", "baidu.com"); system.out.println(ismember);
实际的日志输出为:
bar exception in thread "main" java.lang.nullpointerexception at redis.clients.jedis.jedis.sismember(jedis.java:1307) at com.tcl.recipevideohunter.jedistest.main(jedistest.java:37)
分析:
get("nonexist-key")得到是之前的get("foo")的结果, 而sismember得到的是get("nonexist-key")的结果,而get("nonexist-key")返回为空,于是这时是报空指针异常了.
解决方法：不能不管什么情况都一律使用returnresource。更健壮可靠以及优雅的处理方式如下所示：
while(true){ jedis jedis = null; boolean broken = false; try { jedis = jedispool.getresource(); return jedisaction.action(jedis); //模板方法 } catch (jedisexception e) { broken = handlejedisexception(e); throw e; } finally { closeresource(jedis, broken); } } /** * handle jedisexception, write log and return whether the connection is broken. */ protected boolean handlejedisexception(jedisexception jedisexception) { if (jedisexception instanceof jedisconnectionexception) { logger.error("redis connection " + jedispool.getaddress() + " lost.", jedisexception); } else if (jedisexception instanceof jedisdataexception) { if ((jedisexception.getmessage() != null) && (jedisexception.getmessage().indexof("readonly") != -1)) { logger.error("redis connection " + jedispool.getaddress() + " are read-only slave.", jedisexception); } else { // dataexception, isbroken=false return false; } } else { logger.error("jedis exception happen.", jedisexception); } return true; } /** * return jedis connection to the pool, call different return methods depends on the conectionbroken status. */ protected void closeresource(jedis jedis, boolean conectionbroken) { try { if (conectionbroken) { jedispool.returnbrokenresource(jedis); } else { jedispool.returnresource(jedis); } } catch (exception e) { logger.error("return back jedis failed, will fore close the jedis.", e); jedisutils.destroyjedis(jedis); } }
补充：
ubuntu本地模拟访问redis网络超时：
sudo iptables -a input -p tcp –dport 6379 -j drop
恢复网络：
sudo iptables -f
补充：
若jedis操作逻辑类似下面所示的话，
jedis jedis = null; try { jedis = jedissentinelpool.getresource(); return jedis.get(key); }catch(jedisconnectionexception e) { jedissentinelpool.returnbrokenresource(jedis); logger.error("", e); throw e; }catch (exception e) { logger.error("", e); throw e; } finally { jedissentinelpool.returnresource(jedis); }
若一旦发生了jedisconnectionexception，如网络异常，会先执行returnbrokenresource，这时jedis已被destroy了。然后进入了finally，再一次执行returnresource，这时会报错：
redis.clients.jedis.exceptions.jedisexception: could not return the resource to the pool at redis.clients.util.pool.returnresourceobject(pool.java:65) at redis.clients.jedis.jedissentinelpool.returnresource(jedissentinelpool.java:221)
临时解决方法：
jedissentinelpool.returnbrokenresource(jedis); jedis=null; //这时不会实际执行returnresource中的相关动作了
但不建议这样处理，更严谨的释放资源方法见前文所述。
以上就是使用jedis线程池returnresource异常注意事项的详细内容，更多关于jedis线程池returnresource异常的资料请关注<计算机技术网(www.ctvol.com)!!>其它相关文章！
需要了解更多c/c++开发分享使用Jedis线程池returnResource异常注意事项，都可以关注C/C++技术分享栏目—计算机技术网(www.ctvol.com)!
本文来自网络收集，不代表计算机技术网立场，如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址：https://www.ctvol.com/c-cdevelopment/1074250.html