ReentrantLock需结合业务提炼安全可复用加锁结构：一、try-finally确保unlock；二、复用Lock实例并谨慎清理；三、可用Spring AOP实现声明式加锁；四、注意锁粒度、避免锁内远程调用、慎用可重入、集群需分布式锁。
ReentrantLock 本身不提供“开箱即用”的业务模板，但结合常见业务诉求（如防重提交、库存扣减、幂等操作），可以提炼出清晰、安全、可复用的加锁结构。关键不在“炫技”，而在明确锁粒度、保障异常安全、避免死锁、兼顾可读性。
一、基础安全模板：try-finally 确保 unlock
这是最核心原则——lock() 和 unlock() 必须配对，且 unlock() 必须在 finally 中执行，否则线程中断或异常时会永久持锁。
示例（扣减用户余额）：
ReentrantLock lock = new ReentrantLock();
try {
if (!lock.tryLock(3, TimeUnit.SECONDS)) {
throw new BusinessException("操作繁忙，请稍后重试");
}
// ✅ 执行业务逻辑：查余额 → 校验 → 扣减 → 持久化
BigDecimal balance = accountService.getBalance(userId);
if (balance.compareTo(amount) < 0) {
throw new BusinessException("余额不足");
}
accountService.deductBalance(userId, amount);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
throw new BusinessException("操作被中断");
} finally {
if (lock.isHeldByCurrentThread()) { // 防止 unlock 未加锁线程（防御性检查）
lock.unlock();
}
}
说明：
立即学习“Java免费学习笔记（深入）”；
- 用 tryLock(timeout) 替代 lock()，避免无限等待；超时后主动失败比阻塞更利于系统稳定
- isHeldByCurrentThread() 是防御性写法，防止误 unlock 或重复 unlock
- 中断处理要显式恢复中断状态，符合 Java 并发规范
二、基于业务 Key 的动态锁：避免全局锁竞争
直接 new ReentrantLock() 是单实例锁，所有调用串行化。真实场景需按业务维度隔离，例如“按用户 ID 加锁”或“按订单号加锁”。推荐使用 ConcurrentHashMap + Lock 实现轻量级分段锁：
// 全局缓存：key → lock 实例（带自动清理可选）
private static final ConcurrentMap<String, ReentrantLock> LOCK_MAP
= new ConcurrentHashMap<>();
public void processOrder(String orderId) {
ReentrantLock lock = LOCK_MAP.computeIfAbsent(orderId, k -> new ReentrantLock());
try {
if (!lock.tryLock(2, TimeUnit.SECONDS)) {
throw new BusinessException("订单处理中，请勿重复提交");
}
// 执行订单校验、状态变更等
orderService.handle(orderId);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new BusinessException("处理中断");
} finally {
if (lock.isHeldByCurrentThread()) {
lock.unlock();
// ? 可选：空闲后清理 lock（避免内存泄漏），例如用 ScheduledExecutor 清理超时未用 lock
if (lock.getHoldCount() == 0 && lock.hasQueuedThreads() == false) {
LOCK_MAP.remove(orderId, lock);
}
}
}
}
注意点：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- Lock 实例应复用，不要每次 new —— 否则失去锁意义
- 清理策略要谨慎：高频 key（如热门商品）不宜频繁 remove；低频 key 可定时扫描清理
- 若需更健壮方案，可用
Striped<lock></lock>（Guava）或LockFreeLinkedQueue等成熟分段工具
三、与 Spring AOP 结合：声明式加锁（适合通用幂等场景）
当多个服务方法都需要“按参数加锁”时，可封装为自定义注解 + AOP 切面，把加锁逻辑从业务代码中剥离：
定义注解：
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface LockByParam {
String keyExpr() default ""; // SpEL 表达式，如 "#order.userId"
long timeout() default 3000;
TimeUnit unit() default TimeUnit.MILLISECONDS;
}
AOP 切面核心逻辑（简化版）：
@Around("@annotation(lockAnno)")
public Object doLock(ProceedingJoinPoint joinPoint, LockByParam lockAnno) throws Throwable {
String lockKey = parseKeyExpression(joinPoint, lockAnno.keyExpr()); // 解析 SpEL
ReentrantLock lock = lockCache.get(lockKey); // 复用锁
if (!lock.tryLock(lockAnno.timeout(), lockAnno.unit())) {
throw new BusinessException("操作冲突：" + lockKey);
}
try {
return joinPoint.proceed();
} finally {
if (lock.isHeldByCurrentThread()) lock.unlock();
}
}
业务方法即可简洁调用：
@LockByParam(keyExpr = "#order.orderId")
public void confirmOrder(Order order) {
// 无需关心加锁，专注业务
orderService.confirm(order);
}
优点：
- 业务代码零侵入，关注点分离
- 统一超时、重试、日志、监控埋点入口
- 便于后续替换为 Redis 分布式锁（只需改切面实现）
四、避坑提醒：这些细节决定是否真正“优雅”
不是写上 lock/unlock 就算优雅。以下问题高频发生：
- 锁粒度错位：用同一个 lock 保护不同业务资源（如用 userLock 扣减库存），导致无关请求互相阻塞
- 锁内调用外部服务：在 lock 块里远程调用 HTTP/API，一旦慢或超时，锁长期占用 → 推荐锁内只做本地状态检查和 DB update，异步发消息触发后续动作
- 忽略可重入性滥用：ReentrantLock 可重入，但过度嵌套（如 A 方法加锁后调 B 方法又加同一把锁）易引发理解偏差和调试困难；尽量保持单层加锁
- 未考虑分布式场景：JVM 内 ReentrantLock 无法跨进程同步；单机应用 OK，集群部署必须升级为 Redis/ZooKeeper 分布式锁
不复杂但容易忽略。模板的价值，在于把防御性、可观测性、可维护性提前固化下来，而不是让每个开发者重新发明轮子。
