从线程池理论聊聊为什么要看源码

点关注，不迷路；持续更新Java相关技术及资讯！！！

常见线程池

• SingleThreadExecutor: 单线程线程池,一般很少使用.
• FixedThreadExecutor: 固定数量线程池,这个比较常用,重点留意一下,也是本文重点
• CachedThreadExecutor: 字面翻译缓存线程池,这个也比较常用,重点留意一下,也是本文重点
• ScheduledThreadExecutor: 定时调度线程池,一般很少使用.那这里可能就有人反驳了.那为什么Dubbo源码里面的定时任务要用这个?看源码最重要的还是要看出别人的设计思想.Dubbo设计的初衷是只依赖JDK,使用他的定时任务,自然是优先选择使用这个JDK原生的API来做一个简易的定时任务.

线程池参数的意义及工作原理

public ThreadPoolExecutor(int corePoolSize,
 int maximumPoolSize,
 long keepAliveTime,
 TimeUnit unit,
 BlockingQueue<Runnable> workQueue,
 ThreadFactory threadFactory,
 RejectedExecutionHandler handler) {
 //...
}
复制代码

线程池有这么几个重要的参数

corePoolSize: 线程池里的核心线程数量

maximumPoolSize: 线程池里允许有的最大线程数量

keepAliveTime: 如果 当前线程数量 > corePoolSize，多出来的线程会在keepAliveTime之后就被释放掉

unit: keepAliveTime的时间单位,比如分钟,小时等

workQueue: 队列

threadFactory: 每当需要创建新的线程放入线程池的时候,就是通过这个线程工厂来创建的

handler: 就是说当线程,队列都满了,之后采取的策略,比如抛出异常等策略

那么我们假设来一组参数练习一下这个参数的意义

corePoolSize：1
mamximumPoolSize：3
keepAliveTime：60s
workQueue：ArrayBlockingQueue，有界阻塞队列，队列大小是4
handler：默认的策略，抛出来一个ThreadPoolRejectException复制代码

1.一开始有一个线程变量poolSize维护当前线程数量.此时poolSize=0

2.此时来了一个任务.需要创建线程.poolSize(0) < corePoolSize(1),那么直接创建线程

3.此时来了一个任务.需要创建线程.poolSize(1) >= corePoolSize(1),此时队列没满,那么就丢到队列中去

4.如果队列也满了,但是poolSize < mamximumPoolSize,那么继续创建线程

5.如果poolSize == maximumPoolSize,那么此时再提交一个一个任务,就要执行handler,默认就是抛出异常

6.此时线程池有3个线程(poolSize == maximumPoolSize(3)),假如都处于空闲状态,但是corePoolSize=1,那么就有(3-1 =2),那么这超出的2个空闲线程,空闲超过60s,就会给回收掉.

以上,就是线程池参数意义及工作原理

线程池参数设计上的思考

知道了以上的原理,那么我们看看常见的两个线程池FixedThreadExecutor和CachedThreadExecutor的参数设计

public static ExecutorService newFixedThreadPool(int nThreads) {
 return new ThreadPoolExecutor(nThreads, nThreads,
 0L, TimeUnit.MILLISECONDS,
 new LinkedBlockingQueue<Runnable>());
public static ExecutorService newCachedThreadPool() {
 return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
 60L, TimeUnit.SECONDS,
 new SynchronousQueue<Runnable>());
复制代码

那么问题来了

1.为什么FixedThreadExecutor的corePoolSize和mamximumPoolSize要设计成一样的?

2.为什么CachedThreadExecutor的mamximumPoolSize要设计成接近无限大的?

敲黑板划重点

还是前面那句话,我们看源码,并不是大段大段的源码打上注释,最重要的是经过深度思考,明白作者设计的意图,这也就是为什么市场上有这么多源码解析文章,我们依然还要关注一下肥朝(卖个萌)

如果你对上面的线程池的原理,参数有了清晰的认识,自然很快就能明白这个设计思路.

比如问题一,因为线程池是先判断corePoolSize,再判断workQueue,最后判断mamximumPoolSize,然而LinkedBlockingQueue是无界队列,所以他是达不到判断mamximumPoolSize这一步的,所以mamximumPoolSize成多少,并没有多大所谓

比如问题二:我们来看看SynchronousQueue的注释:

从我圈的这几个小学英文单词都知道,这个队列的容量是很小的,如果mamximumPoolSize不设计得很大,那么就很容易动不动就抛出异常

线程池使用上的建议

原理明白了,设计思想我们也明白了,代码要怎么写.光理论还不行,也就是说,我们在项目中,线程池究竟要怎么用?那么我们来看一下阿里手册,看到这个强制相信不用我多说什么

Dubbo线程池

那么我们来看看Dubbo官方文档,一直强调,官方文档才是最好的学习资料.

回归问题

那么回到我们前面遇到的问题.我们看了官方文档说Dubbo默认(缺省)用线程池是fixed,那么我们第一反应,从前面各种分析原理也得知了,FixedThreadPool的队列是很大的,他根本达不到第三个判断条件mamximumPoolSize,达不到第三个条件,也就不会触发handle抛出异常.那前面那个压测问题的异常怎么来的。

直入源码

这种问题.搜索是不好使了,因为根本不好搜索.那么我们只好直入源码了

@SPI("fixed")
public interface ThreadPool {
 
 /**
 * 线程池
 * 
 * @param url 线程参数
 * @return 线程池
 */
 @Adaptive({Constants.THREADPOOL_KEY})
 Executor getExecutor(URL url);
}

public class FixedThreadPool implements ThreadPool {
 public Executor getExecutor(URL url) {
 String name = url.getParameter(Constants.THREAD_NAME_KEY, Constants.DEFAULT_THREAD_NAME);
 int threads = url.getParameter(Constants.THREADS_KEY, Constants.DEFAULT_THREADS);
 int queues = url.getParameter(Constants.QUEUES_KEY, Constants.DEFAULT_QUEUES);
 return new ThreadPoolExecutor(threads, threads, 0, TimeUnit.MILLISECONDS, 
 		queues == 0 ? new SynchronousQueue<Runnable>() : 
 			(queues < 0 ? new LinkedBlockingQueue<Runnable>() 
 					: new LinkedBlockingQueue<Runnable>(queues)),
 		new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));
 }
}
复制代码

此时我们发现,Dubbo里面的FixedThreadPool和newFixedThreadPool创建出来的FixedThreadPool参数是不一样的.默认情况下,Dubbo的FixedThreadPool中,maximumPoolSize = 200,队列是容量很小的SynchronousQueue.所以当线程超过200的时候,就会抛出异常.这个和我们上面分析的原理是一致的.

其实换个角度想,规范手册都是阿里出的,阿里手册都强制说要用ThreadPoolExecutor的方式来创建了,而且还给你分析了无界队列的风险,那么Dubbo官方文档说的fixed又怎么会是Executors创建的无界队列这种呢?

知道了线程池的原理和异常的根源之后,我们完全可以根据业务特点的不同,自定义线程池参数,来避免这类异常的频繁发生.亦或者改变Dubbo默认的线程模型,从aLL改成message等,这个就要结合实际的业务情况了。

关注、转发、评论每天分享java 知识，赠送Spring源码分析、Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式资料

转载于:https://juejin.im/post/5cfdee06f265da1b897ac443