Java可重入锁要求同一线程且同一锁实例才能重入，依赖AQS中state计数器和exclusiveOwnerThread字段匹配；ReentrantLock需手动配对lock/unlock，易因异常导致锁泄漏，而synchronized由JVM自动管理。
Java可重入锁就是同一个线程能反复 lock() 同一把 ReentrantLock 而不被自己卡死——它靠“线程ID + 计数器”实现，不是魔法，是明确的状态管理。
为什么必须是“同一线程 + 同一锁实例”才能重入？
可重入性不是对任意锁都生效，而是严格绑定到具体锁对象和调用线程的。JVM 或 AQS 不会跨实例、跨线程做“信任”。
比如：new ReentrantLock() 创建的是独立锁实例，两个不同实例之间完全不共享重入状态。
- 判断逻辑：每次
lock()时，AQS 会检查state（锁计数）和exclusiveOwnerThread（持有线程）——只有两者匹配才允许重入并递增state - 反例：线程 A 持有
lock1，再对lock2（另一个ReentrantLock实例）调用lock()，哪怕在同一个方法里，也一定会阻塞（除非已释放lock2） - 常见误用：在
Spring Bean 中把
ReentrantLock声明为static，导致多个实例共用一把锁，破坏了本意的“实例级隔离”
ReentrantLock 和 synchronized 的重入行为差异在哪？
表面效果一致（都可重入），但底层机制和风险点完全不同：
-
synchronized是 JVM 层自动管理：进入同步块自动加锁，异常或退出自动释放，不可能漏掉unlock -
ReentrantLock是 API 层手动控制：必须显式lock()和unlock()，且unlock()次数必须等于lock()次数，否则state不归零，锁永远无法被其他线程获取 - 关键区别：如果
ReentrantLock在try块中抛异常且没进finally，或者unlock()被跳过（比如 return 写在finally外），就会造成“锁泄漏”——这不是死锁，而是资源永久占用
怎么验证一个锁确实是可重入的？写个最小可测代码
别依赖文档，直接跑一段能暴露重入行为的代码。重点看是否能连续 lock() 两次而不阻塞，以及释放后其他线程能否抢到。
public class ReentrantCheck {
private final ReentrantLock lock = new ReentrantLock();
public void outer() {
lock.lock();
try {
System.out.println("outer: locked, count = " + getHoldCount());
inner();
} finally {
lock.unlock(); // 这里只 unlock 一次
}
}
public void inner() {
lock.lock(); // 同一线程再次 lock → 成功，state 变 2
try {
System.out.println("inner: locked, count = " + getHoldCount());
} finally {
lock.unlock(); // 必须 unlock 两次才能真正释放
}
}
private int getHoldCount() {
return lock.getHoldCount(); // 注意：这是调试用，非生产推荐
}
public static void main(String[] args) {
ReentrantCheck test = new ReentrantCheck();
test.outer(); // 输出 count=1 → count=2 → 最终释放
}
}
运行后输出应为：outer: locked, count = 1 → inner: locked, count = 2。若把 inner() 改成另一个线程调用，第二行就会卡住——这才是验证“同线程”这个前提的关键。
最容易被忽略的点：重入不是免费的，每次 lock()/unlock() 都要读写 state 和比较线程引用，高竞争下比 synchronized（尤其轻量级锁膨胀前）略重；但它的价值不在性能，而在可控性——比如你要 tryLock(3, TimeUnit.SECONDS) 或响应 interrupt()，那就没得选。
