1. 为何要使用分布式锁
在分布式系统中，多个服务实例可能同时访问共享资源，传统的本地锁失效。分布式锁应运而生，解决以下关键问题：
- 并发资源访问控制
- 防止数据不一致
- 避免重复操作
- 保证业务原子性
典型场景：
- 订单生成
- 库存扣减
- 秒杀系统
- 分布式任务调度
2. 分布式锁的几种实现方式
2.1 数据库实现
-- 悲观锁
SELECT * FROM table WHERE id = ? FOR UPDATE
优点：简单直接
缺点：性能低，数据库压力大
2.2 ZooKeeper实现
// 创建临时顺序节点
create -e -s /lock path
优点：可靠性高
缺点：依赖ZooKeeper集群
2.3 Redis实现
--加锁
SET key value NX PX 30000
优点：性能高
缺点：需要自己实现续期机制
3. 为什么总选择Redis？
- 性能优势
- 内存操作，毫秒级响应
- 原子操作命令
- 支持集群和高可用
- 实现简单
4. Redisson的优越性
既然是redis,那么开箱即用，便是大家所需，redission应运而生
- 功能全面
- 自动续期
- 可重入锁
- 公平锁
代码示例
RLock lock = redissonClient.getLock("myLock");
lock.lock();
try {
// 业务逻辑
} finally {
lock.unlock();
}
5. Redisson看门狗失效及解决
redission虽然有看门狗续命机制，但也不能做到万无一失
5.1 失效场景
有垃圾收集器（ GC ），有时运行期间会暂停所有正在运行的线程。这些GC暂停甚至有时会持续数分钟 ！即使像HotSpot JVM CMS所谓的“并发”垃圾收集器也不能完全与应用代码并行运行，需要时时地停止活动的线程。通过改变分配模式或调整GC某些参数可 减少暂停，但是我们还是要防范最差情况以提供可靠的保证。
当操作系统执行线程上下文切换时，或者虚拟机管理程序切换到 个虚机时
正在运行的线程可能会在代码的任意位置被暂停。在虚拟机环境中，这种被其
虚拟机中断的 PU时间称为窃取时间 。如果机器负载很高（ 等待运行的钱程很
长），被暂停的线程可能需要 段时间之后才能再次运行。如果操作系统配置了基于磁盘的内存交换分区，内存访问可能触发缺页中断，进
而需要从磁盘中加载内存页。 I/O 进行时（通常比较慢）线程为暂停。如果内存
使用压力很大，还可能迫使更多的页面换出到磁盘 极端的情况下，操作系统可
会花费大量时间在页面换入换出上，而实际工作完成很少（所谓的颠簸’）。为
了避免 问题，通常在服务器上禁用分页，宁愿杀死一些进程来释放内 而不
是反复抖动。
总之，当节点1拿到锁在执行时，如果看门狗未来的及续命，被暂停了，而redis锁过期了，节点2就有可能拿到锁，然后节点1复活继续执行，就会造成并发问题
5.2解决方案
5.2.1 显式设置超时
// 增加锁的超时时间
RLock lock = redissonClient.getLock("your_lock");
lock.lock(60, TimeUnit.SECONDS); // 显式设置较长超时
5.2.2 业务幂等设计
- 唯一请求ID
- 状态机
- 补偿机制
5.2.3 JVM参数调优
调整JVM GC策略
优化Full GC频率和时间
使用G1或ZGC替代
增加锁的容错机制
# 调整内存大小
-Xms4g -Xmx4g # 初始和最大堆内存一致
-XX:MaxMetaspaceSize=256m # 限制元空间大小
# 垃圾回收器选择
-XX:+UseG1GC # 推荐G1收集器
-XX:MaxGCPauseMillis=200 # 控制最大GC停顿时间
# 减少Full GC频率
-XX:+DisableExplicitGC # 禁止显式调用System.gc()
结语
分布式锁是分布式系统中的利器，选择合适的方案和框架至关重要。Redisson提供了强大且易用的分布式锁解决方案，但仍需谨慎设计和使用。
