核心内容摘要
BBBB与BBBBB：不止是数字的飞跃，更是体验的革新！
文章目录
按照任务类型对线程池进行分类
为 IO 密集型任务确定线程数
为 CPU 密集型任务确定线程数
为混合型任务确定线程数在实际开发中线程池几乎是每个 Java 后端绕不开的组件。
但真正让人困惑的往往不是怎么用线程池而是——线程数到底该怎么配。
有人按 CPU 核数来有人直接乘 2还有人干脆拍脑袋设一个固定值。
这些做法在某些场景下 “看起来能跑”但在 IO 较多或混合型任务中往往会带来性能下降、请求堆积甚至线程池耗尽的问题。
这篇文章主要面向Java 后端开发者结合常见的 IO 密集型、CPU 密集型以及混合型任务梳理线程池线程数配置的基本思路并给出可参考的计算方式帮助你在不同场景下做出更合理的选择。
按照任务类型对线程池进行分类在讨论线程数之前首先需要明确一点线程数的配置和任务类型是强相关的。
使用标准构造器 ThreadPoolExecutor 创建线程池时会涉及线程数的配置而线程数的配置与异步任务类型是分不开的。
这里将线程池的异步任务大致分为以下三类IO 密集型任务此类任务主要是执行 IO 操作。
由于执行 IO 操作的时间较长导致 CPU 的利用率不高这类任务 CPU 常处于空闲状态。
Netty 的 IO 读写操作为此类任务的典型例子。
CPU 密集型任务此类任务主要是执行计算任务。
由于响应时间很快CPU 一直在运行这种任务 CPU 的利用率很高。
混合型任务此类任务既要执行逻辑计算又要进行 IO 操作如 RPC 调用、数据库访问。
相对来说由于执行 IO 操作的耗时较长一次网络往返往往在数百毫秒级别这类任务的 CPU 利用率也不是太高。
Web 服务器的 HTTP 请求处理操作为此类任务的典型例子。
一般情况下针对以上不同类型的异步任务需要创建不同类型的线程池并进行针对性的参数配置。
为 IO 密集型任务确定线程数由于 IO 密集型任务的 CPU 使用率较低导致线程空余时间很多因此通常需要开 CPU 核心数两倍的线程。
当 IO 线程空闲时可以启用其他线程继续使用 CPU以提高 CPU 的使用率。
接下来为 IO 密集型任务创建了一个简单的参考线程池具体代码如下importjava.util.concurrent.LinkedBlockingQueue;importjava.util.concurrent.ThreadPoolExecutor;importjava.util.concurrent.TimeUnit;publicclassThreadUtil{privatestaticfinalintCPU_COUNTRuntime.getRuntime().availableProcessors();privatestaticfinalintTHREAD_COUNTMath.max(2,CPU_COUNT);privatestaticfinalintQUEUE_COUNT128;privatestaticfinalintKEEP_ALIVE_SECONDS30;privatestaticclassThreadPoolExecutorDemo{privatestaticfinalThreadPoolExecutorEXECUTORnewThreadPoolExecutor(THREAD_COUNT,THREAD_COUNT,KEEP_ALIVE_SECONDS,TimeUnit.SECONDS,newLinkedBlockingQueue(QUEUE_COUNT),newThreadPoolExecutor.AbortPolicy());}}
为 CPU 密集型任务确定线程数CPU 密集型任务也叫计算密集型任务其特点是要进行大量计算而需要消耗 CPU 资源比如计算圆周率、对视频进行高清解码等。
CPU 密集型任务虽然也可以并行完成但是并行的任务越多花在任务切换的时间就越多 CPU 执行任务的效率就越低所以要最高效地利用 CPUCPU 密集型任务并行执行的数量应当等于 CPU 的核心数。
比如说 4 个核心的 CPU通过 4 个线程并行执行 4 个 CPU 密集型任务此时的效率是最高的。
但是如果线程数远远超出 CPU 核心数量就需要频繁地切换线程线程上下文切换时需要消耗时间反而会使得任务效率下降。
因此对于 CPU 密集型的任务来说线程数等于 CPU 数就行。
接下来为 CPU 密集型任务创建了一个简单的参考线程池具体代码如下importjava.util.concurrent.*;publicclassThreadUtil{privatestaticfinalintCPU_COUNTRuntime.getRuntime().availableProcessors();privatestaticfinalintTHREAD_COUNTCPU_COUNT;privatestaticfinalintQUEUE_COUNT128;privatestaticfinalintKEEP_ALIVE_SECONDS30;privatestaticclassThreadPoolExecutorDemo{privatestaticfinalThreadPoolExecutorEXECUTORnewThreadPoolExecutor(THREAD_COUNT,THREAD_COUNT,KEEP_ALIVE_SECONDS,TimeUnit.SECONDS,newLinkedBlockingQueue(QUEUE_COUNT),newThreadPoolExecutor.AbortPolicy());}}
为混合型任务确定线程数混合型任务既要执行逻辑计算又要进行大量非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那么根据上面这个公式估算如下900ms100ms/100ms8 108 8经过计算以上案例中需要的线程数为 80。
很多人认为线程数越高越好。
那么使用很多线程是否就一定比单线程高效呢答案是否定的比如大名鼎鼎的 Redis 就是单线程的但它却非常高效基本操作都能达到十万量级/秒。
由于 Redis 基本都是内存操作在这种情况下单线程可以高效地利用 CPU多线程反而不是太适用。
多线程适用场景一般是存在相当比例非 CPU 耗时操作如 IO、网络操作需要尽量提高并行化比率以提升 CPU 的利用率。
总体来说线程池线程数并不存在一个放之四海而皆准的固定值。
不同类型的任务其 CPU 使用情况和等待时间差异很大直接决定了线程数配置的侧重点。
对于 IO 密集型、CPU 密集型以及混合型任务本文给出的配置思路和估算公式可以作为一个起点但在真实的生产环境中仍然需要结合具体的业务特性、硬件条件以及压测结果进行不断调整。
实际上线程池真正“难”的地方往往不止是线程数本身还包括队列大小、拒绝策略以及运行时的监控和调优。
这些问题在复杂系统中同样容易被忽视后续也值得单独展开讨论。