java - 为什么 ThreadPoolExecutor$Worker 扩展 AbstractQueuedSynchronizer

Question

我知道一些关于 AbstractQueuedSynchronizer 的细节。它是一个用于创建状态依赖类或同步器的框架。但是我没有得到在 ThreadPoolExecutor 的 Worker 中扩展此类的意义。

private final class Worker extends AbstractQueuedSynchronizer implements Runnable

从 Worker 类的签名可以推断出以下内容:

1. 提交新的 Runnable/Callable 任务时，会创建一个新的 Worker 对象。

2. 一个新的Worker对象可以认为是一个新的线程。

3. addWorker() 方法将添加新的 worker(或只是一个任务)并调用自身 worker.start() 来启动线程。

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

5. run() Worker类的方法内部调用runWorker(this)

   公共(public)无效运行(){ 运行 worker (这个)；

6. runWorker() 执行如下所示的实际任务:

   void runWorker(Worker w) {
尝试 {
w.lock();
w.firstTask.run()
} 最后 {
w.解锁()；
}
}

AQS 仅用于runWorker() 方法的这种锁定和解锁。我们不能在这里采用 ReentrantLock 并使 Worker 类保持简单吗？

类(class)还提供了与此相关的文档，但我无法理解:

This class opportunistically extends AbstractQueuedSynchronizer to simplify acquiring and releasing a lock surrounding each task execution. This protects against interrupts that are intended to wake up a worker thread waiting for a task from instead interrupting a task being run. We implement a simple non-reentrant mutual exclusion lock rather than use ReentrantLock because we do not want worker tasks to be able to reacquire the lock when they invoke pool control methods like setCorePoolSize.

请帮忙

Answer 1

关于您问题的答案在 javadoc 的引用中您发布的内容:

We implement a simple non-reentrant mutual exclusion lock rather than use ReentrantLock because we do not want worker tasks to be able to reacquire the lock when they invoke pool control methods like setCorePoolSize.

那是因为可能正在等待任务的线程未被锁定，即 tryLock 为它们返回 true。如果此处使用 ReentrantLock，在这种情况下会发生什么情况:那么可能会发生以下一系列操作:

setCorePoolSize->interruptIdleWorkers->tryLock()(此处成功!)-> Thread.interrupt (这个 worker 的线程)

这会导致 worker 自身中断。