1.使用
// 设置锁定资源名称
RLock disLock = redissonClient.getLock("DISLOCK");
//尝试获取分布式锁
boolean isLock= disLock.tryLock(500, 15000, TimeUnit.MILLISECONDS);
if (isLock) {try {//TODO if get lock success, do something;Thread.sleep(15000);} catch (Exception e) {} finally {// 无论如何, 最后都要解锁disLock.unlock();}
}
2.原理
对应redis的hash结构的key就是UUID+threadId,hash结构的value就是重入值
-
Redisson 的 RLock 是如何实现分布式锁的?
考察点:对 Redisson 实现机制的理解。
回答要点:
基于 Redis 的 SET key value NX PX 命令实现加锁。
使用 Lua 脚本保证加锁和解锁的原子性。
支持可重入,通过 Redis 的 Hash 结构记录持有锁的线程和重入次数。
内部使用 WatchDog 机制自动续期锁,防止锁因为超时被提前释放。 -
RLock 的 WatchDog 机制是什么?如何工作的?
考察点:对锁自动续期机制的理解。
回答要点:
WatchDog 是 Redisson 内部的一个定时任务。
当加锁时未指定 leaseTime,WatchDog 会定期(默认每 1/3 leaseTime)检查锁是否仍被当前线程持有,若持有则自动延长锁的过期时间。
该机制防止业务执行时间超过锁超时时间而导致锁被提前释放。 -
如果设置了 leaseTime,WatchDog 还会生效吗?
考察点:对 leaseTime 和 WatchDog 之间关系的理解。
回答要点:
如果加锁时显式设置了 leaseTime,则 WatchDog 不会生效。
锁将在 leaseTime 时间后自动释放,不管业务是否执行完毕。
适用于需要强制控制锁超时时间的场景,防止死锁。 -
RLock 是可重入的吗?如何实现可重入性?
考察点:对可重入锁实现机制的理解。
回答要点:
是可重入的。
Redisson 使用 Redis 的 Hash 数据结构存储锁信息:
key:锁名
field:线程标识(如 UUID:threadId)
value:重入次数
每次重入时,重入次数 +1,释放锁时次数 -1,直到为 0 才真正释放锁。 -
Redisson 的 RLock 是公平锁吗?
考察点:对锁公平性机制的理解。
回答要点:
默认是非公平锁。
Redisson 提供了公平锁的实现:RedissonFairLock。
公平锁通过 Redis 队列维护请求顺序,按 FIFO 原则获取锁。 -
主从架构下,Redisson 的 RLock 是否存在一致性问题?
考察点:对 Redis 主从同步机制和分布式锁一致性的理解。
回答要点:
存在主从同步延迟导致的锁丢失风险。
例如主节点加锁后宕机,锁未同步到从节点,从节点提升为主节点后锁丢失。
解决方案:
使用 Redlock 算法(Redisson 提供 RedissonRedLock)。
或使用 Redis 集群模式 + 多数派机制来提高一致性。 -
Redisson 的 RLock 在集群模式下如何工作?
考察点:对 Redis 集群环境下分布式锁实现的理解。
回答要点:
在集群模式下,锁操作会路由到对应的 slot 上。
Redisson 保证锁操作的原子性,即使在集群环境下也能正常工作。
可通过 RedissonRedLock 在多个独立 Redis 实例上实现更可靠的分布式锁。 -
如何防止 Redisson 锁的死锁问题?
考察点:对死锁预防机制的理解。
解决措施:
设置合理的 leaseTime,避免锁持有时间过长。
使用 tryLock 带超时机制,避免无限等待。
合理使用 WatchDog 机制自动续期,但要确保业务能正常结束。
保证加锁和解锁在同一线程中,避免跨线程操作。 -
Redisson 锁的性能如何?有没有优化建议?
考察点:对性能优化和锁使用最佳实践的理解。
优化建议:
尽量减少锁的持有时间。
避免在锁内执行耗时操作。
根据业务需求选择公平锁或非公平锁。
在高并发场景下,考虑分段锁或使用 Redlock 提高可靠性。 -
Redisson 的 RLock 与 Zookeeper 实现的分布式锁相比,有什么优劣?
考察点:对不同分布式锁实现机制的比较能力。
比较要点: | 特性 | Redisson RLock | Zookeeper | |------|----------------|-----------| | 性能 | 高(基于内存) | 一般(基于 ZAB 协议) | | 实现复杂度 | 简单 | 复杂 | | 一致性 | 依赖主从同步 | 强一致性(ZAB) | | 容错性 | 依赖 Redlock 等机制 | 本身具备强一致性 | | 适用场景 | 高并发、低一致性要求 | 强一致性要求 |