在实际开发中，线程池几乎是每个 Java 后端绕不开的组件。但真正让人困惑的往往不是怎么用线程池，而是——线程数到底该怎么配。
有人按 CPU 核数来，有人直接乘 2，还有人干脆拍脑袋设一个固定值。这些做法在某些场景下'看起来能跑'，但在 IO 较多或混合型任务中，往往会带来性能下降、请求堆积，甚至线程池耗尽的问题。
本文结合常见的 IO 密集型、CPU 密集型以及混合型任务，梳理线程池线程数配置的基本思路，并给出可参考的计算方式，帮助你在不同场景下做出更合理的选择。
1. 按照任务类型对线程池进行分类
在讨论线程数之前，首先需要明确一点：线程数的配置和任务类型是强相关的。使用标准构造器 ThreadPoolExecutor 创建线程池时，会涉及线程数的配置，而线程数的配置与异步任务类型是分不开的。这里将线程池的异步任务大致分为以下三类：
- IO 密集型任务
此类任务主要是执行 IO 操作。由于执行 IO 操作的时间较长，导致 CPU 的利用率不高，这类任务 CPU 常处于空闲状态。Netty 的 IO 读写操作为此类任务的典型例子。
- CPU 密集型任务
此类任务主要是执行计算任务。由于响应时间很快，CPU 一直在运行，这种任务 CPU 的利用率很高。
- 混合型任务
此类任务既要执行逻辑计算，又要进行 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）/100ms * 8 = 10 * 8 = 80
经过计算，以上案例中需要的线程数为 80。很多人认为，线程数越高越好。那么，使用很多线程是否就一定比单线程高效呢？答案是否定的，比如大名鼎鼎的 Redis 就是单线程的，但它却非常高效，基本操作都能达到十万量级/秒。
由于 Redis 基本都是内存操作，在这种情况下单线程可以高效地利用 CPU，多线程反而不是太适用。多线程适用场景一般是：存在相当比例非 CPU 耗时操作，如 IO、网络操作，需要尽量提高并行化比率以提升 CPU 的利用率。
总体来说，线程池线程数并不存在一个放之四海而皆准的固定值。不同类型的任务，其 CPU 使用情况和等待时间差异很大，直接决定了线程数配置的侧重点。
对于 IO 密集型、CPU 密集型以及混合型任务，本文给出的配置思路和估算公式可以作为一个起点，但在真实的生产环境中，仍然需要结合具体的业务特性、硬件条件以及压测结果进行不断调整。
实际上，线程池真正'难'的地方，往往不止是线程数本身，还包括队列大小、拒绝策略以及运行时的监控和调优。这些问题在复杂系统中同样容易被忽视，后续也值得单独展开讨论。
