ReentrantLock 的锁重入不更新持有线程，而是通过 AQS 的 exclusiveOwnerThread 字段记录首次获取锁的线程，并仅递增 state 值来标识重入次数；state 减至 0 时才清空 exclusiveOwnerThread。
ReentrantLock 的锁重入逻辑中，持有线程本身不会被“更新”，而是通过内部的 AQS（AbstractQueuedSynchronizer） 状态和线程标识共同维护重入关系：同一个线程多次获取锁时，持有线程字段保持不变，仅递增同步状态（state）值，并记录重入次数。
持有线程由 firstWriterThread 或 owner 字段记录
ReentrantLock 使用 AQS 的 exclusiveOwnerThread 字段（定义在 AbstractOwnableSynchronizer 中）来保存当前持有锁的线程引用。该字段在首次成功加锁时被设为当前线程，之后只要仍是同一线程重入，就不再修改该字段——它始终指向最初获得锁的那个线程（即持有者），而非“最新”或“当前执行”的线程。
重入靠 state 计数，不改变持有线程
每次重入时，AQS 的 state 值加 1；释放锁时减 1。只有当 state 减至 0 时，才真正释放锁，并将 exclusiveOwnerThread 设为 null。这意味着：
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- state = 1 → 首次获取锁，exclusiveOwnerThread 被设为当前线程
- state = 2 → 同一线程再次 lock()，exclusiveOwnerThread 不变，仅 state++
- state = 0 → 最后一次 unlock() 完成，exclusiveOwnerThread 清空
非公平锁与公平锁在此逻辑上一致
无论是 FairSync 还是 NonfairSync，重入判断都依赖 getExclusiveOwnerThread() == currentThread。只要匹配，就跳过排队、直接 state++。这个判断只读取 exclusiveOwnerThread，不写入也不更新它。
立即学习“Java免费学习笔记（深入）”；
注意：不可跨线程重入
如果不同线程尝试对同一把已持有的 ReentrantLock 调用 lock()，即使 state > 0，也会因线程不匹配而触发 AQS 的阻塞逻辑（入队等待）。重入机制天然绑定线程身份，不是靠“更新持有者”实现，而是靠“线程身份校验 + 计数累加”协作完成。
