jave 线程池

线程池简述

Java中的线程池是运用场景最多的并发框架，几乎全部须要异步或并发执行任务的程序均可以使用线程池。在开发过程当中，合理地使用线程池可以带来3个好处。

• 下降资源消耗。经过重复利用已建立的线程下降线程建立和销毁形成的消耗
• 提升响应速度。当任务到达时，任务能够不须要等到线程建立就能当即执行
• 提升线程的可管理性。线程是稀缺资源，若是无限制地建立，不只会消耗系统资源，还会下降系统的稳定性，使用线程池能够进行统一分配、调优和监控

线程池是为忽然大量爆发的线程设计的，经过有限的几个固定线程为大量的操做服务，减小了建立和销毁线程所需的时间，从而提升效率。
若是一个线程的时间很是长，就不必用线程池了(不是不能做长时间操做，而是不宜。)，何况咱们还不能控制线程池中线程的开始、挂起、和停止

线程池的分类

ThreadPoolExecutor

Executor框架的最顶层实现是ThreadPoolExecutor类，Executors工厂类中提供的newScheduledThreadPool、newFixedThreadPool、newCachedThreadPool方法其实也只是ThreadPoolExecutor的构造函数参数不一样而已。经过传入不一样的参数，就能够构造出适用于不一样应用场景下的线程池
corePoolSize： 核心池的大小。 当有任务来以后，就会建立一个线程去执行任务，当线程池中的线程数目达到corePoolSize后，就会把到达的任务放到缓存队列当中
maximumPoolSize： 线程池最大线程数，它表示在线程池中最多能建立多少个线程；
keepAliveTime： 表示线程没有任务执行时最多保持多久时间会终止。
unit： 参数keepAliveTime的时间单位，有7种取值

newCachedThreadPool

建立一个可缓存线程池，若是线程池长度超过处理须要，可灵活回收空闲线程，若无可回收，则新建线程。
线程池为无限大，当执行第二个任务时第一个任务已经完成，会复用执行第一个任务的线程，而不用每次新建线程

newFixedThreadPool

建立一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待
定长线程池的大小最好根据系统资源进行设置。如Runtime.getRuntime().availableProcessors()

newScheduledThreadPool

建立一个定长线程池，支持定时及周期性任务执行

newSingleThreadExecutor

建立一个单线程化的线程池，它只会用惟一的工做线程来执行任务，保证全部任务按照指定顺序(FIFO, LIFO, 优先级)执行

线程池原理

提交一个任务到线程池中，线程池的处理流程以下：
一、判断线程池里的核心线程是否都在执行任务，若是不是（核心线程空闲或者还有核心线程没有被建立）则建立一个新的工做线程来执行任务。若是核心线程都在执行任务，则进入下个流程。
二、线程池判断工做队列是否已满，若是工做队列没有满，则将新提交的任务存储在这个工做队列里。若是工做队列满了，则进入下个流程。
三、判断线程池里的线程是否都处于工做状态，若是没有，则建立一个新的工做线程来执行任务。若是已经满了，则交给饱和策略来处理这个任务。

合理配置线程池

• CPU密集

CPU密集的意思是该任务须要大量的运算，而没有阻塞，CPU一直全速运行。
CPU密集任务只有在真正的多核CPU上才可能获得加速(经过多线程)，而在单核CPU上，不管你开几个模拟的多线程，该任务都不可能获得加速，由于CPU总的运算能力就那些。

• IO密集

IO密集型，即该任务须要大量的IO，即大量的阻塞。在单线程上运行IO密集型的任务会致使浪费大量的CPU运算能力浪费在等待。因此在IO密集型任务中使用多线程能够大大的加速程序运行，即时在单核CPU上，这种加速主要就是利用了被浪费掉的阻塞时间

要想合理的配置线程池的大小，首先得分析任务的特性，能够从如下几个角度分析：

1. 任务的性质：CPU密集型任务、IO密集型任务、混合型任务。
2. 任务的优先级：高、中、低。
3. 任务的执行时间：长、中、短。
4. 任务的依赖性：是否依赖其余系统资源，如数据库链接等。

性质不一样的任务能够交给不一样规模的线程池执行。
对于不一样性质的任务来讲，CPU密集型任务应配置尽量小的线程，如配置CPU个数+1的线程数，IO密集型任务应配置尽量多的线程，由于IO操做不占用CPU，不要让CPU闲下来，应加大线程数量，如配置两倍CPU个数+1，而对于混合型的任务，若是能够拆分，拆分红IO密集型和CPU密集型分别处理，前提是二者运行的时间是差很少的，若是处理时间相差很大，则不必拆分了。
若任务对其余系统资源有依赖，如某个任务依赖数据库的链接返回的结果，这时候等待的时间越长，则CPU空闲的时间越长，那么线程数量应设置得越大，才能更好的利用CPU。
固然具体合理线程池值大小，须要结合系统实际状况，在大量的尝试下比较才能得出，以上只是前人总结的规律。

最佳线程数目 = （（线程等待时间+线程CPU时间）/线程CPU时间 ）* CPU数目
好比平均每一个线程CPU运行时间为0.5s，而线程等待时间（非CPU运行时间，好比IO）为1.5s，CPU核心数为8，那么根据上面这个公式估算获得：((0.5+1.5)/0.5)*8=32。这个公式进一步转化为：
最佳线程数目 = （线程等待时间与线程CPU时间之比 + 1）* CPU数目
能够得出一个结论：
线程等待时间所占比例越高，须要越多线程。线程CPU时间所占比例越高，须要越少线程。
以上公式与以前的CPU和IO密集型任务设置线程数基本吻合。
CPU密集型时，任务能够少配置线程数，大概和机器的cpu核数至关，这样可使得每一个线程都在执行任务
IO密集型时，大部分线程都阻塞，故须要多配置线程数，2*cpu核数
操做系统之名称解释：
某些进程花费了绝大多数时间在计算上，而其余则在等待I/O上花费了大可能是时间，
前者称为计算密集型（CPU密集型）computer-bound，后者称为I/O密集型，I/O-bound。

自定义线程池

• 代码

@RequestMapping("test-threadpool")
    public void testThreadPool() {
        ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(1,
                6,
                60L,
                TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(3));

        for (int i = 0; i < 6; i++) {
            TaskThred t1 = new TaskThred("任务" + i);
            threadPoolExecutor.execute(t1);
        }
        threadPoolExecutor.shutdown();
    }

class TaskThred implements Runnable {
    private String taskName;

    public TaskThred(String taskName) {
        this.taskName = taskName;
    }

    @Override
    public void run() {
        System.out.println(Thread.currentThread().getName()+taskName);
    }

}

• 结果

pool-1-thread-2任务4pool-1-thread-1任务0pool-1-thread-1任务1pool-1-thread-1任务2pool-1-thread-1任务3pool-1-thread-3任务5