ReentrantLock 通过 hasQueuedThreads() 可判断是否有线程在同步队列中等待获取锁，getQueueLength() 返回具体等待线程数，二者均不统计 Condition 等待队列中的线程；hasWaiters() 等用于检查 Condition 队列。
ReentrantLock 本身不提供直接“检查某个线程是否在等待锁”的方法，但可以通过其关联的 Condition 或内部的 AQS 队列状态，间接判断是否有线程正阻塞在获取锁的过程中。
使用 hasQueuedThreads() 判断是否有线程在等待锁
这是最常用、最直接的方式。ReentrantLock 提供了 hasQueuedThreads() 方法，返回 true 表示当前有至少一个线程正在同步队列（AQS 的 CLH 队列）中等待获取该锁（注意：不包括因调用 Condition.await() 而进入等待队列的线程）。
- 适用于公平锁和非公平锁
- 仅反映“正在争抢锁但尚未获取成功”的线程，不包含已持有锁的线程
- 是**近似实时**的快照，多线程下可能瞬间变化，不可用于严格同步逻辑
更细粒度：getQueueLength() 获取等待线程数量
getQueueLength() 返回当前在同步队列中等待获取锁的线程数（同样不包含 Condition 等待队列中的线程）。比布尔值更具体，适合监控或日志场景。
- 返回值为
int，可能为 0、正整数，极端情况下可能为负数（表示估算不可靠，但实践中极少） - 配合
getQueuedThreads()可获取实际线程列表（开销较大，仅调试/诊断时用） - 示例：lock.getQueueLength() > 0 就等价于 lock.hasQueuedThreads()
注意：await() 等待的是 Condition，不是锁本身
如果线程调用了 condition.await()，它会被移到 Condition 的等待队列，而不是 AQS 同步队列 —— 此时 hasQueuedThreads() 和 getQueueLength() **不会统计它**。
立即学习“Java免费学习笔记（深入）”；
- 要检查 Condition 上是否有等待线程，需调用
condition.hasWaiters()或condition.getWaitQueueLength() - 一个线程只有在调用
lock.lock()（或tryLock()失败）且未获得锁时，才会进入 ReentrantLock 的同步队列
不推荐：通过 Thread.holdsLock() 或 synchronized 对比判断
Thread.holdsLock() 只能查当前线程是否持有某个 synchronized 监视器，对 ReentrantLock 完全无效；也不能用它反推其他线程是否在等待。
- ReentrantLock 是显式锁，与 JVM 内置锁机制分离，没有通用的跨锁状态查询接口
- 试图遍历所有线程检查其栈帧是否含
lock.lock()调用，既不可靠也严重破坏封装性，生产环境禁用
