面试官问，线程池是如何处理内部任务的？

阿粉有点惊叹最近的面试题，因为从之前的基础的面试题，到之后的一些涉及到分布式和微服务的面试题，再到现在的线程池的一些面试题，反正不同的面试官，就有不同的针对方向，可能现在的面试官比较想考验你的多方面的能力吧，而最近，一个读者就反馈给了阿粉说，面试官全程就从线程这块入手，整的自己有点尴尬，但是好在有惊无险的入职了，我们来看看面试官都问了什么内容？

进程和线程的概念，你能说一下自己的理解么？
这个问题，有点基础，不过肯定是之后的开胃小菜。

进程就是应用程序在内存中分配的空间，也就是正在运行的程序，各个进程之间互不干扰。同时进程保存着程序每一个时刻运行的状态。

让一个线程执行一个子任务，这样一个进程就包含了多个线程，每个线程负责一个单独的子任务。

进程是一个独立的运行环境，而线程是在进程中执行的一个任务。他们两个本质的区别是是否单独占有内存地址空间及其它系统资源（比如I/O）

总得来说就是，线程是属于进程中的一个任务，应该算是包含的关系。

进程是操作系统进行资源分配的基本单位，而线程是操作系统进行调度的基本单位。

多进程的方式也可以实现并发，为什么我们要使用多线程？
这个问题就有意思了，你如果不是很了解的话，这个问题还真不好回答。

多进程方式确实可以实现并发，但使用多线程，是比多进程有好处的。

1.进程间的通信比较复杂，而线程间的通信比较简单，通常情况下，我们需要使用共享资源，这些资源在线程间的通信比较容易。

2.进程是重量级的，而线程是轻量级的，故多线程方式的系统开销更小。

资源浪费属于一方面的，通信简单也是另外一方面的，就凭借这两点的内容，还能选择多进程？

你在工作中使用过线程池么？为什么使用线程池？
这个问题有点尴尬，为什么这么说？

如果你说你没用过，那你这在面试官这里就相当于只写 CRUD 的逻辑业务了，也不整点其他的内容。

如果你说你用过，你就得回答接下来的一系列关于线程池的问题了。这个阿粉还是推荐，实话实话，就算你没用过，那么也别瞎扯，不然你这给自己挖的坑，肯定自己得跳下去。

那么我们就从为什么使用线程池来入手分析呗。

首先我们就要思考一件事，不使用线程池的话，创建线程有什么弊端么？

在java中，如果每个请求到达就创建一个新线程，那对服务器的资源消耗是不是有点大，创建线程，销毁线程，创建线程，销毁线程，然后再各种线程之间来回的切换，这一来一回，是不是感觉资源浪费就体现出来了。

那么线程池会避免这个情况么？

这就出来了优点1了

   ●   创建/销毁线程需要消耗系统资源，线程池可以复用已创建的线程。
虽然这个优点很明确，但是还不是主要原因，主要原因如下：

   ●   控制并发的数量。并发数量过多，可能会导致资源消耗过多，从而造成服务器崩溃。（主要原因）
   ●   可以对线程做统一管理
分析一下线程池的原理
Java中的线程池顶层接口是Executor接口，但是使用的肯定不是这个，是 ThreadPoolExecutor

我们看看 ThreadPoolExecutor 构造函数

public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue) {
        this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
             Executors.defaultThreadFactory(), defaultHandler);
    }

 

竟然参数这么多，分别都代表什么意思呢？

int corePoolSize：该线程池中核心线程数最大值。

int maximumPoolSize：该线程池中线程总数最大值。

long keepAliveTime：非核心线程闲置超时时长。

TimeUnit unit：keepAliveTime的单位。

BlockingQueue workQueue：阻塞队列，维护着等待执行的Runnable任务对象。

corePoolSize核心线程最大值：这个值怎么确定？

一般这个问题是相对来说比较棘手的，如果面试官问这个问题，那一般的同学肯定头大，我知道啥意思，但是这个怎么设置，我怎么定义呢？

其实有个计算公式：

最佳线程数目 = （（线程等待时间+线程CPU时间）/线程CPU时间 ）* CPU数目

            = （线程等待时间与线程CPU时间之比 + 1）* CPU数目

线程等待时间所占比例越高，需要越多线程。线程CPU时间所占比例越高，需要越少线程

maximumPoolSize :线程池中线程总数最大值

这个值实际上就是 核心线程数 + 非核心线程数量

keepAliveTime: 这个值如果设定了，那么非核心线程如果处于闲置状态超过该值，就会被销毁。

BlockingQueue:阻塞队列

看样子感觉像 MQ 里面的东西，想到队列，我们就又能联想到生产者和消费者，这时候就出现了个问题，为什么要有阻塞队列呢？

是不是就出现了消费者模式，生产者一直生产资源，消费者一直消费资源，资源存储在一个缓冲池中。

我们在实现这个模式的时候，多个线程操作共享变量，于是就带来了线程安全性的问题，造成重复消费和死锁，这时候阻塞队列就出现了，当缓冲池空了，我们需要阻塞消费者，唤醒生产者；当缓冲池满了，我们需要阻塞生产者，唤醒消费者。

而BlockingQueue提供了线程安全的队列访问方式，并发包下很多高级同步类的实现都是基于BlockingQueue实现的。

也就是说，你就只负责生产和消费，安全问题，JDK 来给你保证。

说到这里，我们不在继续往下延伸了，等下次阿粉直接在吧 BlockingQueue 完全的分析一波，应为 BlockingQueue 绝对得需要一个长篇的内容才能解释清楚。

分析完里面的参数，这时候，就得来看看线程池是怎么处理线程任务的，不然那怎么和面试官battle。

线程池是如何处理内部的线程任务的

public void execute(Runnable command) {
        if (command == null)
            throw new NullPointerException();
       int c = ctl.get();
       // 1.当前线程数小于corePoolSize,则调用addWorker创建核心线程执行任务
            if (workerCountOf(c) < corePoolSize) {
                if (addWorker(command, true))
                    return;
                c = ctl.get();
            }
            // 2.如果不小于corePoolSize，则将任务添加到workQueue队列。
            if (isRunning(c) && workQueue.offer(command)) {
                int recheck = ctl.get();
                //如果isRunning返回false(状态检查)，则remove这个任务，然后执行拒绝策略。
                if (! isRunning(recheck) && remove(command))
                    reject(command);
                    //线程池处于running状态，但是没有线程，则创建线程
                else if (workerCountOf(recheck) == 0)
                    addWorker(null, false);
            }
            //如果放入workQueue失败，则创建非核心线程执行任务，
            //如果这时创建非核心线程失败(当前线程总数不小于maximumPoolSize时)，就会执行拒绝策略。
            else if (!addWorker(command, false))
                reject(command);
}         

在 execute 方法中，ctl.get()是获取线程池状态。

流程图如下：

总结流程实际上就是三个阶段的判断

1，首先线程池判断基本线程池是否已满，如果要是没满，创建一个工作线程来执行任务。满了，则进入下个流程。

2，其次线程池判断工作队列是否已满？如果要是没满，则将新提交的任务存储在工作队列里。满了，则进入下个流程。

3，最后线程池判断整个线程池是否已满，如果要是没满，则创建一个新的工作线程来执行任务，满了，则交给饱和策略来处理这个任务。

这样你还会怕面试官问线程池么？

本文转载自公众号Java极客技术