【高并发】关于线程池，蚂蚁金服面试官问了我这些内容！！

﹏ヽ暗。殇╰゛Y 2021-09-01 03:23 334阅读 0赞

## 写在前面 ##

> 最近，一名读者去蚂蚁金服面试，面试官问了他关于乐观锁和悲观锁的问题，幸亏他看了我的【[高并发专题][Link 1]】文章，结果是替这名读者高兴！现就部分面试题目总结成文，供小伙伴们参考。
> 
> 小伙伴们可以关注 冰河技术 微信公众号来学习【高并发专题】，学习超硬核知识技能，跳槽大厂，升级加薪，指日可待！

## 面试汇总 ##

### Java中的线程池是如何实现的？ ###

在Java中，所谓的线程池中的“线程”，其实是被抽象为了一个静态内部类Worker，它基于AQS实现，存放在线程池的HashSetworkers成员变量中；而需要执行的任务则存放在成员变量workQueue（BlockingQueueworkQueue）中。这样，整个线程池实现的基本思想就是、从workQueue中不断取出需要执行的任务，放在Workers中进行处理。

### 创建线程池的几个核心构造参数？ ###

Java中的线程池的创建其实非常灵活，我们可以通过配置不同的参数，创建出行为不同的线程池，这几个参数包括：

*  corePoolSize：线程池的核心线程数。
 *  maximumPoolSize：线程池允许的最大线程数。
 *  keepAliveTime：超过核心线程数时闲置线程的存活时间。
 *  workQueue：任务执行前保存任务的队列，保存由execute方法提交的Runnable任务。

### 线程池中的线程是怎么创建的？是一开始就随着线程池的启动创建好的吗？ ###

显然不是的。线程池默认初始化后不启动Worker，等待有请求时才启动。每当我们调用execute()方法添加一个任务时，线程池会做如下判断：

如果正在运行的线程数量小于corePoolSize，那么马上创建线程运行这个任务；

如果正在运行的线程数量大于或等于corePoolSize，那么将这个任务放入队列；

如果这时候队列满了，而且正在运行的线程数量小于maximumPoolSize，那么还是要创建非核心线程立刻运行这个任务；

如果队列满了，而且正在运行的线程数量大于或等于maximumPoolSize，那么线程池会抛出异常RejectExecutionException。

当一个线程完成任务时，它会从队列中取下一个任务来执行。当一个线程无事可做，超过一定的时间（keepAliveTime）时，线程池会判断。如果当前运行的线程数大于corePoolSize，那么这个线程就被停掉。所以线程池的所有任务完成后，它最终会收缩到corePoolSize的大小。

### 既然提到可以通过配置不同参数创建出不同的线程池，那么Java中默认实现好的线程池又有哪些呢？请比较它们的异同。 ###

（1）SingleThreadExecutor线程池这个线程池只有一个核心线程在工作，也就是相当于单线程串行执行所有任务。如果这个唯一的线程因为异常结束，那么会有一个新的线程来替代它。此线程池保证所有任务的执行顺序按照任务的提交顺序执行。

corePoolSize：1，只有一个核心线程在工作。
    maximumPoolSize：1。
    keepAliveTime：0L。
    workQueue：newLinkedBlockingQueue<Runnable>()，其缓冲队列是无界的。

（2）FixedThreadPool线程池

FixedThreadPool是固定大小的线程池，只有核心线程。每次提交一个任务就创建一个线程，直到线程达到线程池的最大大小。线程池的大小一旦达到最大值就会保持不变，如果某个线程因为执行异常而结束，那么线程池会补充一个新线程。FixedThreadPool多数针对一些很稳定很固定的正规并发线程，多用于服务器。

corePoolSize：nThreads
    maximumPoolSize：nThreads
    keepAliveTime：0L
    workQueue：newLinkedBlockingQueue<Runnable>()，其缓冲队列是无界的。

（3）CachedThreadPool线程池CachedThreadPool是无界线程池，如果线程池的大小超过了处理任务所需要的线程，那么就会回收部分空闲（60秒不执行任务）线程，当任务数增加时，此线程池又可以智能的添加新线程来处理任务。

