在微服务架构和分布式系统日益普及的今天，单机环境下的线程安全已经无法满足业务需求。当多个服务实例同时操作同一份资源时，如何保证数据的原子性和一致性，成为了开发者必须面对的难题。提到并发控制，很多第一反应就是“分布式锁”。而在众多实现分布式锁的方案中，基于Redis的方案因其高性能和易用性，成为了绝大多数企业的首选。

然而，市面上流传着大量关于Redis分布式锁的“伪教程”，最典型的错误就是仅仅使用 SETNX（Set if Not Exists）命令加一个过期时间，甚至在过期时间设置上存在巨大隐患。今天我们就深入剖析Redis分布式锁的一个核心痛点：如何安全、可靠地实现可重入分布式锁，并解决锁超时导致的数据不一致问题。

我们将聚焦于基于Redisson客户端实现的分布式锁机制。它不仅仅是封装了Jedis或Lettuce，更底层地解决了死锁、脑裂和可重入性等复杂场景。

为什么简单的SETNX行不通？

让我们先看一个典型的错误实现思路。假设我们要保护一段更新库存的代码：

// 错误的伪代码
if (redis.setnx("lock:product:1001", "1")) {
    try {
        // 执行业务逻辑，比如扣减库存
        updateInventory(1001, -1);
    } finally {
        redis.del("lock:product:1001");
    }
}

这个实现有三个致命缺陷：

原子性问题：SETNX 和 EXPIRE 是两个独立的命令。如果在设置锁之后、设置过期时间之前服务崩溃了，这把锁将永远不会释放，导致死锁。虽然可以用Lua脚本解决原子性，但这只是解决了第一步。
超时误删：如果业务逻辑执行时间超过了锁的过期时间，锁会自动释放。此时其他线程获取了锁，而原线程执行完毕后会错误地删除其他线程持有的锁，导致并发安全失效。
不可重入：上述逻辑不支持同一个线程多次获取同一把锁。如果在持锁过程中调用其他需要该锁的方法，将会阻塞自己，造成死锁。

引入Redisson：不仅仅是锁，是完整的解决方案

为了解决上述问题，我们需要引入 Redisson。Redisson 是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid），它提供了完整的分布式Java对象服务。对于分布式锁，Redisson实现了基于 RedLock 算法和 WatchDog（看门狗） 机制的高级锁特性。

首先，我们需要在项目中引入Redisson依赖。假设我们使用Maven构建项目，添加以下依赖：

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

注意版本号，3.23.5 是较新的稳定版本，修复了许多关于Lua脚本在集群环境下执行的边界问题。

核心机制解析：看门狗与可重入锁

Redisson的分布式锁核心在于其实现的 RLock 接口。它底层使用Hash结构存储锁信息，Key格式通常为 redisson_lock{resource_name}，Field为 UUID:ThreadId，Value为可重入计数器。

1. 自动续期（看门狗机制）

这是Redisson最实用的功能之一。当你使用默认配置获取锁时，如果没有指定leaseTime（锁持有时间），Redisson会启动一个后台线程（看门狗）来监控锁的状态。

默认情况下，��的过期时间是30秒（LOCK_EXPIRE_INTERVAL）。只要持有锁的客户端还在运行，看门狗就会每隔10秒（WATCHDOG_PERIOD）检查一次，如果锁依然存在，就自动将过期时间重置为30秒。这完美解决了“业务执行时间不确定”导致的误删锁问题。

2. 可重入性

Redisson的锁支持可重入。当同一个线程多次获取同一把锁时，计数器会递增。只有当该线程释放相同次数的锁后，锁才会真正从Redis中删除。这是通过Lua脚本保证原子性实现的：

-- 伪Lua逻辑简述
if redis.call('hexists', KEYS[1], ARGV[2]) == 1 then
    redis.call('hincrby', KEYS[1], ARGV[2], 1)
    redis.call('pexpire', KEYS[1], ARGV[1])
    return 1
end
return 0

实战代码示例

下面是一个完整的Spring Boot集成Redisson分布式锁的示例，展示了如何在高并发场景下安全地更新商品库存。

第一步：配置Redisson客户端

在 application.yml 中配置Redis连接信息：

spring:
  redis:
    host: 192.168.1.100
    port: 6379
    password: yourpassword
    database: 0

第二步：编写锁服务

import org.redisson.Redisson;
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.stereotype.Service;

import java.util.concurrent.TimeUnit;

@Service
public class DistributedLockService {

