ReentrantLock 的 state 是 volatile 修饰的整型字段，依赖 CAS 原子操作实现无锁并发控制，同时表征锁空闲/持有状态与重入计数，并与 exclusiveOwnerThread 和 AQS 队列协同完成线程竞争管理。
ReentrantLock 内部的 state 是一个用 volatile 修饰的整型字段，它不靠 synchronized 或 monitor 锁保护，而是完全依赖 CAS（Compare-And-Swap）原子操作 实现多线程竞争下的安全更新。
state 的核心作用
它同时承载两个关键语义：
- 锁持有状态：state == 0 表示锁空闲；state > 0 表示已被某线程持有；
- 重入计数：每次同一线程成功 lock()，state +1；每次 unlock()，state -1；只有当 state 减至 0，锁才真正释放，其他线程才可能获取。
CAS 是竞争控制的核心
当线程调用 lock() 时，底层会尝试用 CAS 将 state 从 0 改为 1：
- 如果成功 → 当前线程获得锁，设置 owner thread，并返回；
- 如果失败（state 已非 0）→ 说明锁被占用，线程进入 AQS 队列排队等待；
- 后续唤醒时，队首线程仍通过 CAS 尝试抢锁，而非直接分配 —— 这就是“非公平”的默认行为；若启用公平模式，则先检查队列是否为空、自己是否队首，再决定是否 CAS。
为什么不用 synchronized 保护 state？
因为 synchronized 本身就需要锁，而 ReentrantLock 正是要实现“锁的锁”。state 必须是无锁（lock-free）的共享变量，才能避免自循环依赖。CAS 提供了硬件级原子性，配合 volatile 保证可见性，构成整个锁机制的基石。
立即学习“Java免费学习笔记（深入）”；
state 和线程绑定靠 exclusiveOwnerThread
仅靠 state 无法区分是谁持有的锁。ReentrantLock 还维护一个 exclusiveOwnerThread 字段（继承自 AbstractOwnableSynchronizer）：
- 首次获取锁时，CAS 成功后立即将当前线程写入该字段；
- 重入时，只增 state，不改 owner；
- unlock 时，只减 state；仅当 state == 0 才清空 exclusiveOwnerThread；
- 这样，
isHeldByCurrentThread()等方法才能准确判断归属。
本质上，state + exclusiveOwnerThread + AQS 队列三者协作，让多个线程在无内置锁的前提下，安全、高效、可定制地竞争同一把锁。
