Java基础之线程池

目录

线程池的原理：

线程池的使用场景：

加快处理大任务：

ThreadPoolExecutor中重要的几个参数详解

线程池中的线程创建流程图：

workQueue队列

总结

---

线程池的原理：

线程池是管理一组同构工作线程的资源池。合理利用线程池能够带来三个好处。第一：降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。第二：提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。第三：提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。但是要做到合理的利用线程池，必须对其原理了如指掌。

线程池的使用场景：

Java中经常需要用到多线程来处理一些业务，我们非常不建议单纯的使用继承Thread或者实现Runnable接口的方式来创建线程，那样势必来创建及销毁资源、线程上下文切换问题。同时创建过多的线程也可能引发资源耗尽的风险，这个时候引入线程池比较合理，线程池任务的管理。Java中涉及到线程池的相关类均在jdk1.5开始的java.util.concurrent包中，涉及到几个核心类及接口包括：Executor、Executors、ExecutorService、ThreadPoolExecutor、FutureTask、Callable、Runnable等。

加快处理大任务：

比如业务中台每10分钟就调用接口统计每个系统/项目的PV/UV等指标然后写入多个sheet页中返回，这种情况下往往也会使用多线程方式来并行统计。和"时间优先"场景不同，这种场景的关注点不在于尽可能快的返回，而是关注利用有限的资源尽可能的在单位时间内处理更多的任务，即吞吐量优先。这种场景下我们往往会设置队列来缓冲并发任务，并且设置合理的corePoolSize和maxPoolSize参数，这个时候如果设置了太大的corePoolSize和maxPoolSize可能还会因为线程上下文频繁切换降低任务处理速度，从而导致吞吐量降低。

以上两种使用场景和JVM里的ParallelScavenge和CMS垃圾收集器有较大的类比性，ParallelScavenge垃圾收集器关注点在于达到可观的吞吐量，而CMS垃圾收集器重点关注尽可能缩短GC停顿时间。

ThreadPoolExecutor中重要的几个参数详解

• corePoolSize：核心线程数，也是线程池中常驻的线程数，线程池初始化时默认是没有线程的，当任务来临时才开始创建线程去执行任务
• maximumPoolSize：最大线程数，在核心线程数的基础上可能会额外增加一些非核心线程，需要注意的是只有当workQueue队列填满时才会创建多于corePoolSize的线程(线程池总线程数不超过maxPoolSize)
• keepAliveTime：非核心线程的空闲时间超过keepAliveTime就会被自动终止回收掉，注意当corePoolSize=maxPoolSize时，keepAliveTime参数也就不起作用了(因为不存在非核心线程)；
• unit：keepAliveTime的时间单位
• workQueue：用于保存任务的队列，可以为无界、有界、同步移交三种队列类型之一，当池子里的工作线程数大于corePoolSize时，这时新进来的任务会被放到队列中
• threadFactory：创建线程的工厂类，默认使用Executors.defaultThreadFactory()，也可以使用guava库的ThreadFactoryBuilder来创建
• handler：线程池无法继续接收任务(队列已满且线程数达到maximunPoolSize)时的饱和策略，取值有AbortPolicy、CallerRunsPolicy、DiscardOldestPolicy、DiscardPolicy

线程池中的线程创建流程图：

workQueue队列

• SynchronousQueue(同步移交队列)：队列不作为任务的缓冲方式，可以简单理解为队列长度为零
• LinkedBlockingQueue(无界队列)：队列长度不受限制，当请求越来越多时(任务处理速度跟不上任务提交速度造成请求堆积)可能导致内存占用过多或OOM
• ArrayBlockintQueue(有界队列)：队列长度受限，当队列满了就需要创建多余的线程来执行任务

总结

上面的几个方面均是从仔细控制线程池的创建和销毁来进行描述。基本思路即是从对象管理，生命周期以及代码控制多个方面来处理.在实际项目中，业务使用方只需要使用相应的组件即可，但组件提供方需要正确地提供，才能保证基础架构的完整性.