ReentrantLock 的重入次数由 AQS 的 volatile int state 直接记录：state==0 表示空闲，state>0 即重入计数；同一线程可多次 CAS 成功递增 state，仅当 state 减至 0 才释放锁并唤醒等待者。
state 变量怎么记录重入次数
ReentrantLock 的可重入性不是靠线程本地存储或额外 Map 实现的，而是直接复用 AQS 的 state 这个 int 类型原子变量。它不存“谁持有”，而存“持有了几次”——state == 0 表示锁空闲；state > 0 时，值就是当前持有线程的重入计数。
关键点在于：AQS 不允许任意线程修改 state，只有在 tryAcquire 中通过 CAS 成功将 state 从 0 改为 1 时，才记录 exclusiveOwnerThread = currentThread；后续同一线程再次调用 lock()，tryAcquire 会先比对 getExclusiveOwnerThread() == currentThread，成立则直接 setState(state + 1)，跳过竞争逻辑。
-
state是 volatile int，所有读写都带内存语义，无需额外同步 - 每次
lock()对应一次state++，每次unlock()对应一次state-- - 只有当
state减到 0 时，AQS 才唤醒同步队列里的第一个等待节点
为什么不能直接用 ThreadLocal 存重入次数
用 ThreadLocal<integer></integer> 看似也能实现“本线程计数”，但它无法解决锁释放的原子判定问题：AQS 必须在 state == 0 时才真正释放锁并通知其他线程，而 ThreadLocal 的值对其他线程不可见，也无法参与 CAS 竞争判断。
更实际的问题是——如果仅靠 ThreadLocal 记录，那当线程 A 持有锁后中断自己、或在 finally 外抛异常未 unlock，ThreadLocal 值可能残留，但锁其实已丢失（无人能释放），导致永久死锁。而 state 和 exclusiveOwnerThread 的绑定由 AQS 在 acquire/release 全流程中严格维护，状态始终一致。
- AQS 的
state+exclusiveOwnerThread是一个不可分割的状态对 -
ThreadLocal无法参与跨线程可见性与原子更新，只适合纯单线程上下文缓存 - 公平锁模式下，还要依赖
state值判断是否已有等待者，ThreadLocal完全无此能力
非公平锁下 state 修改可能被“插队”吗
不会。非公平指的是“新线程尝试获取锁时，可以和等待队列头节点竞争”，但这个“尝试”本身仍需通过 CAS 修改 state。也就是说：state 的修改永远是原子的，不存在中间态；所谓“插队”，只是新线程在队列外多了一次 CAS 尝试机会，失败后仍会进队列。
例如：当前 state == 2（线程 A 重入两次），线程 B 调用 lock() 时发现 state != 0，且持有者不是自己，就会走 acquireQueued 流程入队；此时线程 C 来了，它也会先 CAS 尝试把 state 从 2 改成 3？不，它只能尝试从 0 改成 1 —— 因为只有 state == 0 才表示锁空闲，才允许抢占。
- 非公平 ≠ 可以随意修改别人的
state值 - 所有线程对
state的修改，都必须满足 “当前为 0 才能设为 1” 或 “当前为自己持有才允许 +1” - CAS 失败后，非公平锁不会重试，而是直接入队；公平锁则跳过这步 CAS，直接入队
调试时怎么看当前 state 和持有线程
没有公开 API 直接读取 state，但可以通过反射临时观察（仅限调试，勿用于生产）：
Field stateField = AbstractQueuedSynchronizer.class.getDeclaredField("state");
stateField.setAccessible(true);
int currentState = stateField.getInt(lock.getSync()); // lock 是 ReentrantLock 实例
持有线程可通过 lock.getOwner() 获取（注意：该方法返回 null 并不代表没锁，可能只是当前无竞争、AQS 尚未设置 exclusiveOwnerThread；最准的方式仍是看 state != 0 且 getOwner() != null）。
-
ReentrantLock.isLocked()底层就是检查state != 0 -
ReentrantLock.getHoldCount()返回的是getSync().getCount()，本质就是读state - 不要依赖
getOwner()判断锁是否被占用，它有竞态窗口；isLocked()更可靠
state 不仅承载重入计数，还隐式承担了“锁是否被占用”的布尔语义。这种一值双用的设计让 AQS 极其紧凑，但也意味着任何绕过 lock()/unlock() 直接操作 state 的行为都会破坏整个机制——比如在 finally 块里漏掉 unlock()，state 就卡在非零值，别的线程永远等不到它归零。 
