Redis Lettuce-core 共享锁死锁问题分析与解决方案

问题背景

在分布式系统开发中，Redis作为高性能的内存数据库被广泛使用，而Lettuce作为Redis的Java客户端库，因其响应式编程支持而受到开发者青睐。然而，在使用Lettuce-core 6.1.9版本时，开发者发现了一个潜在的共享锁死锁问题，该问题会在Redis服务异常时触发，导致整个应用服务不可用。

问题现象

当系统同时满足以下条件时，会出现线程死锁：

1. Redis服务正常运行
2. 应用服务启动并处理正常流量
3. Redis服务突然停止
4. Redis端口被其他进程占用(模拟Redis IP和端口可访问但服务不可用)
5. Lettuce尝试自动重连Redis

此时，所有进入点的线程都会被阻塞，即使停止压力测试，HTTP服务也无法恢复正常。通过线程堆栈分析(jstack)可以确认发生了死锁。

技术分析

从线程堆栈信息可以看出，死锁发生在共享锁(SharedLock)的实现中。具体表现为：

1. 一个线程持有lockWritersExclusive锁，同时等待获取incrementWriters锁
2. 另一个线程持有incrementWriters锁，同时等待获取lockWritersExclusive锁

这种典型的双锁互持情况导致了死锁的发生。问题根源在于Lettuce在错误恢复路径上的锁获取顺序不一致。

问题复现步骤

1. 启动Redis服务
2. 启动应用服务
3. 使用ab工具模拟并发请求(如：ab -c 3 -n 100000)
4. 停止Redis服务
5. 启动其他进程占用Redis端口(模拟端口可访问但服务不可用)
6. 等待30秒让Lettuce尝试自动重连
7. 观察服务状态和线程情况

影响范围

该问题影响所有使用Lettuce-core 6.1.9版本且采用响应式编程模式的应用，特别是在Redis服务不稳定或网络环境复杂的生产环境中更容易触发。

解决方案

Lettuce开发团队已经意识到该问题的严重性，并计划在后续版本中修复。可能的解决方案包括：

1. 统一锁获取顺序，确保所有代码路径都按照相同的顺序获取锁
2. 引入锁超时机制，避免无限期等待
3. 重构共享锁实现，减少锁粒度或使用无锁编程技术

临时规避措施

对于无法立即升级的生产环境，可以考虑以下临时方案：

1. 监控Redis连接状态，在检测到异常时主动重启应用
2. 配置更短的连接超时时间，快速失败而非长时间等待
3. 在onErrorResume块中避免执行可能导致锁竞争的Redis操作

总结

Redis Lettuce-core的共享锁死锁问题是一个典型的并发编程陷阱，提醒我们在分布式系统开发中需要特别注意错误处理路径上的资源竞争问题。开发者应当关注Lettuce的后续版本更新，及时升级以获得修复。同时，在编写响应式代码时，应当谨慎处理错误恢复逻辑，避免在错误处理路径中引入新的竞争条件。