根据 CPU 核心数确定线程池并发线程数

根据 CPU 核心数确定线程池并发线程数

一、抛出问题

关于如何计算并发线程数，一般分两派，来自两本书，且都是好书，到底哪个是对的？问题追踪后，整理如下：

第一派：《Java Concurrency in Practice》即《java 并发编程实践》，如下图：

如上图，在《Java Concurrency in Practice》一书中，给出了估算线程池大小的公式：

Nthreads=NcpuUcpu(1+w/c)，其中

Ncpu=CPU 核心数

Ucpu=cpu 使用率，0~1

W/C = 等待时间与计算时间的比率

第二派：《Programming Concurrency on the JVM Mastering》即《Java 虚拟机并发编程》

线程数 = Ncpu/（1 - 阻塞系数）

回到顶部

二、分析

对于派系一，假设 cpu100% 运转，即撇开 CPU 使用率这个因素，线程数 =Ncpu*(1+w/c)。

现在假设将派系二的公式等于派系一公式，即 Ncpu/（1 - 阻塞系数）=Ncpu*(1+w/c),===》阻塞系数 = w/(w+c)，即阻塞系数 = 阻塞时间 /（阻塞时间 + 计算时间），这个结论在派系二后续中得到应征，如下图：

由此可见，派系一和派系二其实是一个公式...... 这样我就放心了......

回到顶部

三、实际应用

那么实际使用中并发线程数如何设置呢？分析如下（我们以派系一公式为例）：

Nthreads=Ncpu*(1+w/c)

IO 密集型：一般情况下，如果存在 IO，那么肯定 w/c>1（阻塞耗时一般都是计算耗时的很多倍）, 但是需要考虑系统内存有限（每开启一个线程都需要内存空间），这里需要上服务器测试具体多少个线程数适合（CPU 占比、线程数、总耗时、内存消耗）。如果不想去测试，保守点取 1 即，Nthreads=Ncpu*(1+1)=2Ncpu。这样设置一般都 OK。

计算密集型：假设没有等待 w=0，则 W/C=0. Nthreads=Ncpu。

至此结论就是：

IO 密集型 =2Ncpu（可以测试后自己控制大小，2Ncpu 一般没问题）（常出现于线程中：数据库数据交互、文件上传下载、网络数据传输等等）

计算密集型 =Ncpu（常出现于线程中：复杂算法）

java 中：Ncpu=Runtime.getRuntime().availableProcessors()

========================= 此处可略过 =============================================

当然派系一种《Java Concurrency in Practice》还有一种说法，

即对于计算密集型的任务，在拥有 N 个处理器的系统上，当线程池的大小为 N+1 时，通常能实现最优的效率。(即使当计算密集型的线程偶尔由于缺失故障或者其他原因而暂停时，这个额外的线程也能确保 CPU 的时钟周期不会被浪费。)

即，计算密集型 =Ncpu+1，但是这种做法导致的多一个 cpu 上下文切换是否值得，这里不考虑。读者可自己考量。

======================================================================

回到顶部

四、总结：

选择线程池并发线程数的因素很多：任务类型、内存等线程中使用到所有资源都需要考虑。本文经过对现有文献的分析论证，得出结论，并给出了实际应用公式，实乃工程师之福利，技术之典范......