tryAcquire无法实现租约机制，因其仅为无状态布尔判断函数，不支持超时控制、时间感知、自动续期及过期释放等租约核心语义。
不能直接靠重写 tryAcquire 实现租约机制 —— 它不处理超时、不感知时间、也不维护租约续期逻辑。
为什么 tryAcquire 本身无法承载租约语义
tryAcquire 是一个纯状态判断函数：它只看 state 值是否可修改（比如从 0→1 或 1→2），返回 true/false，不阻塞、不等待、不记录时间戳、不触发后台续约。租约（lease）的核心要素——有效期、自动续期、过期自动释放——全部超出它的职责边界。
-
tryAcquire被调用时，线程已进入同步器的获取流程，但尚未入队或挂起；它不接收 deadline 参数，也无法主动检查“当前锁是否已过期” - 租约必须绑定到持有者（线程 or 节点 ID），而 AQS 的
state是整数，setExclusiveOwnerThread只存Thread引用，无法存储租约到期时间或唯一节点标识 - 本地节点内租约需防止单点故障导致的脑裂（如 JVM Crash 后锁未释放），这要求租约必须带时间戳 + 独立心跳，而
tryAcquire没有执行周期或后台上下文
真正可行的租约锁结构：AQS + 外部租约管理器
高性能本地租约锁的本质是「AQS 控制并发准入」+「独立租约生命周期管理」，二者解耦：
- 用 AQS 的
state表示「当前是否有有效租约」（0 = 无，1 = 有），但不存租约细节 - 用
ConcurrentHashMap<Long, LeaseRecord>存储租约元数据：LeaseRecord包含ownerNodeId、expireTimeMs、renewDeadlineMs -
tryAcquire(long leaseMs)改为自定义方法（非 AQS 模板），内部做三件事：
① 生成本地唯一nodeId（如System.nanoTime() ^ Thread.currentThread().getId()）
② 调用租约管理器acquireIfExpiredOrAbsent(nodeId, leaseMs)（CAS 写入 + 过期检查）
③ 成功则setState(1)并setExclusiveOwnerThread(Thread.currentThread()) - 租约续期由单独的守护线程或
ScheduledExecutorService执行，定期调用renewLease(nodeId)，失败则触发release流程
关键陷阱：别在 tryRelease 里做租约清理
这是最常踩的坑：认为只要重写 tryRelease 就能安全删租约。问题在于：
- 租约可能已过期，但线程还没来得及调用
unlock()（比如 GC STW、长暂停、线程卡死） -
tryRelease仅在线程显式调用unlock()时触发，无法覆盖租约自然过期场景 - 若在
tryRelease中清理租约，又没加分布式锁或 CAS 保护，多个线程并发unlock()可能重复清理或漏清理 - 正确做法是：租约管理器自身维护一个
expireTimeMs字段，所有操作（包括tryAcquire入口、续期、后台过期扫描）都基于该字段做原子比较，tryRelease只负责 AQS 层 state 归零和 owner 清空
性能敏感点：租约检查必须无锁且 O(1)
每次 lock() / tryLock() 都要检查租约有效性，高频路径不能有锁竞争或对象分配：
- 避免在
tryAcquire变体中 newDate、System.currentTimeMillis()（可用System.nanoTime()配合启动偏移转毫秒） - 租约记录用
Unsafe或VarHandle直接更新expireTimeMs字段，避免 synchronized - 过期扫描用分段轮询（如每 100ms 扫描 1/100 的租约桶），不全量遍历
- 本地节点内无需 ZooKeeper 或 Redis，但必须用
AtomicLongFieldUpdater管理expireTimeMs，确保跨线程可见性
租约不是加在锁上的装饰，而是锁的生存前提；把时间维度硬塞进 AQS 的 state 或 tryAcquire，只会让逻辑缠绕、时序错乱、过期不可控。
