目录
3. 为了完成任务,创建很多的线程可以吗?线程真的是越多越好?
1.并发和并行
CPU单核
CPU多核、多CPU
1.1 并发
单核上,多个线程占用不同的CPU时间片,物理上还是串行执行的,但是由于每个线程占用的CPU时间片非常短(比如10ms),看起来就像是多个线程都在共同执行一样,这样的场景称作并发(concurrent)。
1.2 并行
在多核或者多CPU上,多个线程是在真正的同时执行,这样的场景称作并行(parallel)。
2. 多线程的优势
多线程程序一定就好吗?不一定,要看具体的应用场景:
2.1 IO密集型
(涉及I/O操作)
无论是CPU单核、CPU多核、多CPU,都是比较适合多线程程序的
I/O密集型更适合设计成多线程程序
内核有2个队列:
系统直接从就绪队列取任务执行指令。
I/O密集型的任务不受CPU资源,因为可能调度不到,没有放在就绪队列(等待的资源没有准备好,放在阻塞队列),操作系统是从就绪队列取任务,分配时间片的。
2.2 CPU密集型
(大量计算,深度学习,运算)
(不会阻塞)
CPU单核(一个人一直计算)
多线程存在上下文切换,(CPU寄存器信息保存到线程的内核栈上,上下文切换,然后恢复到CPU寄存器上),是额外的花销,线程越多上下文切换所花费的额外时间也越多,倒不如一个线程一直进行计算
对于多核来说,I/O密集型和CPU密集型,都是适合多线程程序的
上下文切换:当线程1切换到线程2时,线程1需要把自己执行的现场信息(主要是寄存器里的信息),找到当前线程1的线程栈,然后存到线程1的内核栈中,再调度线程2时,又会访问线程2的内核栈,从内核栈中再进行地址的偏移,找内核栈中存储的上一次该线程运行的寄存器CPU的信息,然后从内核栈中再把它恢复到CPU的寄存器中,再调度线程2
不能让CPU空闲下来,不然就是浪费了!!!
I/O密集型的任务不会造成CPU资源的浪费,CPU密集型的任务是受操作系统直接调度的。
I/O密集型的任务不受CPU资源,因为可能调度不到,没有放在就绪队列(等待的资源没有准备好,放在阻塞队列),操作系统是从就绪队列取任务,分配时间片的。
总结:
I/O密集型不论是单核还是多核,始终适合多线程
CPU密集型:单核不适合,多核适合
3. 为了完成任务,创建很多的线程可以吗?线程真的是越多越好?
不是
1.线程的创建和销毁都是非常"重"的操作(性能消耗,耗时严重)
创建一个线程的耗费是很大的,既涉及了空间的切换,有涉及了内核一系列的数据结构的分配,数据的初始化。所以线程数量不宜过多,且不宜在业务的执行过程中,再去频繁的创建和销毁线程
2.线程栈本身占用大量内存
32位系统进程占4G的地址空间,其中用户空间3G,内核空间1G
一个线程栈空间默认8M
一个进程大概可以创建380个线程。(扣除代码段,数据段,共享库区域…)
3.线程的上下文切换要占用大量时间
4.
4 线程池的优势
操作系统上创建线程和销毁线程都是很"重"的操作,耗时耗性能都比较多,那么在服务执行的过程中,如果业务量比较大,实时的去创建线程、执行业务、业务完成后销毁线程,那么会导致系统的实时性能降低,业务的处理能力也会降低。
线程池的优势就是(每个池都有自己的优势),在服务进程启动之初,就事先创建好线程池里面的线程,当业务流量到来时需要分配线程,直接从线程池中获取一个空闲线程执行task任务即可,task执行完成后,也不用释放线程,而是把线程归还到线程池中继续给后续的task提供服务。
fixed模式线程池
线程池里面的线程个数是固定不变的,一般是ThreadPool创建时根据当前机器的CPU核心数量进行指定。
cached模式线程池
线程池里面的线程个数是可动态增长的,根据任务的数量动态的增加线程的数量,但是会设置一个线程数量的阈值(线程过多的坏处上面已经讲过了),任务处理完成,如果动态增长的线程空闲了60s还没有处理其它任务,那么关闭线程,保持池中最初数量的线程即可。