多态机制本身不提升吞吐，其价值在于与AQS结合实现锁调度策略可插拔、状态语义可扩展、竞争路径可分层；通过接口定义CheckoutPolicy、继承细化state语义、组合Wrapper增强能力，解耦锁行为与业务逻辑。
多态机制本身不提升吞吐，它和AQS独占锁排队机制结合的价值，在于让锁的调度策略可插拔、状态语义可扩展、竞争路径可分层——从而避免因锁实现固化、响应逻辑僵化、资源粒度粗放导致的吞吐瓶颈。
用接口+实现多态解耦锁行为与业务逻辑
不要在结算服务里直接 new ReentrantLock() 或硬编码 synchronized。定义清晰的同步策略接口，例如：
-
CheckoutPolicy：声明
acquire(long orderId)、tryAcquire(long orderId, long timeoutNs)、release(long orderId) - 同一接口，多种实现：本地用户级 AQS 锁、分片 Redis 分布式锁、无锁乐观重试策略，都实现该接口
- 业务代码只依赖 CheckoutPolicy，压测发现单点锁成瓶颈时，只需替换 Bean 实现，无需改一行业务逻辑
用运行时多态动态选择锁竞争强度
不同请求场景对延迟和吞吐敏感度不同，可通过策略工厂在运行时返回适配的 AQS 实现：
- 高优先级订单（如 VIP）→ 返回公平模式 AQS 子类，保证唤醒顺序，降低尾部延迟
- 批量导入订单 → 返回非公平 + 自旋退避 AQS 子类，减少 park/unpark 开销，提升吞吐
- 低频管理后台操作 → 返回轻量 CAS + LockSupport.parkNanos() 实现，跳过 AQS 队列封装，规避节点内存分配与链表维护成本
用继承多态细化 state 语义与排队维度
AQS 的 state 是整型变量，但它的含义由子类决定；多态允许你为不同场景赋予完全不同的语义，直接影响排队效率：
- UserScopedLock：state 表示“当前用户是否正在结算”，每个 userId 对应独立实例，排队队列极短，无跨用户争用
- InventoryGuardLock：state 表示“剩余库存校验许可数”，支持有限并发（如最多 3 个线程同时校验），用 tryAcquireShared 控制共享粒度
- TimeoutAwareLock：state 不仅存持有状态，还嵌入纳秒级超时戳（高位存时间，低位存状态），在 acquireQueued 中提前判断是否已超时，避免无效排队
用组合多态叠加非侵入式增强能力
拒绝把所有功能塞进一个庞大的 AQS 子类。通过包装器（Wrapper）组合，每层只专注一件事：
- MetricsWrapper：记录每次 acquire 耗时、排队长度、唤醒延迟，不影响核心逻辑
- BackoffWrapper：在 park 前根据排队位置计算退避时间（越靠后等得越久），调用 parkNanos() 精准挂起
- DeadlineWrapper：统一拦截 tryAcquire，将业务传入的毫秒级 deadline 转为 nanoTime 剩余值，交由 AQS 原生 acquireNanos 处理
所有 Wrapper 都实现 CheckoutPolicy 接口，堆叠顺序即增强顺序，调试时可任意移除某层验证影响。
