AQS中独占模式靠tryAcquire/tryRelease控制锁获取与释放，共享模式靠tryAcquireShared（返回负数失败、0成功不传播、正数成功并传播）和releaseShared实现唤醒传播，二者共用队列但行为不同，需严格区分模式使用。
独占模式下，tryAcquire 和 tryRelease 是关键入口
如果你在写一个类似 ReentrantLock 的自定义锁，必须重写 tryAcquire 和 tryRelease —— 这两个方法决定了“谁能在当前状态拿到锁”和“释放后是否真能唤醒别人”。AQS 不管你逻辑怎么写，只认返回值：tryAcquire 返回 true 才算抢锁成功，false 就进队列等待。
- 常见错误：在
tryAcquire里没检查重入（比如用getState() == 0判空，但没处理当前线程已持有锁的情况），导致可重入语义失效 - 参数
arg含义由你定义，比如是“加锁次数”或“资源配额”，但必须和tryRelease中的arg对齐，否则state值会错乱 - 不要在
tryAcquire里阻塞或 sleep，它必须快速返回；阻塞逻辑由 AQS 自动完成（进队 + park）
共享模式下，tryAcquireShared 的返回值有特殊含义
tryAcquireShared 不是布尔值，而是返回一个 int：负数表示失败，0 表示成功但不传播唤醒，正数表示成功且应继续唤醒后继节点。这个设计直接决定了“唤醒链”是否启动 —— 比如 Semaphore 许可够用时返回 1，就会触发 doReleaseShared 连续唤醒多个等待者。
- 容易踩的坑：返回 0 而非正数，结果只有第一个等待线程被唤醒，其余卡死 —— 看似获取成功，实则没触发传播
- 共享模式下
releaseShared不保证唤醒全部等待者，它只负责“尝试传播”，真正能否全唤醒，取决于每个tryAcquireShared是否返回正值 - 如果你实现的是“读多写少”的场景（如
ReadWriteLock），要注意读锁获取不能阻塞写锁的排队，这需要在shouldParkAfterFailedAcquire或acquireQueued中做额外判断
两种模式共用同一队列，但唤醒行为截然不同
独占模式释放锁后调用 unparkSuccessor，只唤醒队列里第一个有效后继；共享模式调用 doReleaseShared，会反复尝试唤醒、设头、再传播，直到遇到一个 tryAcquireShared 返回负数或队列尾部。
- 性能影响：共享模式一次
releaseShared可能引发多次 CAS 和多次 unpark，高并发下注意避免过度唤醒（比如用PROPAGATE状态做优化） - 调试线索：如果发现多个线程始终只唤醒一个，先查
tryAcquireShared是否返回了 0 而非 >0；如果唤醒太多导致 CPU 飙高，检查是否漏了对state的边界控制（比如许可数溢出） - Node 的
nextWaiter字段在共享模式下固定为Node.SHARED，这是 AQS 区分模式的底层标记，别手动改它
子类不该同时支持两种模式，除非像 ReadWriteLock 那样明确分离语义
AQS 允许子类同时实现独占和共享方法，但绝大多数情况下这是危险的。比如你在一个同步器里既重写了 tryAcquire 又重写了 tryAcquireShared，却没严格隔离使用路径，就可能让读操作误走独占流程，或写操作被当成共享请求放行。
- 典型反例：自己封装一个“带超时的信号量”，却把
acquire（独占）和acquireShared（共享）混用，结果超时逻辑只在独占路径生效，共享路径永远不响应中断 - 正确做法：按用途选一种模式，然后彻底屏蔽另一种。例如只做限流就用共享模式，只做互斥就用独占模式；若真要读写分离，像
ReentrantReadWriteLock那样拆成两个内部同步器更安全 - 序列化时
state是唯一保存的字段，如果两种模式共用同一个state含义（比如既表示锁重入次数又表示剩余许可数），反序列化后状态语义就崩了
