Spring cache + redis 项目偶发死锁异常浅析

本文分析了在使用Spring Cache和Redis时遇到的偶发死锁异常问题,详细描述了当存在未删除的~lock key时,如何导致线程卡死并引发系统错误。问题源于execute()方法中存在潜在的死循环,当加锁的key未被正确删除时,Exists命令会不断执行。解决方案是手动删除未解锁的~lock后缀key。
摘要由CSDN通过智能技术生成

问题描述:

在使用@Cacheable注解配置value名称之后,在读取或写入该value下任意key对应的值时,当前线程卡死直到超时。伴随着卡死线程的不断增加系统会抛出RedisConnectionFailureException。

org.springframework.data.redis.RedisConnectionFailureException | Cannot get Jedis connection; nested exception is redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
看似这个问题是redis连接池满了导致的,也有很多文章提到使用Spring data redis时,使用事务的连接会出现连接不释放的问题。 

然而还有另一种情况也会导致上述情况的发生,即这个value名称对应的所有key都被锁死了,听起来很扯淡但是事情就是这个样子。


问题分析:

使用redis客户端登录打出monitor命令后,发现一连串的Exists命令在不断刷新

1502245422.108774 [0 10.10.197.15:33919] "EXISTS" "group_info_cache~lock"
我们的请求由于某种原因导致服务不间断的像redis服务器确认"group_info_cache~lock"这个key是否存在。那么这个~lock后缀的key是干啥用的呢。其实是spring cache默认作为锁存在的key,~lock前面的是我们在@Cacheable注解中配置的value名
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值