exclusiveOwnerThread字段由AQS父类定义，为transient volatile Thread类型，仅用于独占模式，记录当前锁持有者，加锁成功后通过setExclusiveOwnerThread设置，volatile保障其可见性，不参与抢锁判断或阻塞控制。

加锁成功后，AQS 通过 exclusiveOwnerThread 字段明确记录当前持有锁的线程，这是实现独占语义和可重入性的关键一步。

exclusiveOwnerThread 的定位与作用

该字段定义在 AQS 的父类 AbstractOwnableSynchronizer 中，类型为 Thread，被声明为 transient volatile。它不参与序列化，且保证多线程读写时的可见性。

• 它只在独占模式下使用（如 ReentrantLock），共享模式（如 Semaphore、CountDownLatch）不依赖它
• 它的核心职责不是“判断能否加锁”，而是“确认谁已加锁”——即作为锁归属的事实来源
• 当 state > 0 但 exclusiveOwnerThread == null，说明状态异常；反之，exclusiveOwnerThread != null 必然对应 state ≥ 1

加锁成功时如何设置该字段

在 tryAcquire 方法返回 true 后，AQS 的 acquire 模板逻辑会调用 setExclusiveOwnerThread(currentThread)，完成赋值。

• 对 ReentrantLock 而言，非公平锁在 CAS 抢到 state=0→1 后立即设置；公平锁则先检查队列是否为空，再执行同样流程
• 如果是重入场景（即当前线程已是持有者），不会重复设置 exclusiveOwnerThread，而是仅递增 state
• 该赋值操作发生在用户线程已获得锁资源之后、进入临界区之前，确保任何后续对 isHeldExclusively() 或 getOwner() 的调用都能立刻反映真实持有者

为什么必须是 volatile？

volatile 保障了其他线程能及时看到 exclusiveOwnerThread 的变更，尤其在释放锁唤醒后继节点时至关重要：

• 前驱节点释放锁后将 exclusiveOwnerThread 置为 null，后继节点在 shouldParkAfterFailedAcquire 中检查前驱状态时，需依赖该字段的可见性来决定是否继续尝试获取
• 调试或监控工具（如 jstack、JMX）读取锁持有者信息，也依赖此字段的实时可见性
• 它不保证原子性（比如不能靠它实现“比较并设置”），但配合 state 的 CAS，共同构成线程安全的锁归属断言基础

常见误区澄清

exclusiveOwnerThread 不是锁竞争的入口判断条件，也不是加锁成功的充分条件：

• 它不会阻止其他线程发起 tryAcquire；state 才是 CAS 操作的目标，才是抢锁成败的直接依据
• 它不负责线程阻塞——阻塞由 LockSupport.park() 完成，而唤醒信号传递依赖 Node.waitStatus 和前驱节点行为
• 它不维护重入次数，重入计数完全由 state 承担；exclusiveOwnerThread 只标识“是谁”，state 标识“重入几次”