CPU密集型也叫计算密集型,指的是系统的硬盘、内存性能相对CPU要好很多,此时,系统运作大部分的状况是CPU Loading 100%,CPU要读/写I/O(硬盘/内存),I/O在很短的时间就可以完成,而CPU还有许多运算要处理,CPU Loading很高。 写了一个cpu密集型的例子,一直执行自增操作 CPU bound的程序一般而言CPU占用率相当高。这可能是因为任务本身不太需要访问I/O设备,也可能是因为程序是多线程实现因此屏蔽掉了等待I/O的时间 如果是CPU密集型应用,则线程池大小设置为N+1;(对于计算密集型的任务,在拥有N个处理器的系统上,当线程池的大小为N+1时,通常能实现最优的效率。(即使当计算密集型的线程偶尔由于缺失故障或者其他原因而暂停时,这个额外的线程也能确保CPU的时钟周期不会被浪费。摘自《Java Concurrency In Practise》)
以下我们写一个cpu密集型的demo; 来试试不同线程数量的耗时结果
public class SrcTest {
static int threadNum = 20;
final static int taskNum = 200;
static ExecutorService executorService = Executors.newFixedThreadPool(threadNum);
static CountDownLatch endGate = new CountDownLatch(taskNum);
public static void main(String[] args) throws InterruptedException {
long start = System.currentTimeMillis();
for (int i = 0; i< taskNum; i++){
executorService.submit(cpuCal());
}
endGate.await();
long end = System.currentTimeMillis();
System.out.println("线程池数量:"+threadNum+" CPU核数:"+Runtime.getRuntime().availableProcessors()+"全部结束:time:"+(end-start));
}
public static Thread cpuCal(){
return new Thread(()->{
long start = System.currentTimeMillis();
//随便写个cpu耗时的操作
for (int i = 0;i<10000000;i++){
StringBuffer sb = new StringBuffer();
sb.append(i).append(",");
}
long end = System.currentTimeMillis();
System.out.println("线程ID:"+Thread.currentThread().getId()+"; 消耗时间:"+(end-start));
endGate.countDown();
});
}
}
threadNum=1
threadNum=2
threadNum=4
可以看到在线程数量为4的时候,我的这8核机器中的4个cpu飙升
threadNum=8
打开cpu使用率 可以看到在线程数量为8的时候,我的这8核机器中的8个cpu全部满负载运行
threadNum=14
threadNum=20
实验系统配置情况:
物理cpu内核数:4 sysctl hw.physicalcpu
逻辑cpu内核数:8 sysctl hw.logicalcpu
因为开启了 超线程技术 就有了4核8线程
线程数 | 全部结束耗费时间 | 单任务平均耗费时间 |
---|---|---|
1 | 63007 | 320 |
2 | 35828 | 345 |
4 | 24252 | 430 |
8 | 21340 | 700 |
14 | 22837 | 1100 |
20 | 22081 | 1920 |
通过上面的实验数据,我们分析可以得出 在CPU密集型的场景下; 当线程数=CPU逻辑核数 的时候, 总体耗费的时间是最少的; 并且 当线程数 越来越大的时候, 单任务平均耗时会越来越大,这是因为线程数越多,就会有越多的线程上下文切换,耗费一部分性能; 当 线程数 > CPU逻辑核数时候, 总体耗费的时间已经不会有明显的减少,反而会略微上升,并且 单任务耗时确实逐渐增高的;
所以最终结论: 当CPU密集场景下; 线程数 =CPU逻辑核数时候, 总体效率最高;
当然了我们一般可以设置为 CPU逻辑核数+1 ; 这个1 的原因是:即使当计算密集型的线程偶尔由于缺失故障或者其他原因而暂停时,这个额外的线程也能确保CPU的时钟周期不会被浪费
如果是IO密集型应用,则线程池大小设置为2N+1
如果一台服务器上只部署这一个应用并且只有这一个线程池,那么这种估算或许合理,具体还需自行测试验证。
接下来在这个文档:服务器性能IO优化 中发现一个估算公式:
最佳线程数目 = ((线程等待时间+线程CPU时间)/线程CPU时间 )* CPU数目 进一步转换 最佳线程数目 = (线程等待时间与线程CPU时间之比 + 1)* CPU数目
可以得出一个结论: 线程等待时间所占比例越高,需要越多线程。线程CPU时间所占比例越高,需要越少线程
混合型任务 可以将任务分成IO密集型和CPU密集型任务,然后分别用不同的线程池去处理。 只要分完之后两个任务的执行时间相差不大,那么就会比串行执行来的高效。 因为如果划分之后两个任务执行时间相差甚远,那么先执行完的任务就要等后执行完的任务,最终的时间仍然取决于后执行完的任务,而且还要加上任务拆分与合并的开销,得不偿失。
先来解释一下什么是上下文切换(context switch)。在多任务处理系统中,作业数通常大于CPU数。为了让用户觉得这些任务在同时进行,CPU给每个任务分配一定时间,把当前任务状态保存下来,当前运行任务转为就绪(或者挂起、删除)状态,另一个被选定的就绪任务成为当前任务。之后CPU可以回过头再处理之前被挂起任务。上下文切换就是这样一个过程,它允许CPU记录并恢复各种正在运行程序的状态,使它能够完成切换操作。在这个过程中,CPU会停止处理当前运行的程序,并保存当前程序运行的具体位置以便之后继续运行
上下文切换会导致CPU在寄存器和运行队列之间来回奔波。这种消耗可以分为两种
损耗种类 | 描述 |
---|---|
直接损耗 | CPU寄存器需要保存和加载, 系统调度器的代码需要执行, TLB实例需要重新加载, CPU 的pipeline需要刷掉 |
间接损耗 | 多核的cache之间得共享数据 |