    private final RedissonClient redissonClient;

    // 假设通过Spring注入或初始化获取RedissonClient
    public DistributedLockService(RedissonClient redissonClient) {
        this.redissonClient = redissonClient;
    }

    /**
     * 扣减库存的分布式锁实现
     * @param productId 商品ID
     * @param amount    扣减数量
     * @return 是否成功
     */
    public boolean deductStock(String productId, int amount) {
        // 1. 获取锁实例，锁名称需唯一
        RLock lock = redissonClient.getLock("stock_lock:" + productId);
        
        boolean locked = false;
        try {
            // 2. 尝试获取锁，等待10秒，锁自动释放时间30秒（由看门狗管理）
            // 注意：这里leaseTime参数如果不传，默认开启看门狗
            locked = lock.tryLock(10, 30, TimeUnit.SECONDS);
            
            if (locked) {
                // 3. 只有获取到锁才能执行临界区代码
                // 此处模拟数据库查询和更新
                boolean success = updateInventoryInDB(productId, amount);
                return success;
            } else {
                // 获取锁失败，记录日志或返回失败
                System.out.println("Failed to acquire lock for product: " + productId);
                return false;
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return false;
        } finally {
            // 4. 释放锁
            if (locked) {
                lock.unlock();
            }
        }
    }

    private boolean updateInventoryInDB(String productId, int amount) {
        // 模拟数据库操作
        // 实际生产中这里应该结合Lua脚本或事务保证Redis缓存与DB的一致性
        return true;
    }
}

第三步：测试验证

为了验证可重入性和安全性，我们可以编写一个测试用例，模拟线程自调用：

// 模拟内部调用获取锁
public void nestedDeduct() {
    RLock lock = redissonClient.getLock("stock_lock:9527");
    try {
        lock.lock();
        // 这里可以再次调用 deductStock，不会死锁
        // 因为Redisson检测到是当前线程持有的锁，计数器+1
        System.out.println("Nested lock acquired. Reentrancy count: " + lock.getHoldCount());
    } finally {
        lock.unlock();
    }
}

进阶：RedLock算法与集群部署

如果你的Redis是主从架构或Cluster集群，单节点的 RLock 可能存在脑裂风险。例如，客户端A获取了Master锁，Master宕机且锁未同步到Slave，客户端B随即在Slave上获取了锁，导致双写冲突。

Redisson提供了基于 RedLock 算法的 RedissonRedLock。它要求客户端向多个独立的Redis节点获取锁，只有当大多数节点（N/2 + 1）返回成功时，才认为获取锁成功。

RLock lock1 = redissonClient.getLock("lock1");
RLock lock2 = redissonClient.getLock("lock2");
RLock lock3 = redissonClient.getLock("lock3");
RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);

// 尝试获取红锁
boolean locked = redLock.tryLock(10, 30, TimeUnit.SECONDS);

需要注意的是，RedLock算法在学术界曾引发争议（如《Redis Distributed Lock is flawed》一文），但在实际工程实践中，配合合理的超时配置和重试机制，它仍然是应对集群环境的最有效方案之一。对于绝大多数非金融级强一致性要求的业务，单节点Redisson Lock配合看门狗已完全足够。

总结与最佳实践

使用Redis实现分布式锁并非简单的 SETNX，而是一个系统工程。通过Redisson这一工具，我们获得了以下核心优势：

原子性：基于Lua脚本保证加锁、续期、解锁的原子操作。
安全性：看门狗机制防止业务未执行完锁即过期。
可重入：Hash结构记录线程ID和计数，支持递归调用。
高性能：Redis的单线程模型保证了极高的并发性能。

在实际生产中，请务必注意以下几点：

锁的粒度：锁的粒度应尽量细，避免锁住整个业务方法，只锁住关键资源操作。
超时时间设置：虽然看门狗可以续期，但 tryLock 的等待时间应设置合理，避免线程长时间阻塞。
异常处理：务必在 finally 块中释放锁，防止因异常导致锁无法释放。
监控告警：监控锁的等待时间和持有时长，及时发现慢查询或死锁隐患。

Redis分布式锁虽然强大，但它属于“最终一致性”范畴，不适用于对一致性要求极高的场景（如转账）。在那种场景下，请考虑使用数据库悲观锁或ZooKeeper实现强一致性锁。但在电商秒杀、库存预扣、热点计数等绝大多数互联网场景中，Redisson提供的分布式锁方案无疑是目前Java生态中最实用、最高效的选择。