Java面试——ReentrantLock的可重入性实现-Java面试题-PHP中文网

ReentrantLock 通过 AQS 的 exclusiveOwnerThread 字段和可累加的 state 计数器判断重入：state==0 空闲；state>0 且 exclusiveOwnerThread 为当前线程则可重入；否则需排队。tryLock() 与 lock() 在重入时行为一致，仅首次失败时处理不同。unlock() 必须与 lock() 次数严格匹配，否则导致死锁或抛 IllegalMonitorStateException。公平锁下重入仍生效，但每次 lock() 需检查队列，性能较低。

java面试——reentrantlock的可重入性实现

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) 也是可重入的，只要在超时前完成重入，就视为成功。

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。

JavaScript 测试模式

使用 Jest、Vitest 和 Testing Library 实施全面的测试策略，包括单元测试、集成测试和端到端测试，涵盖模拟、测试夹具和测试驱动开发。在编

下载

未完全释放 → 其他线程永远拿不到锁，极易引发死锁或饥饿
多 unlock → 运行时报错，堆栈里会明确出现 java.lang.IllegalMonitorStateException: attempt to unlock lock, not owned by current thread
建议配合 try-finally 使用，确保 unlock 执行