CyclicBarrier.getNumberWaiting()准确吗？

Question

我分析jdk 1.8中的代码，但在其他jdk版本中可能存在相同的问题。

在下面的代码中，让我们假设

1. = 3

CyclicBarrier(3); cb =新的CyclicBarrier

​

​

各方=3和count >= 0，因此getNumberWaiting() <= 3的返回值，但在某些情况下，超过3个线程将等待2。让我们看看CyclicBarrier中的关键代码

​

​

( a)位置2的线程A将返回0，现在在第3位置有2个线程在等待

( b)在线程A执行lock.unlock()之后，位置1的线程B获得锁(但锁不公平)，所以现在索引=2，计数= 2，它将等待在位置3，所以现在有3线程等待位置3的

( c)假设锁总是由线程从位置1处获得，所以等待线程的数量将越来越多

因此，结果是getNumberWaiting() > 3

getNumberWaiting() =(循环数)*各方-计数

Answer 1

我认为你需要多看一下“一代人”的概念。在您的场景中，线程A将调用nextGeneration()，它重置所有计数(getNumberWaiting() = 0)，并向所有当前等待者发送信号。那些侍者(现在--上一代)很快就会开始工作。

因此，在trip条件下，可能有>3个线程，但是已经有两个老服务生被指示离开，任何新的等待一个新信号。getNumberWaiting不是使用Lock.getHoldCount()计算的，所以这是可以的。