reentrantlock 通过 aqs 的 state 字段记录持有锁次数实现可重入，每次 lock() 加 1、unlock() 减 1，仅当 state=0 才真正释放；公平性由 tryacquire 是否检查 hasqueuedpredecessors() 决定。
ReentrantLock 底层怎么靠 AQS 实现可重入
AQS（AbstractQueuedSynchronizer）不是直接被调用的工具类，而是通过子类复写 tryAcquire 和 tryRelease 来定义“加锁”和“解锁”的语义。ReentrantLock 的公平/非公平模式，本质就是这两个方法的具体实现差异。
可重入的关键在于：AQS 的 state 字段不只表示“有没有锁”，而是记录当前线程持有锁的次数。每次 lock() 成功，state 加 1；每次 unlock()，state 减 1；减到 0 才真正释放锁。
- 非公平模式下，
tryAcquire会先用 CAS 尝试抢锁（不管队列里有没有人等着），抢不到再进队列 - 公平模式下，
tryAcquire会先查hasQueuedPredecessors()—— 如果队列非空，就直接放弃抢锁，老老实实排队 - 注意：
Thread.currentThread()必须和 AQS 内部保存的exclusiveOwnerThread一致，才能做重入判断；否则就算state > 0也进不了重入逻辑
Semaphore 的 permits 是怎么被 AQS 管理的
Semaphore 不是“锁某个资源”，而是维护一个可用许可数（permits）。它的 AQS 子类把 state 直接当作剩余 permits 数来用，acquire(1) 对应 state -= 1，release(1) 对应 state += 1。
和 ReentrantLock 最大区别是：Semaphore 不绑定线程。acquire() 成功后，任何线程都能调用 release() —— 这意味着它不能靠 exclusiveOwnerThread 判断归属，全靠 state 计数本身。
立即学习“Java免费学习笔记（深入）”；
- 构造时传
true表示公平模式，会走 AQS 的hasQueuedPredecessors()检查，避免新请求插队 - 调用
acquireUninterruptibly()会忽略中断，但底层仍是基于 AQS 的acquire()流程，只是把 Thread.interrupted() 清掉了 - 如果
permits = 0时多个线程同时acquire()，它们会按顺序挂进 AQS 的 CLH 队列，等后续release()唤醒
为什么 new ReentrantLock() 默认是非公平的
性能。非公平模式允许刚释放锁的线程立刻再次抢到锁（即“锁重入”或“锁复用”），避免了进出队列的开销和上下文切换。在多数竞争不激烈、线程执行时间短的场景下，吞吐量更高。
- 公平模式虽然能保证等待时间长的线程优先获得锁，但每次加锁都要检查队列，且唤醒时还要做一次 CAS，平均延迟更高
- 即使开了公平模式，也不能完全避免“插队”：比如一个线程在
tryAcquire返回 false 后、进入队列前，另一个线程刚好释放锁并触发唤醒，这时新来的请求仍可能抢先获取 - 别指望公平模式解决死锁或活锁——它只管排队顺序，不管业务逻辑是否形成循环等待
AQS 的 waitStatus 字段容易被误解的点
waitStatus 是 AQS Node 里的一个 volatile int 字段，用于标记节点状态，不是“线程状态”。常见值有 0（初始化）、CANCELLED（1）、SIGNAL（-1）、CONDITION（-2）、PROPAGATE（-3）。其中 SIGNAL 最关键：它表示“当前节点的后继节点已被阻塞，需要我释放锁时通知它”。
- 这个字段不是由线程自己设的，而是前驱节点在 park 前设的——也就是说，“通知谁”是由前驱决定的，不是自己声明的
-
CANCELLED节点不会被唤醒，也不会参与唤醒传播，但会留在队列里，直到被前驱或后继“跳过” - 别手动改
waitStatus：AQS 内部用 CAS 更新，外部修改既无效也不安全
tryAcquire 和 tryRelease。 
