getQueueLength() 返回当前AQS同步队列中等待获取锁的线程数，不包括已持锁、tryLock失败未入队及已出队线程，是动态快照，适用于监控诊断而非同步控制。
reentrantlock 的 getqueuelength() 可以实时反映正在排队等待获取锁的线程数量，但需注意它不包含已持有锁的线程，也不保证绝对精确（因竞态条件），适合用于监控和诊断，而非同步逻辑控制。
理解 getQueueLength() 的实际含义
该方法返回的是当前在 AQS 同步队列中等待获取该锁的线程数（即调用了 lock() 但尚未成功获取锁、处于阻塞或自旋等待状态的线程）。它不包括：
- 已成功获得锁并正在执行临界区代码的线程；
- 调用
tryLock()失败后直接返回的线程（未入队）； - 被中断或超时后退出等待的线程（已出队，不计入）。
由于队列状态在多线程下是动态变化的，该值是某一时刻的快照，仅适用于趋势观察或告警阈值判断。
基础用法：打印与日志记录
在关键锁操作前后或定时任务中调用，便于排查锁竞争瓶颈：
- 在加锁前记录等待数：
log.info("Lock queue length before acquire: {}", lock.getQueueLength()); - 在释放锁后可选记录：
log.debug("Lock released, current queue: {}", lock.getQueueLength()); - 配合 JMX 或 Prometheus 暴露为监控指标，例如封装为
lock_queue_length{lock="orderProcess"} 3。
结合 tryLock() 做轻量级竞争感知
若希望避免长时间排队，可在尝试获取锁前先检查队列长度，作为是否降级或重试的参考依据：
立即学习“Java免费学习笔记（深入）”；
- 当
lock.getQueueLength() > 10且!lock.tryLock(100, TimeUnit.MILLISECONDS)，可选择返回失败、走异步流程或返回限流响应； - 注意：不能仅依赖
getQueueLength()做决策，必须配合tryLock()或lockInterruptibly()实际尝试，否则可能误判。
注意事项与常见误区
使用时需警惕以下几点：
- 公平锁（
new ReentrantLock(true)）下队列长度更稳定；非公平锁下该值可能偏小，因为新线程可能“插队”成功； - 该方法本身是线程安全的，但频繁调用（如每毫秒一次）会带来一定性能开销；
- 不要用它实现自定义调度逻辑（如“只允许最多5个线程排队”），AQS 不提供修改队列的能力，应通过限流器（如 Semaphore）或外部协调机制实现。
