简介这份源码解析资源面向Java后端开发者与分布式系统学习者聚焦大厂生产环境下Redis高并发分布式锁的实战落地帮助读者理解锁的获取、续租、释放及异常处理等核心机制解决高并发场景下操作互斥与数据一致性问题。资源包共39个文件约148KB以14个java源码与8个class文件为主体辅以xml、yml、properties等配置文件和gitignore规则文件并包含jar依赖与说明文档目录按redis-jedis、redis-lock、redis-boot-sentinel-cluster等模块组织便于对照学习。目前已有361人学习下载。通过研读源码读者可掌握Jedis连接Redis、Spring Boot集成配置、避免死锁与活锁、保障锁性能与可靠性等实践要点适合希望深入分布式锁设计并提升生产级开发能力的技术人员。1. 从一次超卖事故说起这套 Java Redis 分布式锁源码到底值不值得拆电商大促凌晨两点库存扣减接口在 QPS 破万时出现超卖日志里decr返回负数数据库里同一件商品被卖了三次。事后复盘问题不在 Redis 性能而在锁的粒度、续租和释放逻辑全是拍脑袋写的。这套「基于 Java 的大厂生产级 Redis 高并发分布式锁实战源码」就是冲着这类场景来的——它不是教你setnx就完事的玩具而是把锁的获取、续租、释放、异常兜底拆成可运行的 Maven 多模块工程包含 8 个 Java 类、3 个 XML 配置、2 个 YAML 配置和 3 个属性文件覆盖 Jedis 直连与 Spring Boot 自动装配两条路线。适合已经写过synchronized但在分布式环境里翻过车的后端也适合准备面试「分布式锁使用场景」却答不出 Redlock 争议的 Java 工程师。下面按「资源结构 → 核心实现 → 配置落地 → 避坑 → 进阶验证」的顺序拆每一步都落到能抄的代码和参数上。2. 工程结构与依赖选型39 个文件里哪几个是真正要读的拿到upload.zip解压后目录里同时躺着redis-lock、redis-boot-sentinel-cluster两个子模块和一堆 Eclipse 元数据。很多人第一反应是全部导入 IDE结果被.settings和target里的 class 文件干扰。先搞清楚哪些是源码、哪些是构建产物再决定读的顺序能省掉至少半小时的无效翻找。2.1 模块划分与文件清单从目录树看工程是典型的 Maven 多模块结构根pom.xml做依赖管理两个子模块分别对应「原生 Jedis 实现」和「Spring Boot Sentinel 集群实现」。真正需要精读的 Java 类集中在src/main/java下target/classes里的是编译产物可以直接忽略。下面这张表把关键文件按职责归了类照着读不会迷路。路径类型作用是否精读redis-lock/src/main/javaJava 源码锁获取/续租/释放核心逻辑是redis-boot-sentinel-cluster/src/main/javaJava 源码Spring Boot 自动装配与集群配置是根pom.xmlXML统一版本与模块聚合是*.properties属性连接池、超时等运行参数是*.ymlYAMLSentinel 集群节点与锁行为是.settings/、.gitignore配置IDE 与版本控制否target/编译产物字节码否提示导入 IDE 前先执行一次mvn clean把target清掉否则索引会拖慢整个工程加载。2.2 为什么是 Jedis 而不是 Lettuce项目里同时出现了 Jedis 和 Spring Boot 的 starter但锁的核心操作走的是 Jedis。这不是随意选的。分布式锁对命令的原子性要求极高SET key value NX PX和 Lua 脚本的EVAL必须落在同一条连接、同一个节点上Jedis 的同步阻塞模型让「获取连接 → 执行 → 归还」这条链路非常直观出问题时堆栈也干净。Lettuce 基于 Netty 异步共享连接在集群重定向场景下排查成本更高新手很容易在redis command timed out里绕不出来。常见做法是锁这种强一致、低频但要求确定性的操作走 Jedis 直连普通缓存读写走 Lettuce 或 Spring Data Redis。项目把两者分开放在不同模块正是这个思路。依赖坐标大致如下版本以根pom.xml为准不要自己乱升。!-- 根 pom.xml 中的关键依赖版本号以工程实际为准 -- dependency groupIdredis.clients/groupId artifactIdjedis/artifactId !-- 锁操作依赖同步连接避免异步重定向带来的排查成本 -- /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId !-- 仅用于非锁场景的缓存读写 -- /dependency参数说明jedis负责锁的原子命令spring-boot-starter-data-redis负责常规缓存。两者共存时要注意连接池隔离别让缓存的大流量把锁的连接池占满——这是生产环境里最隐蔽的翻车点之一。2.3 导入与首次编译确认 JDK 和 Maven 版本后按下面步骤跑通第一次编译。这一步的目的是验证依赖能拉下来、模块能识别不涉及业务逻辑。# 1. 解压后进入根目录 unzip upload.zip -d redis-lock-demo cd redis-lock-demo # 2. 清理历史编译产物避免旧 class 干扰 mvn clean # 3. 跳过测试先编译确认依赖完整 mvn compile -DskipTests # 4. 查看模块是否被正确识别 mvn -q -Dexec.executableecho -Dexec.args${project.modules} exec:exec逻辑说明clean清掉targetcompile只编译主源码不跑测试能快速暴露依赖缺失。如果卡在下载依赖检查 Maven 镜像配置如果报模块找不到检查根pom.xml的modules是否包含两个子模块。首次编译通过后再进 IDE 读代码索引会快很多。3. 锁的获取、续租与释放8 个 Java 类里的核心链路这套源码最值钱的部分不是「怎么加锁」而是「锁在异常和超时下怎么不失控」。8 个 Java 类基本围绕三条链路展开加锁的原子性、持有期间的续租、释放时的归属校验。把这三条读透分布式锁的面试题和线上问题就都能接住。3.1 加锁SET NX PX 与唯一 value加锁的核心是一条命令SET lockKey uniqueValue NX PX expireTime。NX保证只有 key 不存在时才设置成功PX保证即使客户端崩溃锁也会自动过期。关键在于uniqueValue必须是每个请求唯一的通常是 UUID 加线程标识释放锁时用它来校验「这把锁是不是我加的」。// 加锁核心逻辑示意结构字段名以工程实际为准 public boolean tryLock(String lockKey, String requestId, int expireMillis) { // NXkey 不存在才设置PX毫秒级过期防止死锁 String result jedis.set(lockKey, requestId, NX, PX, expireMillis); // OK 表示抢锁成功null 表示已被占用 return OK.equals(result); }参数说明lockKey是业务维度的锁名建议带业务前缀如lock:order:123requestId必须全局唯一否则释放时会误删别人的锁expireMillis是锁的兜底过期时间设太短会导致业务没跑完锁就没了设太长会让故障恢复变慢。常见做法是按「业务 P99 耗时 × 3」来估再配合续租兜底。3.2 续租看门狗机制与过期时间博弈锁的过期时间和业务执行时间是一对天然矛盾设短了业务没跑完锁就释放设长了客户端崩溃后要等很久。生产级方案是加一个「看门狗」——后台定时任务在锁快过期时如果业务还在执行就把过期时间续上。续租同样要用 Lua 脚本保证「校验归属 续期」的原子性。// 续租只有 value 匹配还是自己的锁才延长过期时间 String renewScript if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(pexpire, KEYS[1], ARGV[2]) else return 0 end; // KEYS[1]锁名, ARGV[1]requestId, ARGV[2]新的过期毫秒 Long renewed (Long) jedis.eval(renewScript, Collections.singletonList(lockKey), Arrays.asList(requestId, String.valueOf(newExpireMillis)));逻辑说明脚本先get比对 value确认锁还属于当前请求再执行pexpire。两步放在一个 Lua 脚本里Redis 单线程执行保证不会被打断。参数上续租周期一般设为过期时间的三分之一比如锁 30 秒过期每 10 秒续一次。注意续租任务要能感知业务结束否则会一直续下去变成另一种形式的死锁。3.3 释放Lua 脚本保证归属校验释放锁最常见的错误是先get判断再del这两步之间锁可能刚好过期并被别人抢走导致删掉别人的锁。正确做法是把「比对 value」和「删除」写进同一个 Lua 脚本。// 释放value 匹配才删除避免误删他人锁 String unlockScript if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; Long released (Long) jedis.eval(unlockScript, Collections.singletonList(lockKey), Collections.singletonList(requestId));参数说明返回1表示成功释放0表示锁已不属于当前请求可能已过期或被续租失败。业务代码里不要忽略这个返回值它往往是排查「锁提前失效」的第一手线索。释放失败时不要重试删除而应该记录日志并检查续租任务是否正常。3.4 异常兜底finally 与连接归还锁的释放必须放在finally里且要处理 Jedis 连接异常。如果获取连接就失败了finally里再调del会抛二次异常掩盖原始错误。try { boolean locked tryLock(lockKey, requestId, 30000); if (!locked) { // 抢锁失败按业务决定重试还是快速失败 return; } // 执行业务逻辑 } finally { try { unlock(lockKey, requestId); } catch (Exception e) { // 释放失败只记录不抛出避免掩盖业务异常 log.warn(unlock failed, key{}, requestId{}, lockKey, requestId, e); } }逻辑说明finally保证无论业务是否抛异常都会尝试释放内层try-catch保证释放本身的异常不会覆盖业务异常。这是血泪经验——线上曾因为释放抛异常把真正的业务错误吞掉排查方向全跑偏。4. 配置落地properties 与 YAML 里的参数怎么调源码能跑起来不等于能在生产跑。3 个属性文件和 2 个 YAML 配置决定了连接池大小、超时、Sentinel 节点和锁行为这些参数调错锁的可靠性直接打折。这一章把关键配置项拆开讲给出估算方法和调整边界。4.1 连接池与超时参数属性文件里通常有maxTotal、maxIdle、minIdle、maxWaitMillis、timeout这几项。锁操作的连接数不需要很大但等待时间要短避免线程堆积。参数建议值说明maxTotal50100锁操作并发有限过大反而浪费maxIdle20保持一定空闲连接减少创建开销maxWaitMillis5001000抢不到连接快速失败别让线程干等timeout2000单次命令超时超过说明网络或节点异常注意锁的连接池要和缓存的连接池分开配置。共用一个大池子时缓存的大 key 扫描或批量操作会把连接占满锁请求排队超时表现为「偶发抢不到锁」极难排查。4.2 Sentinel 集群配置redis-boot-sentinel-cluster模块的 YAML 里配置了 Sentinel 节点列表、master 名称和密码。集群模式下锁的 key 必须落在同一个 master 上否则主从切换时锁状态会不一致。# Sentinel 集群配置示意字段以工程实际为准 spring: redis: sentinel: master: mymaster # 与 Sentinel 配置的 master 名一致 nodes: # 至少配两个 Sentinel 节点 - 127.0.0.1:26379 - 127.0.0.1:26380 password: your_password # 有密码时必须配否则连接被拒 timeout: 2000参数说明master必须和 Sentinel 端sentinel monitor配置的名字完全一致大小写敏感nodes至少两个单节点 Sentinel 本身就是单点password在启用认证时必填。主从切换期间锁可能短暂不可用业务侧要有降级或重试策略不能假设锁永远可用。4.3 锁行为参数与业务对齐锁的过期时间、续租周期、重试次数这些参数最好从配置文件读而不是硬编码在 Java 里。这样不同业务可以配不同的锁策略不用改代码重新打包。# 锁行为参数按业务维度覆盖 lock.order.expireMillis30000 # 订单锁 30 秒过期 lock.order.renewInterval10000 # 每 10 秒续租一次 lock.order.retryTimes3 # 抢锁失败重试 3 次 lock.order.retryInterval200 # 重试间隔 200 毫秒逻辑说明expireMillis要大于业务 P99 耗时renewInterval取过期时间的三分之一左右retryTimes和retryInterval决定抢锁失败时的行为。重试次数不宜过多否则高并发下会放大 Redis 压力形成「越抢越慢」的负反馈。常见做法是重试 23 次后快速失败让上层决定是否降级。5. 避坑与排查分布式锁最常见的 5 个翻车现场锁的代码看起来简单线上问题却五花八门。这一章按「现象 → 原因 → 解决」整理 5 条真实踩坑记录都是这套源码涉及场景里高频出现的。5.1 锁提前失效导致并发进入现象业务日志显示两个线程同时进入临界区库存被扣了两次。原因锁的过期时间设得比业务执行时间短业务还没跑完锁就自动过期第二个线程趁虚而入。解决把过期时间设为业务 P99 耗时的 3 倍以上同时开启续租续租任务要绑定业务生命周期业务结束立即停止续租。5.2 误删他人锁现象A 线程释放锁后B 线程发现自己刚加的锁没了。原因释放时只做了del没校验 valueA 的锁过期后 B 抢到A 的释放逻辑把 B 的锁删了。解决释放必须用 Lua 脚本比对requestId匹配才删。这套源码的释放逻辑正是这么写的照抄即可。5.3 主从切换丢锁现象master 宕机切换后同一把锁被两个客户端同时持有。原因锁写在 master 上还没同步到 slavemaster 就挂了slave 升主后没有这把锁。解决对一致性要求极高的场景考虑 Redlock 或基于共识的锁服务普通业务接受极小概率的锁失效但要保证业务侧幂等把损失控制在可接受范围。5.4 连接池耗尽导致抢锁超时现象高峰期大量请求报Could not get a resource from the pool。原因锁和缓存共用连接池缓存的大批量操作占满连接。解决锁用独立连接池maxWaitMillis设短抢不到连接快速失败监控连接池活跃数和等待队列长度提前扩容。5.5 续租任务泄漏现象业务早已结束后台还在不停续租锁一直不释放。原因续租任务没有在业务结束时取消线程池里的定时任务持续运行。解决用try-finally保证业务结束时取消续租任务续租任务内部也要检查业务是否还存活避免孤儿任务。这是最隐蔽的坑往往在压测后才暴露。6. 进阶验证用压测和日志确认锁真的可靠代码读完、配置调完最后一步是验证。分布式锁的可靠性不能靠「看起来对」要用并发压测和日志把边界逼出来。我一般会做两件事一是用多线程模拟抢锁看是否严格互斥二是打开 Redis 慢查询和锁操作日志观察续租和释放的时序。6.1 多线程互斥验证写一个最小验证程序起 50 个线程抢同一把锁每个线程在临界区里对共享计数器加一最后检查计数是否等于线程数。如果出现小于说明锁没兜住。// 互斥验证50 线程抢锁临界区自增最终应等于 50 int threads 50; AtomicInteger counter new AtomicInteger(0); CountDownLatch latch new CountDownLatch(threads); ExecutorService pool Executors.newFixedThreadPool(threads); for (int i 0; i threads; i) { pool.submit(() - { String requestId UUID.randomUUID().toString(); try { if (tryLock(lock:test, requestId, 30000)) { // 临界区模拟业务耗时 int v counter.get(); Thread.sleep(10); counter.set(v 1); } } catch (Exception e) { log.error(lock test error, e); } finally { unlock(lock:test, requestId); latch.countDown(); } }); } latch.await(); // 期望输出 50小于则说明互斥被破坏 System.out.println(counter counter.get());逻辑说明每个线程用独立requestId抢到锁才进临界区sleep模拟业务耗时最后校验计数。如果结果小于 50重点查过期时间是否太短、续租是否生效、释放是否误删。这个验证跑通基本能排除大部分逻辑错误。6.2 日志与监控要看什么光有结果不够还要看过程。锁操作建议打三类日志抢锁成功/失败、续租触发、释放结果。关键字段包括lockKey、requestId、耗时和返回值。Redis 侧打开慢查询日志阈值设 10 毫秒锁的 Lua 脚本正常应该在毫秒级完成超过说明网络或节点有压力。观察项正常表现异常信号抢锁耗时毫秒级持续超过 50ms查网络或连接池续租间隔稳定约过期时间 1/3忽长忽短查定时任务调度释放返回1频繁返回 0查锁是否提前过期慢查询无锁相关记录出现 EVAL 慢查询查脚本复杂度6.3 一个我坚持了很久的习惯压测环境里跑通不代表生产可靠网络抖动、主从切换、GC 停顿都会改变锁的行为。从那以后我每次上线锁相关改动都强制走一遍「多线程互斥验证 慢查询观察 续租日志核对」三个都过了才放行。这套源码的价值不在于它写得多完美而在于它把生产里真正会出问题的点都摆出来了照着拆一遍比自己从零踩坑快得多。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/4 7:42:03 · 阅读 1.2k Java Redis 分布式锁生产级源码实战：从超卖事故到高并发避坑
简介这份源码解析资源面向Java后端开发者与分布式系统学习者聚焦大厂生产环境下Redis高并发分布式锁的实战落地帮助读者理解锁的获取、续租、释放及异常处理等核心机制解决高并发场景下操作互斥与数据一致性问题。资源包共39个文件约148KB以14个java源码与8个class文件为主体辅以xml、yml、properties等配置文件和gitignore规则文件并包含jar依赖与说明文档目录按redis-jedis、redis-lock、redis-boot-sentinel-cluster等模块组织便于对照学习。目前已有361人学习下载。通过研读源码读者可掌握Jedis连接Redis、Spring Boot集成配置、避免死锁与活锁、保障锁性能与可靠性等实践要点适合希望深入分布式锁设计并提升生产级开发能力的技术人员。1. 从一次超卖事故说起这套 Java Redis 分布式锁源码到底值不值得拆电商大促凌晨两点库存扣减接口在 QPS 破万时出现超卖日志里decr返回负数数据库里同一件商品被卖了三次。事后复盘问题不在 Redis 性能而在锁的粒度、续租和释放逻辑全是拍脑袋写的。这套「基于 Java 的大厂生产级 Redis 高并发分布式锁实战源码」就是冲着这类场景来的——它不是教你setnx就完事的玩具而是把锁的获取、续租、释放、异常兜底拆成可运行的 Maven 多模块工程包含 8 个 Java 类、3 个 XML 配置、2 个 YAML 配置和 3 个属性文件覆盖 Jedis 直连与 Spring Boot 自动装配两条路线。适合已经写过synchronized但在分布式环境里翻过车的后端也适合准备面试「分布式锁使用场景」却答不出 Redlock 争议的 Java 工程师。下面按「资源结构 → 核心实现 → 配置落地 → 避坑 → 进阶验证」的顺序拆每一步都落到能抄的代码和参数上。2. 工程结构与依赖选型39 个文件里哪几个是真正要读的拿到upload.zip解压后目录里同时躺着redis-lock、redis-boot-sentinel-cluster两个子模块和一堆 Eclipse 元数据。很多人第一反应是全部导入 IDE结果被.settings和target里的 class 文件干扰。先搞清楚哪些是源码、哪些是构建产物再决定读的顺序能省掉至少半小时的无效翻找。2.1 模块划分与文件清单从目录树看工程是典型的 Maven 多模块结构根pom.xml做依赖管理两个子模块分别对应「原生 Jedis 实现」和「Spring Boot Sentinel 集群实现」。真正需要精读的 Java 类集中在src/main/java下target/classes里的是编译产物可以直接忽略。下面这张表把关键文件按职责归了类照着读不会迷路。路径类型作用是否精读redis-lock/src/main/javaJava 源码锁获取/续租/释放核心逻辑是redis-boot-sentinel-cluster/src/main/javaJava 源码Spring Boot 自动装配与集群配置是根pom.xmlXML统一版本与模块聚合是*.properties属性连接池、超时等运行参数是*.ymlYAMLSentinel 集群节点与锁行为是.settings/、.gitignore配置IDE 与版本控制否target/编译产物字节码否提示导入 IDE 前先执行一次mvn clean把target清掉否则索引会拖慢整个工程加载。2.2 为什么是 Jedis 而不是 Lettuce项目里同时出现了 Jedis 和 Spring Boot 的 starter但锁的核心操作走的是 Jedis。这不是随意选的。分布式锁对命令的原子性要求极高SET key value NX PX和 Lua 脚本的EVAL必须落在同一条连接、同一个节点上Jedis 的同步阻塞模型让「获取连接 → 执行 → 归还」这条链路非常直观出问题时堆栈也干净。Lettuce 基于 Netty 异步共享连接在集群重定向场景下排查成本更高新手很容易在redis command timed out里绕不出来。常见做法是锁这种强一致、低频但要求确定性的操作走 Jedis 直连普通缓存读写走 Lettuce 或 Spring Data Redis。项目把两者分开放在不同模块正是这个思路。依赖坐标大致如下版本以根pom.xml为准不要自己乱升。!-- 根 pom.xml 中的关键依赖版本号以工程实际为准 -- dependency groupIdredis.clients/groupId artifactIdjedis/artifactId !-- 锁操作依赖同步连接避免异步重定向带来的排查成本 -- /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId !-- 仅用于非锁场景的缓存读写 -- /dependency参数说明jedis负责锁的原子命令spring-boot-starter-data-redis负责常规缓存。两者共存时要注意连接池隔离别让缓存的大流量把锁的连接池占满——这是生产环境里最隐蔽的翻车点之一。2.3 导入与首次编译确认 JDK 和 Maven 版本后按下面步骤跑通第一次编译。这一步的目的是验证依赖能拉下来、模块能识别不涉及业务逻辑。# 1. 解压后进入根目录 unzip upload.zip -d redis-lock-demo cd redis-lock-demo # 2. 清理历史编译产物避免旧 class 干扰 mvn clean # 3. 跳过测试先编译确认依赖完整 mvn compile -DskipTests # 4. 查看模块是否被正确识别 mvn -q -Dexec.executableecho -Dexec.args${project.modules} exec:exec逻辑说明clean清掉targetcompile只编译主源码不跑测试能快速暴露依赖缺失。如果卡在下载依赖检查 Maven 镜像配置如果报模块找不到检查根pom.xml的modules是否包含两个子模块。首次编译通过后再进 IDE 读代码索引会快很多。3. 锁的获取、续租与释放8 个 Java 类里的核心链路这套源码最值钱的部分不是「怎么加锁」而是「锁在异常和超时下怎么不失控」。8 个 Java 类基本围绕三条链路展开加锁的原子性、持有期间的续租、释放时的归属校验。把这三条读透分布式锁的面试题和线上问题就都能接住。3.1 加锁SET NX PX 与唯一 value加锁的核心是一条命令SET lockKey uniqueValue NX PX expireTime。NX保证只有 key 不存在时才设置成功PX保证即使客户端崩溃锁也会自动过期。关键在于uniqueValue必须是每个请求唯一的通常是 UUID 加线程标识释放锁时用它来校验「这把锁是不是我加的」。// 加锁核心逻辑示意结构字段名以工程实际为准 public boolean tryLock(String lockKey, String requestId, int expireMillis) { // NXkey 不存在才设置PX毫秒级过期防止死锁 String result jedis.set(lockKey, requestId, NX, PX, expireMillis); // OK 表示抢锁成功null 表示已被占用 return OK.equals(result); }参数说明lockKey是业务维度的锁名建议带业务前缀如lock:order:123requestId必须全局唯一否则释放时会误删别人的锁expireMillis是锁的兜底过期时间设太短会导致业务没跑完锁就没了设太长会让故障恢复变慢。常见做法是按「业务 P99 耗时 × 3」来估再配合续租兜底。3.2 续租看门狗机制与过期时间博弈锁的过期时间和业务执行时间是一对天然矛盾设短了业务没跑完锁就释放设长了客户端崩溃后要等很久。生产级方案是加一个「看门狗」——后台定时任务在锁快过期时如果业务还在执行就把过期时间续上。续租同样要用 Lua 脚本保证「校验归属 续期」的原子性。// 续租只有 value 匹配还是自己的锁才延长过期时间 String renewScript if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(pexpire, KEYS[1], ARGV[2]) else return 0 end; // KEYS[1]锁名, ARGV[1]requestId, ARGV[2]新的过期毫秒 Long renewed (Long) jedis.eval(renewScript, Collections.singletonList(lockKey), Arrays.asList(requestId, String.valueOf(newExpireMillis)));逻辑说明脚本先get比对 value确认锁还属于当前请求再执行pexpire。两步放在一个 Lua 脚本里Redis 单线程执行保证不会被打断。参数上续租周期一般设为过期时间的三分之一比如锁 30 秒过期每 10 秒续一次。注意续租任务要能感知业务结束否则会一直续下去变成另一种形式的死锁。3.3 释放Lua 脚本保证归属校验释放锁最常见的错误是先get判断再del这两步之间锁可能刚好过期并被别人抢走导致删掉别人的锁。正确做法是把「比对 value」和「删除」写进同一个 Lua 脚本。// 释放value 匹配才删除避免误删他人锁 String unlockScript if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; Long released (Long) jedis.eval(unlockScript, Collections.singletonList(lockKey), Collections.singletonList(requestId));参数说明返回1表示成功释放0表示锁已不属于当前请求可能已过期或被续租失败。业务代码里不要忽略这个返回值它往往是排查「锁提前失效」的第一手线索。释放失败时不要重试删除而应该记录日志并检查续租任务是否正常。3.4 异常兜底finally 与连接归还锁的释放必须放在finally里且要处理 Jedis 连接异常。如果获取连接就失败了finally里再调del会抛二次异常掩盖原始错误。try { boolean locked tryLock(lockKey, requestId, 30000); if (!locked) { // 抢锁失败按业务决定重试还是快速失败 return; } // 执行业务逻辑 } finally { try { unlock(lockKey, requestId); } catch (Exception e) { // 释放失败只记录不抛出避免掩盖业务异常 log.warn(unlock failed, key{}, requestId{}, lockKey, requestId, e); } }逻辑说明finally保证无论业务是否抛异常都会尝试释放内层try-catch保证释放本身的异常不会覆盖业务异常。这是血泪经验——线上曾因为释放抛异常把真正的业务错误吞掉排查方向全跑偏。4. 配置落地properties 与 YAML 里的参数怎么调源码能跑起来不等于能在生产跑。3 个属性文件和 2 个 YAML 配置决定了连接池大小、超时、Sentinel 节点和锁行为这些参数调错锁的可靠性直接打折。这一章把关键配置项拆开讲给出估算方法和调整边界。4.1 连接池与超时参数属性文件里通常有maxTotal、maxIdle、minIdle、maxWaitMillis、timeout这几项。锁操作的连接数不需要很大但等待时间要短避免线程堆积。参数建议值说明maxTotal50100锁操作并发有限过大反而浪费maxIdle20保持一定空闲连接减少创建开销maxWaitMillis5001000抢不到连接快速失败别让线程干等timeout2000单次命令超时超过说明网络或节点异常注意锁的连接池要和缓存的连接池分开配置。共用一个大池子时缓存的大 key 扫描或批量操作会把连接占满锁请求排队超时表现为「偶发抢不到锁」极难排查。4.2 Sentinel 集群配置redis-boot-sentinel-cluster模块的 YAML 里配置了 Sentinel 节点列表、master 名称和密码。集群模式下锁的 key 必须落在同一个 master 上否则主从切换时锁状态会不一致。# Sentinel 集群配置示意字段以工程实际为准 spring: redis: sentinel: master: mymaster # 与 Sentinel 配置的 master 名一致 nodes: # 至少配两个 Sentinel 节点 - 127.0.0.1:26379 - 127.0.0.1:26380 password: your_password # 有密码时必须配否则连接被拒 timeout: 2000参数说明master必须和 Sentinel 端sentinel monitor配置的名字完全一致大小写敏感nodes至少两个单节点 Sentinel 本身就是单点password在启用认证时必填。主从切换期间锁可能短暂不可用业务侧要有降级或重试策略不能假设锁永远可用。4.3 锁行为参数与业务对齐锁的过期时间、续租周期、重试次数这些参数最好从配置文件读而不是硬编码在 Java 里。这样不同业务可以配不同的锁策略不用改代码重新打包。# 锁行为参数按业务维度覆盖 lock.order.expireMillis30000 # 订单锁 30 秒过期 lock.order.renewInterval10000 # 每 10 秒续租一次 lock.order.retryTimes3 # 抢锁失败重试 3 次 lock.order.retryInterval200 # 重试间隔 200 毫秒逻辑说明expireMillis要大于业务 P99 耗时renewInterval取过期时间的三分之一左右retryTimes和retryInterval决定抢锁失败时的行为。重试次数不宜过多否则高并发下会放大 Redis 压力形成「越抢越慢」的负反馈。常见做法是重试 23 次后快速失败让上层决定是否降级。5. 避坑与排查分布式锁最常见的 5 个翻车现场锁的代码看起来简单线上问题却五花八门。这一章按「现象 → 原因 → 解决」整理 5 条真实踩坑记录都是这套源码涉及场景里高频出现的。5.1 锁提前失效导致并发进入现象业务日志显示两个线程同时进入临界区库存被扣了两次。原因锁的过期时间设得比业务执行时间短业务还没跑完锁就自动过期第二个线程趁虚而入。解决把过期时间设为业务 P99 耗时的 3 倍以上同时开启续租续租任务要绑定业务生命周期业务结束立即停止续租。5.2 误删他人锁现象A 线程释放锁后B 线程发现自己刚加的锁没了。原因释放时只做了del没校验 valueA 的锁过期后 B 抢到A 的释放逻辑把 B 的锁删了。解决释放必须用 Lua 脚本比对requestId匹配才删。这套源码的释放逻辑正是这么写的照抄即可。5.3 主从切换丢锁现象master 宕机切换后同一把锁被两个客户端同时持有。原因锁写在 master 上还没同步到 slavemaster 就挂了slave 升主后没有这把锁。解决对一致性要求极高的场景考虑 Redlock 或基于共识的锁服务普通业务接受极小概率的锁失效但要保证业务侧幂等把损失控制在可接受范围。5.4 连接池耗尽导致抢锁超时现象高峰期大量请求报Could not get a resource from the pool。原因锁和缓存共用连接池缓存的大批量操作占满连接。解决锁用独立连接池maxWaitMillis设短抢不到连接快速失败监控连接池活跃数和等待队列长度提前扩容。5.5 续租任务泄漏现象业务早已结束后台还在不停续租锁一直不释放。原因续租任务没有在业务结束时取消线程池里的定时任务持续运行。解决用try-finally保证业务结束时取消续租任务续租任务内部也要检查业务是否还存活避免孤儿任务。这是最隐蔽的坑往往在压测后才暴露。6. 进阶验证用压测和日志确认锁真的可靠代码读完、配置调完最后一步是验证。分布式锁的可靠性不能靠「看起来对」要用并发压测和日志把边界逼出来。我一般会做两件事一是用多线程模拟抢锁看是否严格互斥二是打开 Redis 慢查询和锁操作日志观察续租和释放的时序。6.1 多线程互斥验证写一个最小验证程序起 50 个线程抢同一把锁每个线程在临界区里对共享计数器加一最后检查计数是否等于线程数。如果出现小于说明锁没兜住。// 互斥验证50 线程抢锁临界区自增最终应等于 50 int threads 50; AtomicInteger counter new AtomicInteger(0); CountDownLatch latch new CountDownLatch(threads); ExecutorService pool Executors.newFixedThreadPool(threads); for (int i 0; i threads; i) { pool.submit(() - { String requestId UUID.randomUUID().toString(); try { if (tryLock(lock:test, requestId, 30000)) { // 临界区模拟业务耗时 int v counter.get(); Thread.sleep(10); counter.set(v 1); } } catch (Exception e) { log.error(lock test error, e); } finally { unlock(lock:test, requestId); latch.countDown(); } }); } latch.await(); // 期望输出 50小于则说明互斥被破坏 System.out.println(counter counter.get());逻辑说明每个线程用独立requestId抢到锁才进临界区sleep模拟业务耗时最后校验计数。如果结果小于 50重点查过期时间是否太短、续租是否生效、释放是否误删。这个验证跑通基本能排除大部分逻辑错误。6.2 日志与监控要看什么光有结果不够还要看过程。锁操作建议打三类日志抢锁成功/失败、续租触发、释放结果。关键字段包括lockKey、requestId、耗时和返回值。Redis 侧打开慢查询日志阈值设 10 毫秒锁的 Lua 脚本正常应该在毫秒级完成超过说明网络或节点有压力。观察项正常表现异常信号抢锁耗时毫秒级持续超过 50ms查网络或连接池续租间隔稳定约过期时间 1/3忽长忽短查定时任务调度释放返回1频繁返回 0查锁是否提前过期慢查询无锁相关记录出现 EVAL 慢查询查脚本复杂度6.3 一个我坚持了很久的习惯压测环境里跑通不代表生产可靠网络抖动、主从切换、GC 停顿都会改变锁的行为。从那以后我每次上线锁相关改动都强制走一遍「多线程互斥验证 慢查询观察 续租日志核对」三个都过了才放行。这套源码的价值不在于它写得多完美而在于它把生产里真正会出问题的点都摆出来了照着拆一遍比自己从零踩坑快得多。希望帮到你。本文还有配套的精品资源点击获取