xmlns="http://www.w3.org/2000/svg"

style="display:

分布式锁的正确使用姿势，我后悔没早知道

上个月项目里一个定时任务重复执行了两次，导致数据被重复处理，查了很久才发现是分布式锁失效了。

当时我用的是

Redis

命令，自认为写得没问题，结果在并发场景下完全不行。

这篇文章把踩过的坑和正确的做法分享出来，希望你们别再重蹈覆辙。

一、为什么你的分布式锁总失效？

先说说我踩的第一个坑。

当时我自信满满地写了这样的代码：

publicBooleantryLock(StringlockKey,StringrequestId){Booleanresult=redisTemplate.opsForValue().setIfAbsent(lockKey,requestId,10,TimeUnit.SECONDS);returnresult;}

看起来挺完美对吧？设置了

秒过期时间，防止锁死。

但是问题来了：

问题场景：线程

获取锁后开始执行任务，执行到一半时业务逻辑耗时超过了

同时在执行同一任务，数据就被重复处理了。

根本原因：我没有正确理解

Redis

分布式锁的"看门狗"机制。

锁的过期时间应该由业务执行时间动态决定，而不是写死一个固定值。

二、Redis

分布式锁的核心原理

想用好分布式锁，先得搞懂它的核心原理。

Redis

SETNX（SET

eXists）命令的原子性：

//
伪代码：获取锁if(redis.setnx(lockKey,requestId)==1){//
获取成功，设置过期时间redis.expire(lockKey,30);try{//
业务逻辑}finally{//
释放锁if(requestId.equals(redis.get(lockKey))){redis.del(lockKey);}}}

但这段代码有三个致命问题：

问题1：SETNX

EXPIRE

执行前崩溃，锁就永远不会过期。

问题2：释放锁时没有验证价值

/>如果线程

的锁给释放掉。

问题3：无法自动续期

/>业务执行时间超过锁过期时间，锁自动失效，其他线程可以进来搞破坏。

三、Redisson

框架的正确打开方式

说了这么多坑，该上正确的解决方案了。

Redisson

Java

客户端之一，它帮我们封装好了分布式锁的所有细节。

1.

引入依赖

<dependency><groupId>org.redisson</groupId><artifactId>redisson-spring-boot-starter</artifactId><version>3.24.3</version></dependency>

2.

Redisson

客户端

@ConfigurationpublicclassRedissonConfig{@Value("${spring.data.redis.host}")privateStringhost;@Value("${spring.data.redis.port}")privateStringport;@BeanpublicRedissonClientredissonClient(){Configconfig=newConfig();Stringaddress="redis://"+host+":"+port;config.useSingleServer().setAddress(address).setPassword("yourpassword")//
如果有密码.setConnectionPoolSize(64).setConnectionMinimumIdleSize(10);returnRedisson.create(config);}}

3.

使用分布式锁

@ServicepublicclassOrderService{@AutowiredprivateRedissonClientredissonClient;publicvoidcreateOrder(Orderorder){StringlockKey="order:lock:"+order.getProductId();RLocklock=redissonClient.getLock(lockKey);try{//
等待锁超时时间
会自动续期lock.lock(30,TimeUnit.SECONDS);//
业务逻辑：检查库存、创建订单、扣减库存checkStock(order);saveOrder(order);deductStock(order);}catch(Exceptione){log.error("Order
creation
failed",e);thrownewRuntimeException("创建订单失败",e);}finally{//
释放锁if(lock.isHeldByCurrentThread()){lock.unlock();}}}}

这样写有几个好处：

• 自动续期：Redisson

  内置看门狗机制，默认每

  秒检查一次，如果业务还在执行，自动续期

  秒

• 原子操作：获取锁和设置过期时间是原子执行的
• 可重入：同一个线程可以多次获取同一把锁

四、常见坑点与最佳实践

坑点1：锁的

key

设计不合理

错误做法：所有业务都用同一个

key"lock"

正确做法：按业务维度设计

key，例如：

//
订单业务StringlockKey="lock:order:"+orderId;//
库存业务StringlockKey="lock:stock:"+productId;//
分布式环境下，用
确保唯一性StringrequestId=UUID.randomUUID().toString()+":"+Thread.currentThread().getId();

坑点2：释放锁时没有验证

owner

错误做法：

//
直接删除，不检查是谁的锁redisTemplate.delete(lockKey);

正确做法：

//
Redisson
释放锁时会验证是否是当前线程持有的锁lock.unlock();

如果用原生

Redis，要用

脚本保证原子性：

Stringscript="if
KEYS[1])
"+"return
KEYS[1])
end";redisTemplate.execute(newDefaultRedisScript<>(script,Long.class),Collections.singletonList(lockKey),requestId);

坑点3：没有处理获取锁失败的情况

错误做法：获取不到锁就直接报错

正确做法：根据业务场景选择等待策略

//
策略1：等待并重试booleanacquired=lock.tryLock(10,30,TimeUnit.SECONDS);if(acquired){try{//
业务逻辑}finally{lock.unlock();}}else{//
获取锁失败，执行降级逻辑log.warn("Failed
acquire
fallback");executeFallback();}//
策略2：立即返回，不阻塞if(lock.tryLock()){try{//
业务逻辑}finally{lock.unlock();}}else{//
直接返回结果或提示用户returnResult.fail("系统繁忙，请稍后重试");}

坑点4：集群环境下锁失效

如果

Redis

是主从架构，主节点宕机时可能导致锁丢失。

建议使用

RedLock

Cluster：

//
Redisson
配置RLocklock1=redissonClient1.getLock(lockKey);RLocklock2=redissonClient2.getLock(lockKey);RLocklock3=redissonClient3.getLock(lockKey);RedissonRedLockredLock=newRedissonRedLock(lock1,lock2,lock3);redLock.lock();try{//
业务逻辑}finally{redLock.unlock();}

写在最后

分布式锁是微服务架构中的必备技能，用错了轻则数据重复，重则资金损失。

我在项目里血的教训总结下来就三点：

1. 用成熟的框架：别自己造轮子，Redisson

   已经处理了大部分边界情况

2. 注意锁的粒度：key

   设计要足够细，避免影响并发性能

3. 做好失败降级：获取不到锁时要有兜底方案，别把所有请求都堵死

希望这篇文章能帮你们少踩坑。

如果觉得有用，点个赞再走～