Spring自定义@Lock注解实现并发控制

1. 项目概述：Spring中自定义@Lock注解的实现与应用

在Java后端开发中，处理并发问题是个永恒的话题。当多个线程同时访问共享资源时，如果没有适当的同步机制，就会导致数据不一致的问题。Spring框架虽然提供了丰富的功能组件，但并没有内置的锁注解解决方案。本文将详细介绍如何通过自定义@Lock注解结合AOP切面技术，优雅地解决单机环境和分布式环境下的并发控制问题。

这个方案的核心价值在于：

• 通过注解方式实现声明式加锁，业务代码无需关心锁的获取和释放细节
• 一套注解适配两种场景：本地锁（单机部署）和分布式锁（集群部署）
• 支持灵活的锁标识定义，可通过SpEL表达式动态生成锁key
• 内置防死锁机制，包括超时控制和自动释放保障

2. 核心设计与实现原理

2.1 技术架构解析

整个解决方案建立在三个关键技术之上：

1. Java注解机制：定义@Lock注解及其属性，为方法提供元数据标记
2. Spring AOP：通过环绕通知拦截被注解的方法，在方法执行前后插入锁控制逻辑
3. 锁实现层：抽象本地锁(ReentrantLock)和分布式锁(Redisson)两种实现

这种分层设计使得业务代码与锁实现解耦，当需要切换锁类型时，只需替换切面实现类即可，业务方法无需任何修改。

2.2 注解定义详解

@Lock注解的设计考虑了实际业务场景的需求：

java复制@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Lock {
    String key() default "";
    long waitTime() default 5;
    long leaseTime() default 30;
    TimeUnit timeUnit() default TimeUnit.SECONDS;
}

各参数的作用和设计考量：

• key：锁的唯一标识，支持SpEL表达式。默认使用"类名.方法名"，但实际业务中建议按业务维度设计（如"order:#orderId"）
• waitTime：获取锁的最大等待时间，避免线程长时间阻塞。根据系统容忍度设置，电商场景通常设置1-5秒
• leaseTime：锁的持有时间，必须大于方法执行时间。分布式环境下尤为重要，防止进程崩溃导致死锁
• timeUnit：时间单位，统一参数的时间维度

提示：leaseTime的设置需要权衡 - 过短可能导致业务未执行完锁就释放，过长则可能因进程崩溃导致资源长时间锁定。建议通过压测确定合理值。

3. 本地锁实现细节

3.1 核心组件设计

本地锁实现主要包含两个核心类：

1. Lock注解：如前所述，定义锁的行为特征
2. LocalLockAspect切面：实现具体的锁控制逻辑

切面类的设计要点：

• 使用ConcurrentHashMap缓存锁对象，避免重复创建
• 通过SPEL解析器处理动态key的生成
• 实现try-finally模式确保锁的释放

3.2 锁的获取与释放流程

完整的加锁-执行-释放流程如下：

1. 解析锁标识：根据注解配置和方法的参数值，生成最终的锁key
2. 获取锁实例：从缓存中获取或创建新的ReentrantLock实例
3. 尝试加锁：在指定时间内尝试获取锁，超时则抛出异常
4. 执行业务逻辑：执行被注解的原始方法
5. 释放锁：在finally块中检查并释放锁

关键代码片段：

java复制@Around("@annotation(lock)")
public Object around(ProceedingJoinPoint joinPoint, Lock lock) throws Throwable {
    String lockKey = resolveLockKey(joinPoint, lock);
    Lock reentrantLock = lockCache.computeIfAbsent(lockKey, k -> new ReentrantLock());
    
    boolean locked = false;
    try {
        locked = reentrantLock.tryLock(lock.waitTime(), lock.leaseTime(), lock.timeUnit());
        if (!locked) throw new RuntimeException("获取锁失败");
        return joinPoint.proceed();
    } finally {
        if (locked && reentrantLock.isHeldByCurrentThread()) {
            reentrantLock.unlock();
        }
    }
}

3.3 动态key的解析实现

支持SpEL表达式让锁的粒度控制更加灵活。解析过程主要分为三步：

1. 获取方法参数名和参数值
2. 构建SPEL上下文环境
3. 解析表达式并生成最终key

