reentrantlock的公平锁与非公平锁虽非限流器，但可通过其排队机制间接削峰：非公平锁吸收瞬时脉冲，公平锁保障长尾有序，混合策略可动态切换，需配超时、拒绝及细粒度锁。
ReentrantLock 的公平锁与非公平锁本身不是限流器，不能直接“平抑流量高峰”，但它们在临界区调度中的排队行为差异，可被间接用于调节请求的实际处理节奏——核心是把锁的阻塞特性当作一种轻量级延迟注入机制，配合队列行为实现软性削峰。
用非公平锁吸收短时脉冲
非公平锁默认允许新线程“先抢后排”：锁刚释放时，新线程有较高概率通过 CAS 直接获取，零延迟通过；失败才进入 AQS FIFO 队列。这种特性天然适合应对毫秒级瞬时高峰（比如秒杀开闸、缓存穿透后批量回源）：
- 部分请求快速通行，避免所有线程立刻阻塞，缓解 CPU 和线程调度压力
- 未抢到的线程自动入队，形成隐式缓冲，把尖峰拉平为近似匀速的处理流
- 相比手动维护 BlockingQueue + 线程池，代码更简、无额外内存开销和 GC 压力
- 务必搭配超时控制，例如 tryLock(200, TimeUnit.MILLISECONDS)，防止长尾请求无限等待
用公平锁稳住长尾请求
当高峰持续数秒以上，非公平锁可能导致先排队的线程反复被插队，出现饥饿。此时启用公平锁（new ReentrantLock(true)）可强制 FIFO 调度：
- 每个调用 lock() 的线程立即登记入队位置，唤醒严格按到达顺序执行
- 最大等待时间可估算：队列长度 × 平均单次处理耗时，利于做 SLA 承诺
- 结合监控（如 getQueueLength()），当队列长度超阈值（如 > 50）时主动拒绝新请求，防雪崩
- 适用于支付确认、订单创建等用户感知强、强一致要求的链路
混合策略：运行时动态切换锁实例
ReentrantLock 的公平性在构造时固化，无法运行时修改，但可通过设计实现逻辑切换：
- 预先创建两个锁实例：一个公平锁、一个非公平锁
- 根据实时指标（如 QPS、AQS 队列长度、平均等待时长）决策使用哪个锁
- 例如：连续 3 秒队列长度 > 20 → 切换至公平锁；队列清空且稳定 5 秒 → 切回非公平锁
- 切换只需安全更新锁引用（如用 volatile 字段或 AtomicReference），老请求继续用原锁，新请求走新锁
关键注意事项
这类用法是辅助手段，不是替代专业限流器：
- 不可替代令牌桶/漏桶：ReentrantLock 不提供速率控制、突发容量配置等能力
- 不适用于跨服务或分布式场景：仅作用于单 JVM 内的线程调度
- 必须配超时与拒绝逻辑：否则可能因锁等待引发级联超时
- 避免锁粒度过大：锁住整个业务方法会放大串行化影响，应尽量缩小临界区
