浅谈Java 线程池线程数怎么定

在实际开发中，线程池几乎是每个 Java 后端绕不开的组件。但真正让人困惑的往往不是怎么用线程池，而是——线程数到底该怎么配。

有人按 CPU 核数来，有人直接乘 2，还有人干脆拍脑袋设一个固定值。这些做法在某些场景下 “看起来能跑”，但在 IO 较多或混合型任务中，往往会带来性能下降、请求堆积，甚至线程池耗尽的问题。

这篇文章主要面向 Java 后端开发者，结合常见的 IO 密集型、CPU 密集型以及混合型任务，梳理线程池线程数配置的基本思路，并给出可参考的计算方式，帮助你在不同场景下做出更合理的选择。

1. 按照任务类型对线程池进行分类

在讨论线程数之前，首先需要明确一点：线程数的配置和任务类型是强相关的。 使用标准构造器 ThreadPoolExecutor 创建线程池时，会涉及线程数的配置，而线程数的配置与异步任务类型是分不开的。这里将线程池的异步任务大致分为以下三类：

1. IO 密集型任务

此类任务主要是执行 IO 操作。由于执行 IO 操作的时间较长，导致 CPU 的利用率不高，这类任务 CPU 常处于空闲状态。Netty 的 IO 读写操作为此类任务的典型例子。

2. CPU 密集型任务

此类任务主要是执行计算任务。由于响应时间很快，CPU 一直在运行，这种任务 CPU 的利用率很高。

3. 混合型任务

此类任务既要执行逻辑计算，又要进行 IO 操作（如 RPC 调用、数据库访问）。相对来说，由于执行 IO 操作的耗时较长（一次网络往返往往在数百毫秒级别），这类任务的 CPU 利用率也不是太高。Web 服务器的 HTTP 请求处理操作为此类任务的典型例子。

一般情况下，针对以上不同类型的异步任务需要创建不同类型的线程池，并进行针对性的参数配置。

2. 为 IO 密集型任务确定线程数

由于 IO 密集型任务的 CPU 使用率较低，导致线程空余时间很多，因此通常需要开 CPU 核心数两倍的线程。当 IO 线程空闲时，可以启用其他线程继续使用 CPU，以提高 CPU 的使用率。

接下来为 IO 密集型任务创建了一个简单的参考线程池，具体代码如下：

import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class ThreadUtil {

    private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();

    private static final int THREAD_COUNT = Math.max(2, CPU_COUNT);
    
    private static final int QUEUE_COUNT = 128;
    
    private static final int KEEP_ALIVE_SECONDS = 30;
    
    private static class ThreadPoolExecutorDemo{
        private static final ThreadPoolExecutor EXECUTOR = new ThreadPoolExecutor(
                THREAD_COUNT,
                THREAD_COUNT,
                KEEP_ALIVE_SECONDS,
                TimeUnit.SECONDS,
                new LinkedBlockingQueue<>(QUEUE_COUNT),
                new ThreadPoolExecutor.AbortPolicy()
        );
    }
}

3. 为 CPU 密集型任务确定线程数

CPU 密集型任务也叫计算密集型任务，其特点是要进行大量计算而需要消耗 CPU 资源，比如计算圆周率、对视频进行高清解码等。CPU 密集型任务虽然也可以并行完成，但是并行的任务越多，花在任务切换的时间就越多 CPU 执行任务的效率就越低，所以要最高效地利用 CPU，CPU 密集型任务并行执行的数量应当等于 CPU 的核心数。

比如说 4 个核心的 CPU，通过 4 个线程并行执行 4 个 CPU 密集型任务，此时的效率是最高的。但是如果线程数远远超出 CPU 核心数量，就需要频繁地切换线程，线程上下文切换时需要消耗时间，反而会使得任务效率下降。因此，对于 CPU 密集型的任务来说，线程数等于 CPU 数就行。

接下来为 CPU 密集型任务创建了一个简单的参考线程池，具体代码如下：

import java.util.concurrent.*;

public class ThreadUtil {

    private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();

    private static final int THREAD_COUNT = CPU_COUNT;

    private static final int QUEUE_COUNT = 128;

    private static final int KEEP_ALIVE_SECONDS = 30;

    private static class ThreadPoolExecutorDemo{
        private static final ThreadPoolExecutor EXECUTOR = new ThreadPoolExecutor(
                THREAD_COUNT,
                THREAD_COUNT,
                KEEP_ALIVE_SECONDS,
                TimeUnit.SECONDS,
                new LinkedBlockingQueue<>(QUEUE_COUNT),
                new ThreadPoolExecutor.AbortPolicy()
        );
    }
}

4. 为混合型任务确定线程数

混合型任务既要执行逻辑计算，又要进行大量非CPU 耗时操作（如 RPC 调用、数据库访问、网络通信等），所以混合型任务 CPU 利用率不是太高，非 CPU 耗时往往是 CPU 耗时的数倍。比如在 Web 应用处理 HTTP 请求处理时，一次请求处理会包括 DB 操作、RPC 操作、缓存操作等多种耗时操作。一般来说，一次 Web 请求的 CPU 计算耗时往往较少，大致在 100 - 500 毫秒，而其他耗时操作会占用 500 - 1000 毫秒，甚至更多的时间。

在为混合型任务创建线程池时，如何确定线程数呢？在工程实践中，通常会通过 线程等待时间和 CPU 计算时间的比例 来估算线程数，常见的计算思路如下：

最佳线程数 = （（线程等待时间+线程CPU时间）/线程CPU时间 ）* CPU核数

经过简单的换算，以上公式可进一步转换为：

最佳线程数目 =（线程等待时间与线程CPU时间之比 + 1）* CPU核数

通过公式可以看出：等待时间所占比例越高，需要的线程就越多；CPU 耗时所占比例越高，需要的线程就越少。下面举一个例子：比如在 Web 服务器处理 HTTP 请求时，假设平均线程 CPU 运行时间为 100 毫秒，而线程等待时间（比如包括 DB 操作、RPC操作、缓存操作等）为 900 毫秒，如果 CPU 核数为 8，那么根据上面这个公式，估算如下：

（900ms+100ms）/100ms8= 108 = 8

经过计算，以上案例中需要的线程数为 80。很多人认为，线程数越高越好。那么，使用很多线程是否就一定比单线程高效呢？答案是否定的，比如大名鼎鼎的 Redis 就是单线程的，但它却非常高效，基本操作都能达到十万量级/秒。

由于 Redis 基本都是内存操作，在这种情况下单线程可以高效地利用 CPU，多线程反而不是太适用。多线程适用场景一般是：存在相当比例非 CPU 耗时操作，如 IO、网络操作，需要尽量提高并行化比率以提升 CPU 的利用率。

总体来说，线程池线程数并不存在一个放之四海而皆准的固定值。不同类型的任务，其 CPU 使用情况和等待时间差异很大，直接决定了线程数配置的侧重点。

对于 IO 密集型、CPU 密集型以及混合型任务，本文给出的配置思路和估算公式可以作为一个起点，但在真实的生产环境中，仍然需要结合具体的业务特性、硬件条件以及压测结果进行不断调整。

实际上，线程池真正“难”的地方，往往不止是线程数本身，还包括队列大小、拒绝策略以及运行时的监控和调优。这些问题在复杂系统中同样容易被忽视，后续也值得单独展开讨论。

到此这篇关于浅谈Java 线程池线程数怎么定的文章就介绍到这了,更多相关Java 定线程池线程数 内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论