ThreadPoolExecutor(一) 入门

缘起

当我在阅读 Spring  使用 Callable 对象作为返回值，实现 Spring MVC 的请求异步处理。

---

Spring MVC 3.2 introduced Servlet 3 based asynchronous request processing. Instead of returning a value, as usual, a controller method can now return a java.util.concurrent.Callable and produce the return value from a separate thread. Meanwhile the main Servlet container thread is released and allowed to process other requests. Spring MVC invokes the Callable in a separate thread with the help of a TaskExecutor and when the Callable returns, the request is dispatched back to the Servlet container to resume processing with the value returned by the Callable. Here is an example controller method:

文档中提到 Spring 时通过 TaskExecutor 去处理 Callable 对象，而 TaskExecutor 的实现类 ThreadPoolTaskExecutor 又基于 j.u.c下 的 ThreadPoolExecutor，那么我先简单的认为就是通过ThreadPoolExecutor来处理这些异步请求。

猜想问题：如果请求速度大于处理速度，瓶颈会在哪里？

ThreadPoolExecutor 是什么？

在了解一个概念、实物，应该首先想到，这玩意儿是什么 —— 小贱 本人如是说

JDK 说明如下：An ExecutorService that executes each submitted task using one of possibly several pooled threads, normally configured using Executors factory methods.

原来是一个实现了 ExecutorService 接口的线程池，通常是通过 Executors 的工厂方法 返回你想要的 线程池。本能的理解线程池就是管理一堆线程的池子，然后呢？要更透彻的理解一个事物的存在，那我觉得是从它解决了什么问题来理解比较接地气。

线程池的作用是什么？

---

1、执行任务：这里的任务是针对关键词 task 来描述的，所以在接口如 submit 接收参数有很多类型的 task，如 Runnable，Callable，这个是最最基本的功能， 不然就没有存在的意义了。

2、控制线程数：如果系统共存的线程数太多，虽然不是很了解，但个人感觉不是一个好的征兆，比如线程切换的开销在线程数太多的时候是不能被忽视了…… 当然，这个是看业务场景的，如果业务不会有频繁调用，new Thread 也能接受，但这个不是线程池要解决的问题。

3、复用线程，减少线程的创建、销毁开销：当业务访问量比较低的时候，每次访问创建一个线程，其实创建、销毁线程的开销并不是一个必须解决的问题，尤其是任务处理需要特别久的时候，这里也不是线程池要解决的问题。当业务访问量达到一定量的时候，如 QPS 1K，每次处理请求耗时也很短，这里我做个简单的数学假设：

         T1 = 线程创建的时间， T2 = 线程执行任务的时间， T3 = 线程销毁的时间。

非复用线程的处理时间： T1 + T2 + T3

复用线程的处理时间： T2

试想，如果 T2 的时间和 T1、T3接近，或者小于，那么复用的意义就非常大了。

到目前为止，我认为对 ThreadPoolExecutor 算是入门了，因为我们可以根据 ThreadPoolExecutor 的作用粗略判断是否可用，用在什么地方了。至于使用的代码例子，我相信网上一搜一大波，后续小贱想稍微深入理解一下这个线程池机制，比如说 keepAliveTime，存放 Task 的 BlockingQueue 等。如有理解上的出入，欢迎拍砖吐槽，不要怜惜我！

后续我打算解读 ThreadPoolExecutor 的 官方文档，并加入一些自己的见解。