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 等机制 | 本身具备强一致性 | | 适用场景 | 高并发、低一致性要求 | 强一致性要求 |