线程池执行器#execute。如何重用正在运行的线程？

Question

多年来我一直使用 ThreadPoolExecutors，其中一个主要原因 - 由于并行性和“准备就绪”线程（虽然还有其他线程），它旨在“更快”处理许多请求。

现在我只关注以前众所周知的内部设计。
这是来自 java 8 ThreadPoolExecutor 的 sn-p：

public void execute(Runnable command) {
    ...
    /*
     * Proceed in 3 steps:
     *
     * 1. If fewer than corePoolSize threads are running, try to
     * start a new thread with the given command as its first
     * task.  The call to addWorker atomically checks runState and
     * workerCount, and so prevents false alarms that would add
     * threads when it shouldn't, by returning false.
     */
    ...
    int c = ctl.get();
    if (workerCountOf(c) < corePoolSize) {
        if (addWorker(command, true))
            return;
        c = ctl.get();
    }
...

我对这第一步很感兴趣，因为在大多数情况下，您不希望线程轮询执行器将“未处理的请求”存储在内部队列中，最好将它们留在外部输入 Kafka 主题/JMS 队列等中。因此，我通常将面向性能/并行性的执行器设计为具有零内部容量和“调用者运行拒绝策略”。您选择了一些合理的大量并行线程和核心池超时，而不是吓到其他人并显示价值有多大;)。我不使用内部队列，我希望任务越早开始处理越好，因此它已成为“固定线程池执行器”。因此，在大多数情况下，我处于方法逻辑的“第一步”之下。

问题来了：它真的不会“重用”现有线程，而是每次“低于核心大小”时都会创建新线程（大多数情况下）吗？ “只有在所有其他人都很忙时才添加新的核心线程”而不是“当我们有机会在另一个线程创建上吸一会时”不是更好吗？我错过了什么吗？

Answer 1

doc 描述了 corePoolSize、maxPoolSize 和任务队列之间的关系，以及提交任务时会发生什么。

...但每次“低于核心大小...”时都会创建一个新的 [线程]

是的。来自文档：

在方法execute(Runnable)中提交新任务时，更少 比 corePoolSize 线程正在运行，创建一个新线程 处理请求，即使其他工作线程处于空闲状态。

只有在其他人都忙的时候才添加新的核心线程不是更好吗……

由于您不想使用内部队列，这似乎是合理的。所以将 corePoolSize 和 maxPoolSize 设置为相同。一旦创建线程的加速完成，就不会再创建了。

但是，如果外部队列的增长速度快于处理速度，则使用 CallerRunsPolicy 似乎会损害性能。

Answer 2

问题是：真的是这样，它不会“重用”现有线程，而是每次“低于核心大小”时都会创建新线程（大多数情况）？

是的，这就是记录和编写代码的方式。

我错过了什么吗？

是的，我认为您错过了“核心”线程的全部意义。在Executors docs 中定义的核心线程是：

... threads to keep in the pool, even if they are idle.

这就是定义。线程启动是一个重要的过程，因此如果池中有 10 个核心线程，则对池的前 10 个请求每个都会启动一个线程，直到所有核心线程都处于活动状态。这会将启动负载分散到前 X 个请求中。这不是关于完成任务，而是关于初始化 TPE 和分散线程创建负载。如果您不希望出现这种情况，可以致电 prestartAllCoreThreads()。

核心线程的全部目的是让已经启动并运行的线程可以立即处理任务。如果我们必须在每次需要时启动一个线程，就会有不必要的资源分配时间和线程启动/停止开销，占用计算和操作系统资源。如果您不想要核心线程，那么您可以让它们超时并支付启动时间。

多年来我一直使用 ThreadPoolExecutors，其中一个主要原因 - 它旨在“更快”处理许多请求，因为它具有并行性和“准备就绪”线程（不过还有其他线程）。

TPE 不一定“更快”。我们使用它是因为手动管理多个线程并与之通信很难且容易出错。这就是 TPE 代码如此强大的原因。是操作系统线程为我们提供了并行性。

我不使用内部队列，我希望任务越早开始处理越好，

线程程序的重点是最大化吞吐量。如果您在 4 核系统上运行 100 个线程并且任务是 CPU 密集型的，那么您将为增加的上下文切换付出代价，并且处理大量请求的总时间将会减少。您的应用程序也很可能与其他程序竞争服务器上的资源，如果有 100 多个作业尝试同时在线程池中运行，您不希望它慢到爬行。

限制您的核心线程（即不使它们成为“合理的大数量”）的全部意义在于有一个最佳数量的并发线程，可以最大限度地提高应用程序的整体吞吐量。很难找到最佳的核心线程大小，但如果可能的话，实验会有所帮助。

这在很大程度上取决于任务中 CPU 与 IO 的程度。如果任务对慢速服务进行远程 RPC 调用，那么在池中拥有大量核心线程可能是有意义的。但是，如果它们主要是 CPU 任务，您将希望更接近 CPU/内核的数量，然后将其余任务排队。同样，这一切都与整体吞吐量有关。

Answer 3

要重用线程，需要以某种方式将任务转移到现有线程。
这将我推向了同步队列和零核心池大小。

return new ThreadPoolExecutor(0, maxThreadsCount,
        10L, SECONDS,
        new SynchronousQueue<Runnable>(),
        new BasicThreadFactory.Builder().namingPattern("processor-%d").build());

我的“主要流程”上的“峰值”数量确实减少了 500 - 1500 (ms)。
但这仅适用于零大小的队列。对于非零大小的队列问题仍然是开放的。