有点惊叹最近的面试题，因为从之前的基础的面试题，到之后的一些涉及到分布式和微服务的面试题，再到现在的线程池的一些面试题，反正不同的面试官，就有不同的针对方向，可能现在的面试官比较想考验你的多方面的能力吧，而最近，一个读者就反馈说，面试官全程就从线程这块入手，整的自己有点尴尬，但是好在有惊无险的入职了，我们来看看面试官都问了什么内容？
进程和线程的概念，你能说一下自己的理解么？这个问题，有点基础，不过肯定是之后的开胃小菜。
进程和线程的关系
进程就是应用程序在内存中分配的空间，也就是正在运行的程序，各个进程之间互不干扰。同时进程保存着程序每一个时刻运行的状态。
让一个线程执行一个子任务，这样一个进程就包含了多个线程，每个线程负责一个单独的子任务。
进程是一个独立的运行环境，而线程是在进程中执行的一个任务。他们两个本质的区别是是否单独占有内存地址空间及其它系统资源（比如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，最后线程池判断整个线程池是否已满，没满，则创建一个新的工作线程来执行任务，满了，则交给饱和策略来处理这个任务。
如果你能把这些在面试的时候说清楚，那么至少在线程池这个知识点上，你是没有任何问题了，这样就可以愉快并且开心的走下一个知识点了。