java复制private String resolveLockKey(ProceedingJoinPoint joinPoint, Lock lock) {
    if (lock.key().isEmpty()) {
        return joinPoint.getTarget().getClass().getName() + "." + joinPoint.getSignature().getName();
    }
    
    MethodSignature signature = (MethodSignature) joinPoint.getSignature();
    String[] paramNames = parameterNameDiscoverer.getParameterNames(signature.getMethod());
    Object[] args = joinPoint.getArgs();
    
    StandardEvaluationContext context = new StandardEvaluationContext();
    for (int i = 0; i < paramNames.length; i++) {
        context.setVariable(paramNames[i], args[i]);
    }
    
    return spelParser.parseExpression(lock.key()).getValue(context, String.class);
}

4. 分布式锁实现方案

4.1 为什么需要分布式锁

当应用部署在多个实例上时，本地锁只能控制单个JVM内的线程同步，无法跨进程保证互斥。分布式锁通过外部存储系统（通常是Redis）实现跨JVM的锁协调。

4.2 基于Redisson的实现

Redisson是Redis的Java客户端，提供了丰富的分布式对象和服务，其中RLock接口实现了java.util.concurrent.locks.Lock规范，使用非常方便。

4.2.1 环境准备

首先添加Maven依赖：

xml复制<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson-spring-boot-starter</artifactId>
    <version>3.23.3</version>
</dependency>

SpringBoot会自动配置RedissonClient实例，只需在切面中注入即可使用。

4.2.2 切面实现调整

分布式锁切面与本地锁的结构类似，主要区别在于锁的获取方式：

java复制@Around("@annotation(lock)")
public Object around(ProceedingJoinPoint joinPoint, Lock lock) throws Throwable {
    String lockKey = resolveLockKey(joinPoint, lock);
    RLock redissonLock = redissonClient.getLock(lockKey);
    
    boolean locked = false;
    try {
        locked = redissonLock.tryLock(lock.waitTime(), lock.leaseTime(), lock.timeUnit());
        if (!locked) throw new RuntimeException("获取分布式锁失败");
        return joinPoint.proceed();
    } finally {
        if (locked && redissonLock.isHeldByCurrentThread()) {
            redissonLock.unlock();
        }
    }
}

Redisson的RLock同样实现了tryLock方法，参数语义与ReentrantLock保持一致，这使得两种实现的切换非常平滑。

4.3 分布式锁的注意事项

1. 网络问题：Redis网络波动可能导致锁获取或释放失败，需要有重试机制
2. 时钟漂移：不同服务器时间不一致可能影响锁的过期判断
3. 锁续期：对于长时间任务，需要考虑锁的自动续期机制

实际项目中，Redisson已经处理了大部分边界情况，比自行实现Redis分布式锁更可靠。

5. 应用实践与性能优化

5.1 典型应用场景

1. 库存扣减：防止超卖

   java复制@Lock(key = "'product_stock:' + #productId")
   public void deductStock(Long productId, int quantity) {
       // 检查并扣减库存
   }
   

2. 订单创建：防止重复下单

   java复制@Lock(key = "'order_create:' + #userId")
   public void createOrder(Long userId, OrderDTO orderDTO) {
       // 创建订单逻辑
   }
   

3. 定时任务：防止多实例重复执行

   java复制@Scheduled(cron = "0 0/5 * * * ?")
   @Lock(key = "'job_report_generate'", leaseTime = 60*4)
   public void generateDailyReport() {
       // 生成报表逻辑
   }
   

5.2 性能优化建议

1. 锁粒度控制：尽量缩小锁的范围，比如按用户ID或商品ID加锁，而不是全局锁
2. 锁等待时间：根据业务容忍度设置合理的waitTime，避免线程长时间阻塞
3. 锁分离策略：读写分离，读多写少的场景考虑使用读写锁
4. 避免锁嵌套：防止死锁和性能下降

5.3 监控与报警

在生产环境中，建议对锁的使用添加监控：

1. 记录锁等待时间过长的操作
2. 监控锁获取失败率
3. 对死锁情况设置报警

可以通过Spring的AOP机制轻松实现这些监控点。

6. 常见问题与解决方案

6.1 锁获取失败处理

