從異常信息來看，首先是在'zadd'操作時出現"Socket讀取超時異常"，具體異常信息"JedisConnectionException: java.net.SocketTimeoutException: Read timed out"。
出現異常後，會銷燬這個阻塞的Jedis連接池對象（CustomShardedJedisPool.returnBrokenResource(CustomShardedJedisPool.java:121)），但在請求Redis服務端關閉連接時，出現"強制類型轉換異常"，具體異常信息"ClassCastException: java.lang.Long cannot be cast to [B"。
這個問題已經有前輩遇到過了，其解釋：
查看 Jedis 源碼發現它的Connection中對網絡輸出流做了一個封裝（RedisInputStream），其中自建了一個buffer。當發生異常的時候，這個buffer裏還殘存着上次沒有發送或者發送不完整的命令。這個時候沒有做處理，直接將該連接返回到連接池，那麼重用該連接執行下次命令的時候，就會將上次沒有發送的命令一起發送過去，所以纔會出現上面的錯誤“返回值類型不對”。
所以，正確的寫法應該是：在發送異常的時候，銷燬這個連接，不能再重用！
參考自：
從異常信息來看，首先是在'zadd'操作時出現"Socket讀取超時異常"，具體異常信息"JedisConnectionException: java.net.SocketTimeoutException: Read timed out"。
出現異常後，會銷燬這個阻塞的Jedis連接池對象（CustomShardedJedisPool.returnBrokenResource(CustomShardedJedisPool.java:121)），但在請求Redis服務端關閉連接時，出現"強制類型轉換異常"，具體異常信息"ClassCastException: java.lang.Long cannot be cast to [B"。
這個問題已經有前輩遇到過了，其解釋：
查看 Jedis 源碼發現它的Connection中對網絡輸出流做了一個封裝（RedisInputStream），其中自建了一個buffer。當發生異常的時候，這個buffer裏還殘存着上次沒有發送或者發送不完整的命令。這個時候沒有做處理，直接將該連接返回到連接池，那麼重用該連接執行下次命令的時候，就會將上次沒有發送的命令一起發送過去，所以纔會出現上面的錯誤“返回值類型不對”。
所以，正確的寫法應該是：在發送異常的時候，銷燬這個連接，不能再重用！
參考自：
