大话多线程处理~多线程真的快？线程池 emmm......

常听人说，多线程处理快~ 是啊，多条渠道同时进行确实快、可在计算机世界多线程处理一定快吗，显然不是。首先了解几个常识
1、线程执行需要获取cpu的执行权
2、对于1核cpu，多个线程需要去抢cpu、谁抢到谁执行，这就代表有个切换的过程~抢到 执行 退出，切换要浪费多少时间 emmm…、还不如一个线程一直跑快呢
因此，多线程处理不一定快，还的看硬件条件跟不跟的上

说了这么多，想到了什么没、多线程处理就是合理利用cpu，不能让他闲下来，也不能滥用，市面上 给出了针对不同业务和场景的使用指南可供参考借鉴。

高并发、任务执行时间短的业务：线程池线程数可以设置为CPU核数+1，减少线程上下文的切换
	
并发不高、任务执行时间长的业务
	a、假如是业务时间长集中在IO操作上，也就是IO密集型的任务，因为IO操作并不占用CPU，所以不要让所有的CPU闲下来、可以加大线程池中的线程数目，让CPU处理更多的业务
	b、假如是业务时间长集中在计算操作上，也就是计算密集型任务，这个就没办法了，和（1）一样吧，线程池中的线程数设置得少一些，减少线程上下文的切换
并发高、业务执行时间长的业务
   解决这种类型任务的关键不在于线程池而在于整体架构的设计，看看这些业务里面某些数据是否能做缓存是第一步
   增加服务器是第二步，至于线程池的设置，设置参考（2）。最后，业务执行时间长的问题，也可能需要分析一下、看看能不能使用中间件对任务进行拆分和解耦

还有一种方式，可以根据任务是用的IO多，还是CPU多


那么多线程具体如何用呢，当然用线程池~自己创建线程，何时销毁 搞多了怎么办？等等，一系列问题 专业的事情交给专业的机构去做，线程池由此而来
1、线程池维护一组线程，项目启动的时候就创建了几个核心线程放在内存中随时准备出击
当然对线程池的使用还有些注意事项，如果最大线程数设置过大，或者阻塞队列设置上限过长，可能导致OOM

但是线程池还是有很多优点：

说到线程池，不得不提到7大参数

corePoolSize： 线程池维护线程的最少数量
maxnumPoolSize： 线程池维护线程的最大数量
keepAliveTime： 线程池维护线程所允许的空闲时间、除了核心线程以外的 长时间不用会回收
unit： 线程池维护线程所允许的空闲时间的单位
workQueue： 线程池所使用的缓冲队列
handler： 线程池对拒绝任务的处理策略
设置allowCoreThreadTimeout=true（默认false）时，核心线程会超时关闭、线程池数量会减少为0

1、如果此时线程池中数量小于corePoolSize,即使线程池中的线程都处于空闲状态，也要创建新的线程来处理被添加的任务。
2、如果此时线程池中的数量等于corePoolSize,但是缓冲队列workQueue未满，那么任务放入缓冲队列
3、如果此时线程池中的数量大于corePoolSize，缓冲队列workQueue满，并且线程池中的数量小于maximumPoolSize，建新的线程来处理被添加的任务。
4、如果此时线程池中的数量大于corePoolSize，缓冲队列workQueue 满，并且线程池中的数量等于maximumPoolSize，那么通过handler所指定的策略来处理此任务。也就是：处理任务的优先级为：核心线程 corePoolSize、任务队列workQueue、最大线程maximumPoolSize，如果三者都满了，使用handler处理被拒绝的任务
5、当线程池中的线程数量大于corePoolSize时，如果某线程空闲时间超过keepAliveTime，线程将被终止。这样，线程池可以动态的调整池中的线程数。

之前看到过一张图，形象阐述

7个参数阐述：核心线程相当于银行当值窗口，客户越来越多–先在休息区(阻塞队列) 等待、客户还在增加，休息区也满了 没办法，只能把让剩余窗口临时加班–此时线程继续创建 达到了最大。休息区的客户可去加班窗口办理业务，新来客户去休息区…当休息区+窗口都满了，达到了最大接收客户的极限。客户经理门口拦截–触发了拒绝策略。

流程图

那么java如何创建线程池？有3种方式

   public void test2(){
   
        ExecutorService threadPool1=Executors.newFixedThreadPool(5)