文章目录
- 一. 按照任务类型对线程池进行分类
- 1. IO密集型任务的线程数
- 2. CPU密集型任务的线程数
- 3. 混合型任务的线程数
- 二. 线程数越多越好吗
- 三. Redis 单线程的高效性
使用线程池的好处主要有以下三点：
- 降低资源消耗：线程是稀缺资源，如果无限制地创建，不仅会消耗系统资源，还会降低系统的稳定性，通过重复利用已创建的线程可以降低线程创建和销毁造成的消耗。
- 提高响应速度：当任务到达时，可以不需要等待线程创建就能立即执行。
- 提高线程的可管理性：线程池提供了一种限制、管理资源的策略，维护一些基本的线程统计信息，如已完成任务的数量等。通过线程池可以对线程资源进行统一的分配、监控和调优。
虽然使用线程池的好处很多，但是如果其线程数配置得不合理，不仅可能达不到预期效果，反而可能降低应用的性能。接下来按照不同的任务类型来配置线程池。
一. 按照任务类型对线程池进行分类
使用标准构造器ThreadPoolExecutor创建线程池时，会涉及线程数的配置，而线程数的配置与异步任务类型是分不开的。这里将线程池的异步任务大致分为以下三类：
- IO密集型任务此类任务主要是执行IO操作。由于执行IO操作的时间较长，导致CPU的利用率不高，这类任务CPU常处于空闲状态。Netty的IO读写操作为此类任务的典型例子。
- CPU密集型任务此类任务主要是执行计算任务。由于响应时间很快，CPU一直在运行，这种任务CPU的利用率很高。
- 混合型任务此类任务既要执行逻辑计算，又要进行IO操作（如RPC调用、数据库访问）。
相对来说，由于执行IO操作的耗时较长（一次网络往返往往在数百毫秒级别），这类任务的CPU利用率也不是太高。Web服务器的HTTP请求处理操作为此类任务的典型例子。一般情况下，针对以上不同类型的异步任务需要创建不同类型的线程池，并进行针对性的参数配置。
1. IO密集型任务的线程数
由于IO密集型任务的CPU使用率较低，导致线程空余时间很多，因此通常需要开CPU核心数两倍的线程。当IO线程空闲时，可以启用其他线程继续使用CPU，以提高CPU的使用率。
java">@Slf4j
//懒汉式单例创建线程池：用于IO密集型任务
public class IoIntenseTargetThreadPoolLazyHolder { /** * IO线程池最大线程数 */ public static final int IO_MAX = Math.max(2, CPU_COUNT * 2); /** * 空闲保活时限，单位秒 */ public static final int KEEP_ALIVE_SECONDS = 30; /** * 有界队列size */ public static final int QUEUE_SIZE = 10000; //线程池： 用于IO密集型任务 public static final ThreadPoolExecutor EXECUTOR = new ThreadPoolExecutor( IO_MAX, IO_MAX, KEEP_ALIVE_SECONDS, TimeUnit.SECONDS, new LinkedBlockingQueue(QUEUE_SIZE), new ThreadUtil.CustomThreadFactory("io")); public static ThreadPoolExecutor getInnerExecutor() { return EXECUTOR; } static { log.info("线程池已经初始化"); EXECUTOR.allowCoreThreadTimeOut(true); //JVM关闭时的钩子函数 Runtime.getRuntime().addShutdownHook( new ShutdownHookThread("IO密集型任务线程池", new Callable<Void>() { @Override public Void call() throws Exception { //优雅关闭线程池 shutdownThreadPoolGracefully(EXECUTOR); return null; } })); }
}
有以下几点需要注意
- 调用allowCoreThreadTimeOut，传入了参数true，应用于核心线程，当池中的线程长时间空闲时，可以自行销毁。
- 使用有界队列缓冲任务而不是无界队列，如果128太小，可以根据具体需要进行增大，但是不能使用无界队列。
- corePoolSize和maximumPoolSize保持一致，使得在接收到新任务时，如果没有空闲工作线程，就优先创建新的线程去执行新任务，而不是优先加入阻塞队列，等待现有工作线程空闲后再执行。
- 使用JVM关闭时的钩子函数优雅地自动关闭线程池。
2. CPU密集型任务的线程数
CPU密集型任务也叫计算密集型任务，其特点是要进行大量计算而需要消耗CPU资源，比如计算圆周率、对视频进行高清解码等。
CPU密集型任务虽然也可以并行完成，但是并行的任务越多，花在任务切换的时间就越多，CPU执行任务的效率就越低，所以要最高效地利用CPU，CPU密集型任务并行执行的数量应当等于CPU的核心数。
java">/** * CPU核数 **/
public static final int CPU_COUNT = Runtime.getRuntime().availableProcessors(); public static final int MAXIMUM_POOL_SIZE = CPU_COUNT; //线程池： 用于CPU密集型任务
private static final ThreadPoolExecutor EXECUTOR = new ThreadPoolExecutor( MAXIMUM_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE_SECONDS, TimeUnit.SECONDS, new LinkedBlockingQueue(QUEUE_SIZE), new CustomThreadFactory("cpu")); public static ThreadPoolExecutor getInnerExecutor() { return EXECUTOR;
} static { log.info("线程池已经初始化"); EXECUTOR.allowCoreThreadTimeOut(true); //JVM关闭时的钩子函数 Runtime.getRuntime().addShutdownHook( new ShutdownHookThread("CPU密集型任务线程池", new Callable<Void>() { @Override public Void call() throws Exception { //优雅关闭线程池 shutdownThreadPoolGracefully(EXECUTOR); return null; } }));
}
3. 混合型任务的线程数
混合型任务既要执行逻辑计算，又要进行大量非CPU耗时操作（如RPC调用、数据库访问、网络通信等），所以混合型任务CPU的利用率不是太高，非CPU耗时往往是CPU耗时的数倍。
比如在Web应用中处理HTTP请求时，一次请求处理会包括DB操作、RPC操作、缓存操作等多种耗时操作。一般来说，一次Web请求的CPU计算耗时往往较少，大致在100～500毫秒，而其他耗时操作会占用500～1000毫秒，甚至更多的时间。
在为混合型任务创建线程池时，如何确定线程数呢？业界有一个比较成熟的估算公式，具体如下：
java">
最佳线程数 = (（线程等待时间+线程CPU时间） / 线程CPU时间) * CPU核数通过公式可以看出：等待时间所占的比例越高，需要的线程就越多；CPU耗时所占的比例越高，需要的线程就越少。
下面举一个例子：
比如在Web服务器处理HTTP请求时，假设平均线程CPU运行时间为100毫秒，而线程等待时间（比如包括DB操作、RPC操作、缓存操作等）为900毫秒，如果CPU核数为8，那么根据上面这个公式，估算如下：
java">（900毫秒 + 100毫秒） / 100毫秒 * 8 = 10 * 8 = 80
二. 线程数越多越好吗
很多小伙伴认为，线程数越高越好。那么，使用很多线程是否就一定比单线程高效呢？答案是否定的。
虽然多线程在一些并发场景下能带来性能提升，但过多的线程并不意味着性能必定提升。线程数过高可能导致一些问题：
上下文切换（Context Switching）： 每个线程的执行都由操作系统调度，线程切换会带来额外的开销。当线程数过多时，操作系统频繁地在不同线程间切换，导致 上下文切换 成本增加，这样反而可能降低系统的整体效率。
资源争用： 多线程同时访问共享资源时，可能会遇到 资源竞争 和 锁竞争，特别是在 CPU 绑定的任务中。线程之间的协作和同步会称为性能瓶颈。
内存开销： 每个线程需要占用一定的内存，维护线程栈、调度信息等，过多的线程会消耗大量的内存和系统资源，这可能会导致系统性能下降，甚至造成内存溢出。
三. Redis 单线程的高效性
Redis 是一个 单线程 的高性能数据库，许多人可能会觉得它的设计不合常理，为什么不使用多线程来提升性能呢？然而，Redis 使用单线程反而能够达到极高的吞吐量，这是因为：
| 特点 | 核心内容 |
|---|---|
| 1. 避免多线程上下文切换 | 单线程模型避免了线程切换的开销，任务按顺序处理，简化了并发控制，避免了锁竞争和死锁问题。 |
| 2. 非阻塞设计 | 采用事件驱动和 I/O 多路复用技术，非阻塞处理请求。如果一个请求需要等待外部资源（如网络 I/O），Redis 会把控制权交给其他请求，而不是阻塞线程。这种方式避免了多线程中因为等待 I/O 资源导致的线程空闲，充分利用了 CPU 的时间片。 |
| 3. CPU vs I/O 密集型 | Redis 的大多数操作（如 GET/SET）是 I/O 密集型 的，单线程在 I/O 密集型应用中有优势。 |
| 4. 数据访问模式 | Redis 操作主要是内存访问，内存操作速度快，单线程执行时没有同步问题，数据结构（如哈希表、跳表等）高效。 |
