来自文档：
Condition.signalAll()的文档说明了
'唤醒所有等待的线程。 如果任何线程正在等待这种情况，那么他们都被唤醒了。每个线程必须重新获取锁，然后才能从等待返回。 “
如上所述等待的线程包括已调用
的某些重载变体的线程 Condition.await(...)，
其文档说'与此条件相关联的锁被原子释放，并且当前线程因线程调度而被禁用，并处于休眠状态直到......'
讨论的案例：
因此，假设一个线程已被禁用以进行线程调度，并在调用Condition.await(...)后处于休眠状态，并在稍后唤醒，因为另一个线程已调用Condition.signalAll()并且在返回之前与其他线程竞争重新获取锁定等待。
所以，我认为，线程必须从禁用状态唤醒（线程调度目的）并在获取锁之前竞争。
标题中的问题：
Lock.lock()的文档说明了
'如果锁不可用，则当前线程因线程调度而被禁用，并且在获取锁之前处于休眠状态。'
现在，由于在调用lock()方法的时候锁不可用，因此一个线程已被禁用以进行线程调度并处于休眠状态？
这样一个线程什么时候会从其禁用状态唤醒并参与竞争，以便它可以获得锁定？
注意：
1。提及的所有Condition个对象都是指在讨论中从同一个Lock对象获取的单个Condition对象。
2。这种情况不会出现在隐式锁定中，因为调用同步代码的所有线程都会相互阻塞并竞争锁定而不会自行禁用。
答案 0 :(得分：1)
所以，我认为，线程必须从禁用状态唤醒（线程调度目的）并在获取锁之前竞争。
正确。一些系统在重新启用锁定之前预先将锁定分配给线程，作为＆＃34;释放锁定的一部分＆＃34;处理。但更典型的设计只是重新安排线程并让它竞争锁定。
现在，由于锁定在调用lock（）方法的瞬间不可用，因此为了线程调度目的而被禁用的线程怎么办呢？
这样的线程什么时候会从禁用状态唤醒并竞争，以便它可以获得锁？
通常，只要持有锁的线程释放它。典型的实现是线程在禁用自身之前将自己添加到等待锁的线程列表中。释放锁定后，释放锁定的线程将检查该列表，并重新启用列表中的至少一个线程。
答案 1 :(得分：0)
线程因调度目的而被禁用，这意味着它不会获得CPU时间，但它仍在等待获取锁定。因此，它不是RUNNABLE状态，而是处于WAITING状态。
当锁被释放时，线程有可能获取它或留在WAITING，并重复该过程。 Condition似乎与此问题无关。