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