线程池是指在初始化一个多线程应用程序过程中创建一个线程集合，然后在需要执行新的任务时重用这些线程而不是新建一个线程（提高线程复用，减少性能开销）。线程池中线程的数量通常完全取决于可用内存数量和应用程序的需求。然而，增加可用线程数量是可能的。线程池中的每个线程都有被分配一个任务，一旦任务已经完成了，线程回到池子中然后等待下一次分配任务。
基于以下几个原因在多线程应用程序中使用线程池是必须的：
1. 线程池改进了一个应用程序的响应时间。由于线程池中的线程已经准备好且等待被分配任务，应用程序可以直接拿来使用而不用新建一个线程。
2. 线程池节省了CLR 为每个短生存周期任务创建一个完整的线程的开销并可以在任务完成后回收资源。
3. 线程池根据当前在系统中运行的进程来优化线程时间片。
4. 线程池允许我们开启多个任务而不用为每个线程设置属性。
5. 线程池允许我们为正在执行的任务的程序参数传递一个包含状态信息的对象引用。
6. 线程池可以用来解决处理一个特定请求最大线程数量限制问题。
本质上来讲，我们使用线程池主要就是为了减少了创建和销毁线程的次数，每个工作线程都可以被重复利用，可执行多个任务；节约应用内存（线程开的越多，消耗的内存也就越大，最后死机）
线程池作用就是限制系统中执行线程的数量。根据系统的环境情况，可以自动或手动设置线程数量，达到运行的最佳效果；少了浪费了系统资源，多了造成系统拥挤效率不高。用线程池控制线程数量，其他线程排队等候。一个任务执行完毕，再从队列的中取最前面的任务开始执行。若队列中没有等待进程，线程池的这一资源处于等待。当一个新任务需要运行时，如果线程池中有等待的工作线程，就可以开始运行了；否则进入等待队列。
说完了线程池的概念和作用，我们再看看代码中的线程池：
在Java中，线程池的代码起源之Executor（翻译过来就是执行者）注意：这个类是一个接口。
但是严格意义上讲Executor并不是一个线程池（如图其源码就一个 execute 方法），所以Executor仅只是一个执行线程的工具。那么，线程池的真正面纱是什么？利用AS的类继承关系发现，Executor有一个 ExecutorService 子接口。
实际上，一般说线程池接口，基本上说的是这个 ExecutorService。ExecutorService源码里面有各种API（比如说执行 excute ( xxx )，比如关闭 isShutdown ( )）帮助我们去使用。ExecutorService接口的默认实现类为ThreadPoolExecutor（翻译过来就是线程池执行者）。既然是默认实现类我们就可以根据应用场景去私人订制了。
既然找到了突破口，那我们集中火力先去了解下ThreadPoolExecutor
首先从ThreadPoolExecutor 的构造参数开始分析，通过代码截图得知，ThreadPoolExecutor的构造方法有以下4种：
下面就构造方法里面的参数逐一分析说明：
1：int corePoolSize （core：核心的） = > 该线程池中核心线程数最大值
什么是核心线程：线程池新建线程的时候，如果当前线程总数小于 corePoolSize ，则新建的是核心线程；如果超过corePoolSize，则新建的是非核心线程。
核心线程默认情况下会一直存活在线程池中，即使这个核心线程啥也不干(闲置状态)。
如果指定ThreadPoolExecutor的 allowCoreThreadTimeOut 这个属性为true，那么核心线程如果不干活(闲置状态)的话，超过一定时间( keepAliveTime)，就会被销毁掉
2：int maximumPoolSize = > 该线程池中线程总数的最大值
线程总数计算公式 = 核心线程数 + 非核心线程数。
3：long keepAliveTime = > 该线程池中非核心线程闲置超时时长
注意：一个非核心线程，如果不干活(闲置状态)的时长，超过这个参数所设定的时长，就会被销毁掉。但是，如果设置了 allowCoreThreadTimeOut = true，则会作用于核心线程。
4：TimeUnit unit = > （时间单位）
首先，TimeUnit是一个枚举类型，翻译过来就是时间单位，我们最常用的时间单位包括：
MILLISECONDS ： 1毫秒 、SECONDS ： 秒、MINUTES ： 分、HOURS ： 小时、DAYS ： 天
5：BlockingQueue<Runnable> workQueue = >( Blocking：阻塞的，queue：队列)
该线程池中的任务队列：维护着等待执行的Runnable对象。当所有的核心线程都在干活时，新添加的任务会被添加到这个队列中等待处理，如果队列满了，则新建非核心线程执行任务
其中，BlockingQueue中具体的API介绍：
offer(E e): 将给定的元素设置到队列中，如果设置成功返回true, 否则返回false. e的值不能为空，否则抛出空指针异常。
offer(E e, long timeout, TimeUnit unit): 将给定元素在给定的时间内设置到队列中，如果设置成功返回true, 否则返回false.
add(E e): 将给定元素设置到队列中，如果设置成功返回true, 否则抛出异常。如果是往限定了长度的队列中设置值，推荐使用offer()方法。
put(E e): 将元素设置到队列中，如果队列中没有多余的空间，该方法会一直阻塞，直到队列中有多余的空间。
take(): 从队列中获取值，如果队列中没有值，线程会一直阻塞，直到队列中有值，并且该方法取得了该值。
poll(long timeout, TimeUnit unit): 在给定的时间里，从队列中获取值，如果没有取到会抛出异常。
remainingCapacity()：获取队列中剩余的空间。
remove(Object o): 从队列中移除指定的值。
contains(Object o): 判断队列中是否拥有该值。
drainTo(Collection c): 将队列中值，全部移除，并发设置到给定的集合中。
说完了BlockingQueue常用的API，在说说其常用的workQueue类型：
一般来说，workQueue有以下四种队列类型：
SynchronousQueue：（同步队列）这个队列接收到任务的时候，会直接提交给线程处理，而不保留它（名字定义为 同步队列）。但有一种情况，假设所有线程都在工作怎么办？
这种情况下，SynchronousQueue就会新建一个线程来处理这个任务。所以为了保证不出现（线程数达到了maximumPoolSize而不能新建线程）的错误，使用这个类型队列的时候，maximumPoolSize一般指定成Integer.MAX_VALUE，即无限大，去规避这个使用风险。
LinkedBlockingQueue（链表阻塞队列）：这个队列接收到任务的时候，如果当前线程数小于核心线程数，则新建线程(核心线程)处理任务；如果当前线程数等于核心线程数，则进入队列等待。由于这个队列没有最大值限制，即所有超过核心线程数的任务都将被添加到队列中，这也就导致了maximumPoolSize的设定失效，因为总线程数永远不会超过corePoolSize
ArrayBlockingQueue（数组阻塞队列）：可以限定队列的长度（既然是数组，那么就限定了大小），接收到任务的时候，如果没有达到corePoolSize的值，则新建线程(核心线程)执行任务，如果达到了，则入队等候，如果队列已满，则新建线程(非核心线程)执行任务，又如果总线程数到了maximumPoolSize，并且队列也满了，则发生错误
DelayQueue（延迟队列）：队列内元素必须实现Delayed接口，这就意味着你传进去的任务必须先实现Delayed接口。这个队列接收到任务时，首先先入队，只有达到了指定的延时时间，才会执行任务
说完了BlockingQueue，继续回到ThreadPoolExecutor的构造参数上面
6：ThreadFactory threadFactory = > 创建线程的方式，这是一个接口，new它的时候需要实现他的Thread newThread(Runnable r)方法
7：RejectedExecutionHandler handler = > 这个主要是用来抛异常的
当线程无法执行新任务时（一般是由于线程池中的线程数量已经达到最大数或者线程池关闭导致的），默认情况下，当线程池无法处理新线程时，会抛出一个RejectedExecutionException。
构造参数基本上就介绍完毕了。
（如果看累了就先休息下。。。内容的确较多。。。）
花了这么大篇幅去介绍ThreadPoolExecutor这个类的构造函数，可能你会觉得好累好空虚，好吧，其实我们的付出都是为打通线程池最后的壁垒做的必要准备，因为 千里之行、始于足下 ，我们始终要坚信 倘想达到最高处，就要从低处开始 。
说完了这么多，我们知道了实例化一个线程池，只需要在构造参数里面去添加自己设置的属性值（设置正确即可使用，设置错误即抛异常），这样问题就来了：
一个任务，它是如何进入线程池去执行任务？
ThreadPoolExecutor这个类，里面有一个API，在上面也随口提到过，有一个执行的方法，先上图
首先我们初始化一个线程池后，即可调用 execute这个方法，里面传入Runnable即可向线程池添加任务。
问题又来了，既然线程池新添加了任务，那么线程池是如何处理这些批量任务？
1：如果线程数量未达到corePoolSize，则新建一个线程(核心线程)执行任务
2：如果线程数量达到了corePools，则将任务移入队列等待
3：如果队列已满，新建线程(非核心线程)执行任务
4：如果队列已满，总线程数又达到了maximumPoolSize，就会由RejectedExecutionHandler抛出异常
但是，实际上，Java已经为我们提供了四种线程池！
好吧，在Java中，Executors这个类已经为我们提供了常用的四种线程池，分别为：
A：newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。
源码注释翻译：
创建一个线程池，使用固定数量的线程在共享的无界队列中操作。
在任何时候，有最多 nThreads（就是我们传入参数的数量）的线程将处理任务。
如果所有线程都处于活动状态时，提交额外的任务，他们会在队列中等待，直到有一个线程可用。
如果在执行过程中出现故障，任何线程都会终止。如果需要执行后续任务，新的任务将取代它的位置。线程池中的线程会一直存在，直到它显式为止（调用shutdown）
nThreads 就是传入线程池的数量 ，当nThreads <= 0 就会抛异常IllegalArgumentException
B：newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。
源码注释翻译：
创建一个线程池，根据需要创建新线程，但是将重写之前线程池的构造。
这个线程池通常会提高性能去执行许多短期异步任务的程序。
如果有可用线程，当线程池调用execute， 将重用之前的构造函数。
如果没有现有的线程可用，那么就创建新的线程并添加到池中。
线程没有使用60秒的时间被终止并从线程池里移除缓存。
因此，一个闲置时间足够长的线程池不消耗任何资源。
注意，线程池有类似的属性，但有一些不同的细节（例如，超时参数）可以使用@link ThreadPoolExecutor构造函数创建。
C：newScheduledThreadPool 创建一个定长任务线程池，支持定时及周期性任务执行。
源码注释翻译：
创建一个线程池，它可以安排在 a 之后运行的命令给定延迟，或定期执行。
corePoolSize （这个参数） 是指在池中保留的线程数，即使它们是空闲的。这个函数最终会返回一个新创建的调度线程池
如果 corePoolSize < 0 ，则会抛出 IllegalArgumentException
Ps：这个还支持多传入一个ThreadFactory
D：newSingleThreadExecutor 创建一个单线程的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。
源码注释翻译：
创建一个线程执行器，它使用单个运行中的线程操作在一个无界队列中。
请注意，如果这个单独的线程终止是因为在执行前异常或者终止，若需要执行后续的任务，那么就需要一个新的去替代它。
任务被保证按顺序的执行，并且在任何给定的时间内不超过一个任务将是活动的。
不像其他等价 newFixedThreadPool(1) 这个返回的线程池对象是保证不运行重新配置以使用额外的线程。
最终返回的是一个重新创建的单线程去执行。
总结：
Java为我们提供的四种线程池基本上就介绍完毕了。可以看到，这四种每一个具体的线程池都是 跟 ThreadPoolExecutor 配置有关的。因此，前面花大篇幅介绍ThreadPoolExecutor的构造参数在这里就起到了作用，整体来说，线程池的基本概念就结束了。
下面上一份伪代码加深理解
好了，说完了这么多，我们在回归到Android上面，在Android里面，线程池的应用场景是什么？这个问题面试也经常问（面试常规套路就是，先让你回答Java的某一个知识概念，在让你谈这一知识概念在Android的应用场景）常见的有异步任务栈，（AsyncTask）其内部就是使用到了线程池，关于异步任务栈的线程池这个网上资料就很多了这里就不多说了，我们今天就用上面的概念简单分析讨论下OkHttp这一经典网络框架的内置线程池。
Okhttp的常用写法如下：
配置好请求体，url之后，我们会使用 OkHttpClient这个对象首先去调用 newCall，也就是上图红色的框框，点进去这个newCall
这个方法返回了一个RealCall，翻译过来就是 （真正的请求），点进去看下RealCall
所以，本质上来讲 OkHttpClient.newCall(request).enqueue()， 其实就是调用 RealCall 类里面的 enqueue 方法。如下图
黄色框框里面可以看到，这个方法最终调用的是 client.dispatcher().enqueue，这个方法内部引用了AsyncCall这个对象，那这AsyncCall又是什么？
点击AsyncCall后发现，原来，AsyncCall 是 RealCall 的一个内部类（位于：RealCall 源码 124行）
可能你会问， NamedRunnable 这个类又是什么？点进 NamedRunnable后发现，这个类的本质其实就是一个 Runnable
好了，言归正传我们再回到client.dispatcher().enqueue这个方法，点击 enqueue ，进入到了Dispatcher 这个类里面的enqueue方法（Dispatcher 翻译过来就是：调度员、分配器）
是不是惊奇的看见了executorService（）.execute（call），是不是感觉有点类似线程池的写法（关于 ExecutorService 这个是文章前面说到的；还有，AsyncCall本质就是一个Runnable对象，线程池里面的execte方法里需要的就是一个Runnable对象），我们继续点击 executorService（）这个方法内，看看其庐山真面目
好家伙，是不是看到了熟悉的线程池。如果只是为了应付面试让自己有个概念，看到这里基本上就可以了。因为接下来就开始深挖OkHttp内部线程池细节，内容有点绕，如果愿意深挖的就请继续耐心看完下面的内容。
既然，Okhttp在这里帮我们创建了一个线程池。那么这个线程池是怎么处理的？通过源码得知，构造参数里面有一个SynchronousQueue （同步），这个在上面的构造参数里面也分析过，这个队列接收到任务的时候，会直接提交给线程处理，而且也提到使用这个队列的话，maximumPoolSize一般指定成Integer.MAX_VALUE，即无限大去规避使用风险，在这里，OkHttp的源码也使用到了无限大。
我们知道，okhttp发起请求的步骤真正的执行是在RealCall这个类里面，里面的enqueue方法调用了
client.dispatcher().enqueue(new AsyncCall(responseCallback)) ;（也就是下图第100行）
因此我们在看回去 Dispatcher这个类里面的enqueue方法：
这三个集合简单介绍下：
private final Deque readyAsyncCalls = new ArrayDeque<>() ; // 正在准备中的异步请求队列
private final Deque running AsyncCalls = new ArrayDeque<>(); //运行中的异步请求
private final Deque runningSyncCalls = new ArrayDeque<>(); // 同步请求
拓展：Deque 这个类是什么？简单理解，这个Deque它是Queue的子接口，我们知道Queue是一种队列形式，而Deque则是双向队列，它支持从两个端点方向检索和插入元素（也就是头部和尾部加入元素）
我们继续看下enqueue方法：
在这里有个判断，如果 (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) 如果这个条件不成立的时候，要把任务放在 readyAsyncCalls 里。
问题来了，那么什么时候去取这里的任务来执行呢？
为了解决这个问题，我们需要在回到AsyncCall这个类一探究竟，
AsyncCall - 1图中，截图了三种不同颜色的矩形，是不是感觉红色和绿色矩形对应的两个方法很熟悉，
responseCallback.onFailure （）实际上就是失败的回调
responseCallback.onResponse （）实际上就是成功的回调，将蓝色矩形的Response对象回调出去。
那么蓝色矩形里面的代码是什么意思？getResponseWithInterceptorChain（）这个方法具体是做什么的？继续点进源码看看
哦，这个方法就是遍历外部定义的拦截器 然后添加OkHttp内部的拦截器去发起真正的请求。拦截器的本质就是拦截请求体，拦截响应体，在拦截的过程中添加信息和修改信息，比如添加请求头等等。由于这个方法涉及到拦截器的源码实在是太多了，想要细看的朋友可以在网上自行查阅资料。所以这里就点到为止。
可以看到，这个方法最终返回了一个Response对象。
回到上面那副AsyncCall - 1图，其中红色和绿色矩形的源码，对应的就是下图OkHttp常规写法，通过接口回调将Response结果，告知调用者，蓝色矩形的response的body，就是我们请求成功之后获取的响应体。
我们看到AsyncCall - 2图中， finally 里面有个结束的处理，也就是 client.dispatcher().finished(this) 这个方法，尝试点进去看
进入到finished方法之后，发现回到了Dispatch这个类里面。这个finished方法 里面貌似能看的，就 promoteCalls 方法和runningCallsCount方法，我们首先看看runningCallsCount方法
发现这个方法其实返回的就是长度（返回值就是int嘛），这不是我们想要的结果。所以继续回到上一步，点击promoteCalls 方法点进去看看
哦，是不是终于看到了 executorService().execute(call) ，将任务添加到线程池里面的具体代码。
这个方法的主要功能是，首先遍历 readyAsyncCalls，把任务取出来；把取出来的任务加入 到runningAsyncCalls；最后， 把任务放入线程池。原来把任务添加到线程池是在Dispatcher这里进行的。(这个类内部不仅创建了线程池，也将任务添加了进来)
总体来说，当请求任务数大于 maxRequests 并且相同 host 最大请求数大于 maxRequestsPerHost，就会把请求任务放在 readyAsyncCalls 队列里；当线程池里执行任务的 runnable 执行完任务在最后会检查 readyAsyncCalls 里有没有任务，如果有任务并且是同一个 host 就放入到线程池中执行。因此通过这个方法不断地从 readyAsyncCalls 队列里取出任务，对线程池里的线程进行复用。
关于Okhttp内置线程池和部分源码的分析就写到这里了，希望对开发者有一点点小帮助吧。如果面试官在问到线程池在Android的实际应用的时候，我们除了说异步任务栈（面试官可能也准备好了异步任务栈让你入坑跟你讨论其内部细节），可以直接跟他谈OkHttp框架内部如何创建线程池、如何将任务添加到线程池等具体的内部实现流程。
参考资料：https://www.jianshu.com/p/210eab345423
参考资料：https://www.cnblogs.com/miller-zou/p/6978533.html
原文：https://www.cnblogs.com/aaaazzzz/p/12842390.html