getQueueLength() 返回当前同步队列中等待线程的估算数量，仅统计已阻塞的WAITING/BLOCKED线程，非精确值，适用于监控告警而非同步控制；公平锁下更稳定，非公平锁下数值波动大，调用无需持锁。
ReentrantLock 的 getQueueLength() 方法可以实时获取当前正在等待获取该锁的线程数量，但它只统计“已被阻塞、进入同步队列等待”的线程，不包括刚调用 lock() 但尚未被阻塞的线程（比如刚竞争失败、正准备入队的瞬态线程），也不包括已持有锁的线程。它是一个**估算值，非强实时精确计数**，适用于监控、告警或轻量级自适应调控，不能用于同步逻辑判断。
理解 getQueueLength() 的适用边界
该方法返回的是 AQS 同步队列（CLH 队列）中处于 WAITING 或 BLOCKED 状态的节点数，前提是锁是公平模式（new ReentrantLock(true)）才严格按 FIFO 入队；非公平模式下，新线程可能插队成功，导致队列长度忽高忽低，数值波动更大。
- 公平锁：队列长度更稳定，能较真实反映排队压力
- 非公平锁：队列长度偏低（因插队频繁），但仍有参考价值——持续 >0 说明已有线程在排队
- 调用时无需持有锁，可安全在监控线程或健康检查接口中使用
典型监控与响应场景
将 getQueueLength() 作为轻量级水位信号，嵌入运维可观测性链路：
- 定时采集并上报到 Prometheus：如
reentrant_lock_queue_length{lock="orderProcess"} 3 - 配置告警规则：连续 5 次采样 >10，触发“锁竞争加剧”告警
- 配合日志打点：当
getQueueLength() > 5时，记录一次 warn 日志，附带当前线程堆栈（有助于定位热点锁）
避免常见误用
这个值不能替代同步控制逻辑：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
- ❌ 不要用它做“if (lock.getQueueLength() == 0) then lock()”——竞态存在，条件成立瞬间可能已有新线程入队
- ❌ 不要基于它实现自定义排队策略（如跳过排队直接失败）——AQS 内部状态复杂，绕过 lock/unlock 易导致死锁或状态不一致
- ✅ 正确姿势：仅用于观察、诊断、限流兜底（例如结合 Sentinel，在队列长度持续超标时自动降级该业务路径）
配合 tryLock 做有界等待的实用组合
若需对排队深度敏感的业务逻辑（如高优先级任务快速抢占），可用 tryLock(timeout, unit) + getQueueLength() 协同判断：
if (lock.tryLock(100, TimeUnit.MILLISECONDS)) {
try {
// 执行临界区
} finally {
lock.unlock();
}
} else if (lock.getQueueLength() > 20) {
throw new BusyException("锁排队过载，拒绝请求");
} else {
// 可选：降级为异步处理或重试
}
注意：getQueueLength() 在 tryLock 失败后立即调用，比单独轮询更贴近真实排队状态，但仍属近似判断。
