为什么要用线程池
在生产中,基本不会出现手动创建并启动线程的代码,因为这样做有几个弊端:
- 频繁创建线程开销大
- 线程的数量不可控
- 线程数过多CPU来回切换开销大
那么就需要一个对线程集中管理的工具,线程池应运而生,使用线程池有如下优势:
- 减少创建新线程的时间
- 重复利用线程池中的线程,不需要每次创建
- 利用线程池可对线程进行统一的监控,分配,调优,控制最大并发数
- 实现任务线程队列缓存策略和拒绝机制
- 隔离线程环境
JDK埋的坑
JDK为了我们方便使用,提供了几种创建线程池的方法
ExecutorService executorService = Executors.newCachedThreadPool();
ExecutorService executorService = Executors.newSingleThreadExecutor();
ExecutorService executorService = Executors.newFixedThreadPool(n);
但是!这几种方法不能用!
这不是我说的,阿里规范强制要求
往下翻源码也可以看到
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue());
}
public static ExecutorService newSingleThreadExecutor() {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue()));
}
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue());
}
//这里队列的长度是Integer.MAX_VALUE,容易导致OOM
public LinkedBlockingQueue() {
this(Integer.MAX_VALUE);
}
核心类ThreadPoolExecutor
通过上面的代码也能看到,Executors的几个创建线程池的方法,底层是调用了ThreadPoolExecutor
为了避免踩坑,我们也得老老实实用ThreadPoolExecutor创建线程池
七大参数和底层工作原理
/**
* ThreadPoolExecutor参数最全的构造方法
*/
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)
数了一下,一共7个参数,那这7个参数分别代表什么?先看图
- 主线程执行execute或submit方法时,先判断核心池有没有满了,也就是判断正在执行的线程数若大于或等于corePoolSize,执行2
- 把任务放到阻塞队列中排队,若队列满了,执行3
- 临时创建新的线程,新线程的空闲时间如果超过keepAliveTime就会被销毁,而且新创建的线程数+核心池的线程数不能超过maximumPoolSize,若超过,执行4(关于这点我认为阿里的《码出高效》那本书说错了,大家可以自行查看源码)
- 执行相应的拒绝策略,拒绝执行
由此可知，这7个参数分别代表：
-
int corePoolSize核心池大小，阻塞队列未满时，最大同时执行线程数 -
int maximumPoolSize最大池大小，最大a同时执行线程数 -
long keepAliveTime最大池临时创建的新线程最大空闲时间，超过则被销毁 -
TimeUnit unit最大空闲时间单位 -
BlockingQueue阻塞队列，当核心池已满时，新提交的线程放进阻塞队列排队等候workQueue -
ThreadFactory threadFactory线程工厂，它用来生产一组相同任务的结程。线程池的命名是通过给这个 factory 增加组名前缀来实现的 -
RejectedExecutionHandler handler拒绝策略，当阻塞队列和最大池都满了的时候，对新提交的线程执行拒绝策略，jdk自带四种拒绝策略- DiscardPolicy：直接丢弃
- DiscardOldestPolicy：丢弃队列中排队时间最长的任务
- CallerRunsPolicy：将任务交给调用线程来执行
- AbortPolicy：抛异常
调优
这里说一下int maximumPoolSize参数的调优，因为maximumPoolSize是最后一道防线了，提交的线程数超过maximumPoolSize就执行拒绝策略了，所以maximumPoolSize的大小尤其重要。
CPU密集型任务
CPU密集型任务的特点是需要大量的运算，CPU全速运行，较少的IO而没有阻塞，所以对于CPU密集型任务，应该尽量减少线程切换带来的消耗，参考配置公式：
IO密集型任务
IO密集型任务刚好相反，CPU占用较少，大量的阻塞，对于这种情况，应该尽量利用CPU的空闲时间，最大线程数应该配置比CPU核心数多，参考配置公式：