ReentrantLock 通过 AQS 的 exclusiveOwnerThread 字段和可累加的 state 计数器判断重入：state==0 空闲；state>0 且 exclusiveOwnerThread 为当前线程则可重入；否则需排队。tryLock() 与 lock() 在重入时行为一致，仅首次失败时处理不同。unlock() 必须与 lock() 次数严格匹配，否则导致死锁或抛 IllegalMonitorStateException。公平锁下重入仍生效，但每次 lock() 需检查队列，性能较低。
ReentrantLock 是怎么知道“当前线程已经持锁了”的
靠的是内部的 AQS（AbstractQueuedSynchronizer）和一个叫 exclusiveOwnerThread 的字段。每次调用 lock()，它先检查这个字段是否为当前线程；如果是，就直接把同步状态（state）加 1，不阻塞也不排队。
关键点在于：state 不是简单的 0/1 标志位，而是可累加的重入计数器。这也是它和 synchronized 在 JVM 层实现逻辑上最相似的地方——都靠“线程身份 + 计数”判断是否可重入。
-
state == 0：锁空闲 -
state > 0 && exclusiveOwnerThread == currentThread：当前线程已持有，可重入 -
state > 0 && exclusiveOwnerThread != currentThread：被其他线程持有，当前线程需排队或失败
tryLock() 和 lock() 在重入时行为一样吗
一样。只要当前线程已持锁，tryLock() 也会成功返回 true，且 state 同样自增。区别只在首次获取锁失败时：lock() 会阻塞等待，tryLock() 立即返回 false。
注意：带超时的 tryLock(long, TimeUnit) 也是可重入的，只要在超时前完成重入，就视为成功。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
ReentrantLock lock = new ReentrantLock(); lock.lock(); // state = 1 lock.lock(); // state = 2 → 成功，不阻塞 System.out.println(lock.getHoldCount()); // 输出 2
unlock() 必须和 lock() 次数严格匹配吗
必须。每次 unlock() 都会让 state 减 1，只有当 state 减到 0 时，才真正释放锁、唤醒等待队列头节点。如果少调一次 unlock()，锁就一直被占用；多调一次则抛出 IllegalMonitorStateException。
- 未完全释放 → 其他线程永远拿不到锁，极易引发死锁或饥饿
- 多 unlock → 运行时报错，堆栈里会明确出现
java.lang.IllegalMonitorStateException: attempt to unlock lock, not owned by current thread - 建议配合 try-finally 使用，确保 unlock 执行
公平锁模式下重入还生效吗
生效，但排队逻辑有影响。公平锁（new ReentrantLock(true)）只保证“新来的线程”按 FIFO 排队，不干扰当前线程的重入判断。也就是说：当前线程重入时，依然直接成功，不会插队，也不会被自己之前的等待节点挡住。
真正受影响的是其他线程——它们必须等当前线程所有重入次数都 unlock() 完、且队列头轮到自己时，才能获取锁。
容易忽略的一点：公平锁性能通常比非公平锁低，因为每次 lock() 都要检查同步队列是否为空，即使当前线程已经持锁，这部分开销也省不掉。
