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

大家好，我是冰河~~

最近，一名读者去蚂蚁金服面试，面试官问了他关于乐观锁和悲观锁的问题，幸亏他看了我的【高并发专题】文章，结果是替这名读者高兴！现就部分面试题目总结成文，供小伙伴们参考。

小伙伴们可以关注 冰河技术 微信公众号来学习【高并发专题】，学习超硬核知识技能，跳槽大厂，升级加薪，指日可待！

面试汇总

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

在 Java 中，所谓的线程池中的“线程”，其实是被抽象为了一个静态内部类 Worker，它基于 AQS 实现，存放在线程池的 HashSet<Worker>workers 成员变量中；而需要执行的任务则存放在成员变量 workQueue（BlockingQueue<Runnable>workQueue）中。这样，整个线程池实现的基本思想就是、从 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：nThreadsmaximumPoolSize：nThreadskeepAliveTime：0LworkQueue：newLinkedBlockingQueue<Runnable>()，其缓冲队列是无界的。

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

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

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

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

corePoolSize：corePoolSizemaximumPoolSize：Integer.MAX_VALUEkeepAliveTime：DEFAULT_KEEPALIVE_MILLISworkQueue：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，并且不要和线程池配

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