问在锁状态下发送线程信号

EN

请参见以下对您的问题的回答：

1.等待线程按FIFO顺序发送信号。

当我们调用await()条件方法时，线程进入等待状态，上面的语句引用这些处于等待状态的线程是如何发出信号的。因此，如果线程T1在T2之前进入等待状态，那么T1将在T2之前发出信号。

2.从等待方法返回的线程的锁重新获取顺序与最初获取锁的线程相同，这是默认情况下未指定的锁，但对于公平锁而言，则倾向于等待时间最长的线程。

作为上述语句的延续，当等待线程被发出信号时，它倾向于重新创建锁。虽然上面的声明说T1将在T2之前发出信号，但是当涉及到查询锁时，重新获取的顺序使用了lock定义的概念。因此，这取决于Lock对象是如何创建的。在创建锁时，您可能指定了一个公平参数：

ReentrantLock(boolean fair)

如果是，则使用该参数，如果不使用，则会发生默认的锁行为，您可以在此ReentrantLock上读取更多关于链接锁的信息。

对这些说法可以有更多的解释，只是尽量详细说明我在这里的理解。希望能澄清。

干杯!！

只要锁的创建是公平的还是不公平的，等待线程以FIFO顺序发出信号的事实是完全不相关的，不是吗？因为无论如何，它们是否被构造，公平与否，决定了它们是如何排队的。

我认为这是相关的。

考虑一个场景: T1和T2在C条件下等待( T1等待的时间比T2长)，T3在监视器中运行，T4正在等待初始的锁获取。T3向C发出信号，并让监视器释放锁。让我们假设没有虚假的唤醒发生。

如果锁是公平的，T4肯定会在T1之前获得锁，但是等待线程按FIFO顺序发出信号的事实将保证T1在T2之前获得锁。

此外，如果锁是不公平的，我们不能说哪个线程将首先在T1和T4之间获取锁，但是，等待线程以FIFO顺序发出信号这一事实再次保证了T1将在T2之前获得锁，前提是在T1获得该锁之前不会出现其他信号(例如，在T1负责下一个信令时)。

我认为源代码可以为我们提供更多关于works.ReentrantLock.newCondition()如何在AbstractQueuedSynchronizer.Here中返回ConditionObject的线索--源代码链接AQS源代码。

1.等待线程按FIFO顺序发送信号。

AbstractQueuedSynchronizer.中有两个队列

一个是等待锁(只需调用它锁定等待队列)，您将在AbstractQueuedSynchronizer's类定义中看到两个易失性变量head和尾巴，并且公平性参数将影响该队列的behavior.When you --新的公平的，并调用获取，AQS将调用FairSync的tryAcquiree 224来检查当前线程是否是锁等待队列中等待的第一个线程，请参见hasQueuedPredecessors.。

另一个队列是ConditionObject，定义中的信号队列--您将看到调用了两个变量firstWaiter和lastWaiter.When firstWaiter，一个节点将添加到队列的尾部，当信号被调用时，从头发出的节点将被解除排队，并添加到锁等待队列中以重新获取锁等待队列中的lock.Add，这并不意味着它将被唤醒，但在信号之后将调用一个Lock.unlock()，这将唤醒等待者，请参阅unparkSuccessor.

2.从等待方法返回的线程的锁重新获取顺序与最初获取锁的线程相同，这是默认情况下未指定的锁，但对于公平锁而言，则倾向于等待时间最长的线程。

从等待方法中醒来并不意味着要持有锁，它会调用重新获取锁，并可能再次停放。根据我的理解，最初获取锁的顺序与调用acquireQueued，等待的顺序相同，因此与调用 What 的顺序一样，令我感到困惑的是，但对于等待时间最长的线程来说，公平的锁有利于等待时间最长的线程。在我看来，当从等待中醒来时，它将是锁等待队列中的第一个线程，当调用acquireQueued并检查p == head &tryAcquire时，锁是否正常。

希望这能帮上忙，如果我错了就让我来吧。