当获取锁失败时，通常有以下几种处理方式：

1. 快速失败：直接抛出异常，由上层处理

   java复制if (!locked) {
       throw new BusinessException("系统繁忙，请稍后重试");
   }
   

2. 重试机制：在切面中添加有限次数的重试

   java复制int retries = 3;
   while (retries-- > 0) {
       if (redissonLock.tryLock(waitTime, leaseTime, timeUnit)) {
           try {
               return joinPoint.proceed();
           } finally {
               redissonLock.unlock();
           }
       }
   }
   throw new BusinessException("操作过于频繁，请稍后再试");
   

3. 异步排队：将请求放入队列，稍后处理

6.2 锁的公平性问题

默认情况下，无论是ReentrantLock还是Redisson的RLock，都是非公平锁。如果需要严格按请求顺序获取锁，可以：

java复制// 本地锁
new ReentrantLock(true); // true表示公平锁

// 分布式锁
redissonClient.getFairLock(lockKey);

但公平锁会带来性能开销，除非有强顺序要求，否则不建议使用。

6.3 锁的可重入性

方案中使用的锁都是可重入的，即同一个线程可以重复获取已持有的锁。这在递归调用或嵌套调用场景下非常重要。

验证当前线程是否持有锁：

java复制reentrantLock.isHeldByCurrentThread()  // 本地锁
redissonLock.isHeldByCurrentThread()   // 分布式锁

7. 高级特性扩展

7.1 锁的降级策略

在高并发场景下，可以考虑动态调整锁的粒度或类型。例如：

1. 当系统负载高时，自动增大锁粒度减少锁竞争
2. 根据配置动态切换本地锁和分布式锁
3. 在切面中添加熔断机制，当锁竞争过于激烈时暂时降级

7.2 多锁管理

对于需要同时获取多个锁的场景，可以扩展注解支持锁数组：

java复制@MultiLock(keys = {"#order.id", "#user.id"})
public void complexOperation(Order order, User user) {
    // 需要同时锁定订单和用户资源的操作
}

实现时需要注意按固定顺序获取锁，避免死锁。

7.3 锁与事务的结合

当锁与数据库事务一起使用时，要注意执行顺序：

1. 先获取锁，再开启事务
2. 先提交事务，再释放锁

这样可以避免其他线程在事务未提交时就读取到中间状态的数据。

8. 方案对比与选型建议

8.1 本地锁 vs 分布式锁

8.2 与其他方案对比

1. synchronized关键字：

   • 优点：使用简单，JVM内置支持
   • 缺点：无法跨方法控制，不支持超时，粒度较粗

2. 数据库悲观锁：

   • 优点：实现简单，强一致性
   • 缺点：性能差，容易导致死锁

3. Zookeeper分布式锁：

   • 优点：可靠性高，有现成实现
   • 缺点：性能低于Redis，部署复杂度高

对于大多数Spring应用，本文的自定义@Lock注解方案在简洁性和功能性上取得了良好平衡。

9. 实际应用中的经验分享

在实际项目中使用这套锁机制几年后，我总结了一些宝贵经验：

1. 锁命名规范：建立统一的锁key命名规则，如"业务域:资源类型:资源ID"，便于维护和排查问题

2. 锁日志记录：在切面中添加debug日志，记录锁的获取和释放情况，但要注意日志量控制

3. 锁超时设置：根据压测结果设置合理的默认值，我们的经验值是：

   • waitTime: 2-3秒（用户操作场景）
   • leaseTime: 最大预期执行时间的2倍

4. 避免锁滥用：不是所有共享资源都需要加锁，考虑使用乐观锁或其他并发控制方式

5. 测试策略：

   • 单元测试验证锁的基本功能
   • 集成测试验证分布式锁的协调
   • 压力测试验证锁性能

6. 故障处理：设计锁失效时的降级方案，比如：

   • 快速失败返回友好提示
   • 进入排队流程异步处理
   • 对于非关键操作可以尝试最终一致性

这套自定义锁注解方案已经在我们的多个生产系统中稳定运行，有效解决了各类并发问题。它的最大优势在于将复杂的锁机制简化为一个简单的注解，让开发人员可以更专注于业务逻辑的实现。