线程池大小完全依赖于操作系统（或者说JVM）能够创建的最大线程大小。SynchronousQueue是一个是缓冲区为1的阻塞队列。  
缓存型池子通常用于执行一些生存期很短的异步型任务，因此在一些面向连接的daemon型SERVER中用得不多。但对于生存期短的异步任务，它是Executor的首选。

corePoolSize：0
    maximumPoolSize：Integer.MAX_VALUE
    keepAliveTime：60L
    workQueue：newSynchronousQueue<Runnable>()，一个是缓冲区为1的阻塞队列。

（4）ScheduledThreadPool线程池ScheduledThreadPool、核心线程池固定，大小无限的线程池。此线程池支持定时以及周期性执行任务的需求。创建一个周期性执行任务的线程池。如果闲置，非核心线程池会在DEFAULT\_KEEPALIVEMILLIS时间内回收。

corePoolSize：corePoolSize
    maximumPoolSize：Integer.MAX_VALUE
    keepAliveTime：DEFAULT_KEEPALIVE_MILLIS
    workQueue：newDelayedWorkQueue()

5、如何在Java线程池中提交线程？

线程池最常用的提交任务的方法有两种：

*  execute()、ExecutorService.execute方法接收一个Runable实例，它用来执行一个任务。
 *  submit()、ExecutorService.submit()方法返回的是Future对象。可以用isDone()来查询Future是否已经完成，当任务完成时，它具有一个结果，可以调用get()来获取结果。也可以不用isDone()进行检查就直接调用get()，在这种情况下，get()将阻塞，直至结果准备就绪。Java内存模型相关问题

### 什么是Java的内存模型，Java中各个线程是怎么彼此看到对方的变量的？ ###

Java的内存模型定义了程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出这样的底层细节。此处的变量包括实例字段、静态字段和构成数组对象的元素，但是不包括局部变量和方法参数，因为这些是线程私有的，不会被共享，所以不存在竞争问题。

**Java中各个线程是怎么彼此看到对方的变量的呢？**  
Java中定义了主内存与工作内存的概念、所有的变量都存储在主内存，每条线程还有自己的工作内存，保存了被该线程使用到的变量的主内存副本拷贝。

线程对变量的所有操作（读取、赋值）都必须在工作内存中进行，不能直接读写主内存的变量。不同的线程之间也无法直接访问对方工作内存的变量，线程间变量值的传递需要通过主内存。

### 请谈谈volatile有什么特点，为什么它能保证变量对所有线程的可见性？ ###

关键字volatile是Java虚拟机提供的最轻量级的同步机制。当一个变量被定义成volatile之后，具备两种特性、

（1）保证此变量对所有线程的可见性。当一条线程修改了这个变量的值，新值对于其他线程是可以立即得知的。而普通变量做不到这一点。  
（2）禁止指令重排序优化。普通变量仅仅能保证在该方法执行过程中，得到正确结果，但是不保证程序代码的执行顺序。Java的内存模型定义了8种内存间操作、lock和unlock把一个变量标识为一条线程独占的状态。把一个处于锁定状态的变量释放出来，释放之后的变量才能被其他线程锁定。read和write把一个变量值从主内存传输到线程的工作内存，以便load。把store操作从工作内存得到的变量的值，放入主内存的变量中。

load和store把read操作从主内存得到的变量值放入工作内存的变量副本中。把工作内存的变量值传送到主内存，以便write。use和assgin把工作内存变量值传递给执行引擎。将执行引擎值传递给工作内存变量值。volatile的实现基于这8种内存间操作，保证了一个线程对某个volatile变量的修改，一定会被另一个线程看见，即保证了可见性。

### 既然volatile能够保证线程间的变量可见性，是不是就意味着基于volatile变量的运算就是并发安全的？ ###

显然不是的。基于volatile变量的运算在并发下不一定是安全的。volatile变量在各个线程的工作内存，不存在一致性问题（各个线程的工作内存中volatile变量，每次使用前都要刷新到主内存）。但是Java里面的运算并非原子操作，导致volatile变量的运算在并发下一样是不安全的。

### 请对比下volatile对比Synchronized的异同。 ###

Synchronized既能保证可见性，又能保证原子性，而volatile只能保证可见性，无法保证原子性。

ThreadLocal和Synchonized都用于解决多线程并发访问，防止任务在共享资源上产生冲突。但是ThreadLocal与Synchronized有本质的区别。

