Java线程池基础扫盲

前言

几乎每一次的求职面试都有被问到Java线程池，问题也是各种各样，五花八门。

“谈谈你对Java线程池的认识”

“Java线程池了解吗”

“项目中有用到线程池吗？怎么用的（管你用没用到，你得给我说出个一二三）”

“Java自带的线程池有几种？具体说说这几种线程池的特性”

“如果你设计一个线程池，你会怎么设计”

......

万变不离其宗，搞清楚线程池的原理，就能漂亮的回答这些问题了。

线程池

顾名思义就是把一堆线程放到一个池子里面去。使用线程执行一个任务的时候不需要创建直接从池子里面拿一个，用完之后不需要释放线程，直接放回池子里就可以了。这样带来的好处有：

• 线程复用
• 避免了线程创建和销毁的性能开销
• 线程的创建和具体任务的执行是完全分开的

Java自JDK1.5以后便推出了创建线程池的几种方式，根据不同的场景要求可以创建不同的线程池：

创建线程池

查看这三个方法的源码：

FixedThreadPool:

FixedThreadPool

SingleThreadPool:

SingleThreadPool

CachedThreadPool:

CachedThreadPool

实际上都是通过ThreadPoolExecutor这个类来创建的。点击查看ThreadPoolExecutor源码查看这个构造方法：

可以看到这里面有几个核心参数：

• corePoolSize：线程池的基本大小
• maximumPoolSize：可创建最大线程数
• keepAliveTime：线程空闲存活时间，时间单位为unit
• workQueue：用于存放任务的阻塞队列
• threadFactory：用于创建线程的工厂
• handler：线程池和队列都满了之后的任务处理策略

问题：核心线程池的大小配置多少合适？

这个问题经过各位前辈大佬的各种测试，总结出来如下两条经验：

1. IO密集型任务：2*CPU数，因为IO密集型任务，线程不是一直在运行，所以可以配置多一点；
2. CPU密集型任务：因为一直在使用CPU，所以要保证线程数不能太多，可以CPU数+1；

实际使用过程中，如果不好判断，可以基于这两个数字进行压测，比较得出最佳配置。

问题：handler处理策略都有哪些？

当线程池满了并且队列已经满了，这个时候线程池是无法处理和接收任务的，因此就有处理新进来的任务策略：

1. AbortPolicy：默认的策略，直接拒绝，抛出RejectedExecutionException异常；
2. CallerRunsPolicy：新任务交给任务发起者自己执行；
3. DiscardPolicy：新任务直接抛弃，无任何反应；
4. DiscardOldestPolicy：从队列里面抛弃head的一个任务，并再次执行此任务；
5. 自定义策略：实现RejectedExecutionHandler这个接口类就可以了。

任务处理策略

使用线程池的正确姿势

那是不是我们想用线程池的时候，直接这样就可以了呢：

创建一个线程池

显然这是不可以的，首先这个线程池千万不能在方法里面直接new，不然会把你机器的内存慢慢吃没的。因为每一次的创建线程池都没有得到正确的释放，即使这个方法结束了。

那是不是直接当做类变量就可以了？这样也是不行的。阿里巴巴《Java开发手册》已经做了明确的说明：

下面是在springBoot应用中如何创建并使用线程池（经过生产环境压测验证）：

继承ThreadPoolTaskExecutor，这个类是spring框架实现的线程池，把ThreadPoolExecutor当做自己的属性来用了，本质上是一样的。

定义一个全局bean：

可以看出来是在springboot框架中创建了一个线程池bean，这样在所有需要用到线程池的地方直接：

总结

Java线程池在实际业务开发中应用的场景还是很多的。比如异步调用、结合CountDownLatch提高接口的并发响应能力，也是各大公司面试中必须问的知识点。

各位在使用Java线程池的过程中有什么心得和见解呢？欢迎大家评论交流，批评指正~