为什么ThreadPoolExecutor$Worker扩展AbstractQueuedSynchronizer

Question

我知道一些关于AbstractQueuedSynchronizer的详细信息。它是一个用于创建依赖于状态的类或同步器的框架。但我不理解在ThreadPoolExecutor的Worker中扩展这个类的意义。

private final class Worker extends AbstractQueuedSynchronizer implements Runnable

由Worker类的签名可以推断出以下内容：

>

提交新的可运行/可调用任务时，将创建一个新的工作对象。

Worker的新对象可以被视为新线程。

addWorker（）方法将添加新的worker（或只是一个任务）并在其自身中调用worker。start（）启动线程。

Worker类是非静态嵌套类，因此它可以访问ThreadPoolExecutor的所有变量

Worker类的方法在内部调用runWorker（this）

public void run（）{runWorker（this）；}

runWorker（）执行实际任务，如下所示：

空runWorker（Worker w）{try{w.lock（）；w.firstTask.run（）}最后{w.unlock (); } }

AQS仅用于runWorker（）html" target="_blank">方法的这种锁定和解锁。我们不能在这里使用ReentantLock并保持Worker类简单吗？

课程还提供了相关文档，但我无法理解：

此类机会主义地扩展了AbstractQueuedSynchronizer，以简化获取和释放围绕每个任务执行的锁的过程。这可以防止旨在唤醒等待任务的工作线程而不是中断正在运行的任务的中断。我们实现了一个简单的不可重入互斥锁，而不是使用可重入锁，因为我们不希望工作任务在调用诸如setCorePoolSize之类的池控制方法时能够重新获取锁。

请帮忙




Answer 1

您的问题答案在您发布的javadoc中：

我们实现了一个简单的不可重入互斥锁，而不是使用可重入锁，因为我们不希望工作任务在调用诸如setCorePoolSize之类的池控制方法时能够重新获取锁。

这是因为可能正在等待任务的线程表示未被锁定，即为它们返回true。如果在这里使用ReentrantLock，在这种情况下会发生什么：那么可能会有以下操作序列：

setCorePoolsize-

这将导致工作进程自身中断。