Synchronized用于实现同步机制，是利用锁的机制使变量或代码块在某一时该只能被一个线程访问，是一种“以时间换空间”的方式。而ThreadLocal为每一个线程都提供了变量的副本，使得每个线程在某一时间访问到的并不是同一个对象，根除了对变量的共享，是一种“以空间换时间”的方式。

### 请谈谈ThreadLocal是怎么解决并发安全的？ ###

ThreadLocal这是Java提供的一种保存线程私有信息的机制，因为其在整个线程生命周期内有效，所以可以方便地在一个线程关联的不同业务模块之间传递信息，比如事务ID、Cookie等上下文相关信息。ThreadLocal为每一个线程维护变量的副本，把共享数据的可见范围限制在同一个线程之内，其实现原理是，在ThreadLocal中有一个Map，用于存储每一个线程的变量的副本。

### 很多人都说要慎用ThreadLocal，谈谈你的理解，使用ThreadLocal需要注意些什么？ ###

使用ThreadLocal要注意remove！ThreadLocal的实现是基于一个所谓的ThreadLocalMap，在ThreadLocalMap中，它的key是一个弱引用。通常弱引用都会和引用队列配合清理机制使用，但是ThreadLocal是个例外，它并没有这么做。这意味着，废弃项目的回收依赖于显式地触发，否则就要等待线程结束，进而回收相应ThreadLocalMap！这就是很多OOM的来源，所以通常都会建议，应用一定要自己负责remove，并且不要和线程池配

## 重磅福利 ##

关注「 **冰河技术** 」微信公众号，后台回复 “设计模式” 关键字领取《深入浅出Java 23种设计模式》PDF文档。回复“Java8”关键字领取《Java8新特性教程》PDF文档。两本PDF均是由冰河原创并整理的超硬核教程，面试必备！！

**好了，今天就聊到这儿吧！别忘了点个赞，给个在看和转发，让更多的人看到，一起学习，一起进步！！**

## 写在最后 ##

> 如果你觉得冰河写的还不错，请微信搜索并关注「 **冰河技术** 」微信公众号，跟冰河学习高并发、分布式、微服务、大数据、互联网和云原生技术，「 **冰河技术** 」微信公众号更新了大量技术专题，每一篇技术文章干货满满！不少读者已经通过阅读「 **冰河技术** 」微信公众号文章，吊打面试官，成功跳槽到大厂；也有不少读者实现了技术上的飞跃，成为公司的技术骨干！如果你也想像他们一样提升自己的能力，实现技术能力的飞跃，进大厂，升职加薪，那就关注「 **冰河技术** 」微信公众号吧，每天更新超硬核技术干货，让你对如何提升技术能力不再迷茫！

![20200716220443647.png][]

[Link 1]: https://mp.weixin.qq.com/mp/appmsgalbum?__biz=Mzg3MzE1NTIzNA==&action=getalbum&album_id=1321093706803642369&subscene=126&scenenote=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzg3MzE1NTIzNA%3D%3D%26mid%3D2247485659%26idx%3D1%26sn%3De2350e1da8cbaf5eb1ed883b54a95189%26chksm%3Dcee51716f9929e00d4ba0c13a4e274a4d819dd05ca8a2648541b33537a7bb0b77cf3f7062cb5%26scene%3D126%26sessionid%3D1595779311%26key%3D6270cffc7a2fb38a4843c899e78448c2e5b64dc1b3d940a160ec788d66d699e029cbcfbfc28ea80fe5f899fb7c5432b76c7fcd69f461f0db9c538b281d401cab4009ac3dccc0564f398a6d94fba21767%26ascene%3D1%26uin%3DMjY0ODI3NDMxNQ%253D%253D%26devicetype%3DWindows%2B10%2Bx64%26version%3D62090529%26lang%3Dzh_CN%26exportkey%3DA5llQUJul1EaIwuR1TuvO3U%253D%26pass_ticket%3DV3wMVGh83wZPNM91TrGl0WM9c5LHsB3e2hTzPzmaqLFG3JQavW4ook9vtu2gXL3N%26winzoom%3D1#wechat_redirect
[20200716220443647.png]: /images/20210901/81d3d994bad44ea8a8e25cafe488714d.png