Java线程池相关面试题

最新推荐文章于 2024-04-17 00:43:09 发布

祁坤宇

最新推荐文章于 2024-04-17 00:43:09 发布

阅读量353

点赞数

文章标签： java jvm 面试 Powered by 金山文档

本文链接：https://blog.csdn.net/qq_33550151/article/details/129425889

版权

ThreadPoolExecutor 有哪些常用的方法？

submit()/execute()：执行线程池
shutdown()/shutdownNow()：终止线程池
isShutdown()：判断线程是否终止
getActiveCount()：正在运行的线程数
getCorePoolSize()：获取核心线程数
getMaximumPoolSize()：获取最大线程数
getQueue()：获取线程池中的任务队列
allowCoreThreadTimeOut(boolean)：设置空闲时是否回收核心线程

说说submit()和 execute()两个方法有什么区别？

submit() 和 execute() 都是用来执行线程池的

使用 execute() 执行线程池不能有返回方法
使用 submit() 可以使用 Future 接收线程池执行的返回值。

线程池创建需要的哪几个核心参数的含义

ThreadPoolExecutor 最多包含以下七个参数：

corePoolSize：线程池中的核心线程数
maximumPoolSize：线程池中最大线程数
keepAliveTime：闲置超时时间
unit：keepAliveTime 超时时间的单位（时/分/秒等）
workQueue：线程池中的任务队列
threadFactory：为线程池提供创建新线程的线程工厂
rejectedExecutionHandler：线程池任务队列超过最大值之后的拒绝策略

shutdownNow() 和 shutdown() 两个方法有什么区别？

shutdownNow() 和 shutdown() 都是用来终止线程池的

使用 shutdown() 程序不会报错，也不会立即终止线程，它会等待线程池中的缓存任务执行完之后再退出，执行了 shutdown() 之后就不能给线程池添加新任务了；

shutdownNow() 会试图立马停止任务，如果线程池中还有缓存任务正在执行，则会抛出 java.lang.InterruptedException: sleep interrupted 异常。

了解过线程池的工作原理吗？

如果此时线程池中的数量小于corePoolSize，即使线程池中的线程都处于空闲状态，也要创建新的线程来处理被添加的任务。

如果此时线程池中的数量等于corePoolSize，但是缓冲队列workQueue未满，那么任务被放入缓冲队列。

如果此时线程池中的数量大于等于corePoolSize，缓冲队列workQueue满，并且线程池中的数量小于maximumPoolSize，建新的线程来处理被添加的任务。

如果此时线程池中的数量大于corePoolSize，缓冲队列workQueue满，并且线程池中的数量等于maximumPoolSize，那么通过 handler所指定的策略来处理此任务。

当线程池中的线程数量大于 corePoolSize时，如果某线程空闲时间超过keepAliveTime，线程将被终止。这样，线程池可以动态的调整池中的线程数。

线程池中核心线程数量大小怎么设置？

CPU密集型任务
尽量使用较小的线程池，一般为CPU核心数+1。因为CPU密集型任务使得CPU使用率很高，若开过多的线程数，会造成CPU过度切换。

IO密集型任务
可以使用稍大的线程池，一般为2*CPU核心数。 IO密集型任务CPU使用率并不高，因此可以让CPU在等待IO的时候有其他线程去处理别的任务，充分利用CPU时间。

混合型任务
可以将任务分成IO密集型和CPU密集型任务，然后分别用不同的线程池去处理。只要分完之后两个任务的执行时间相差不大，那么就会比串行执行来的高效。因为如果划分之后两个任务执行时间有数据级的差距，那么拆分没有意义。因为先执行完的任务就要等后执行完的任务，最终的时间仍然取决于后执行完的任务，而且还要加上任务拆分与合并的开销，得不偿失。

以上只是理论值，实际项目中建议在本地或者测试环境进行多次调优，找到相对理想的值大小。

线程池为什么需要使用（阻塞）队列？

主要有三点：

线程若是无限制的创建，可能会导致内存占用过多而产生OOM

会造成cpu过度切换。

创建线程池的消耗较高。

线程池为什么要用（阻塞）队列？

因为线程若是无限制的创建，可能会导致内存占用过多而产生OOM，并且会造成cpu过度切换

创建线程池的消耗较高。线程池创建线程需要获取mainlock这个全局锁，影响并发效率，阻塞队列可以很好的缓冲

线程池为什么要使用阻塞队列而不使用非阻塞队列？

阻塞队列可以保证任务队列中没有任务时阻塞获取任务的线程，使得线程进入wait状态，释放cpu资源。当队列中有任务时才唤醒对应线程从队列中取出消息进行执行。使得在线程不至于一直占用cpu资源。

线程执行完任务后通过循环再次从任务队列中取出任务进行执行，代码片段如下

while(task !=null||(task =getTask())!=null){}）。

不用阻塞队列也是可以的，不过实现起来比较麻烦而已

了解线程池状态吗？

通过获取线程池状态，可以判断线程池是否是运行状态、可否添加新的任务以及优雅地关闭线程池等。

RUNNING：线程池的初始化状态，可以添加待执行的任务。

SHUTDOWN：线程池处于待关闭状态，不接收新任务仅处理已经接收的任务。

STOP：线程池立即关闭，不接收新的任务，放弃缓存队列中的任务并且中断正在处理的任务。

TIDYING：线程池自主整理状态，调用 terminated() 方法进行线程池整理。

TERMINATED：线程池终止状态。

知道线程池中线程复用原理吗？

线程有任务处理的时候执行，没有任务等待，释放cpu，所以使用阻塞队列这样的模型，实现这种需求，提交任务到线程池里面的一个线程（生产者线程）保存在阻塞队列，（消费者）线程不断地从阻塞队列去执行，基于阻塞队列的一个特性，没有工作任务，这些工作线程就会阻塞等待，直到会有新的任务进来，工作线程被唤醒，从而达到线程复用。

线程池将线程和任务进行解耦，线程是线程，任务是任务，摆脱了之前通过 Thread 创建线程时的一个线程必须对应一个任务的限制。

在线程池中，同一个线程可以从阻塞队列中不断获取新任务来执行，其核心原理在于线程池对 Thread 进行了封装，并不是每次执行任务都会调用 Thread.start() 来创建新线程，而是让每个线程去执行一个“循环任务”，在这个“循环任务”中不停的检查是否有任务需要被执行，如果有则直接执行，也就是调用任务中的 run 方法，将 run 方法当成一个普通的方法执行，通过这种方式将只使用固定的线程就将所有任务的 run 方法串联起来。

你的线程池参数是如何设置的？

答：一般线程池是要根据业务场景来设置线程池中的各个参数的，具体的几个重要的参数：

public ThreadPoolExecutor( int corePoolSize,

int maximumPoolSize,

long keepAliveTime,

TimeUnit unit,

BlockingQueue workQueue,

ThreadFactory threadFactory,

RejectedExecutionHandler handler) { … }

1、corePoolSize: 核心线程数这个应该是最重要的参数，核心线程会一直存活，及时没有任务需要执行。当线程数小于核心线程数时，即使有线程空闲，线程池也会优先创建新线程处理。设置allowCoreThreadTimeout=true（默认false）时，核心线程会超时关闭。

如何设置好需要根据项目业务是CPU密集型和IO密集型的区别。

(1)、CPU密集型 CPU密集型也叫计算密集型，指的是系统的硬盘、内存性能相对CPU要好很多，此时，系统运作大部分的状况是CPU Loading 100%，CPU要读/写I/O(硬盘/内存)，I/O在很短的时间就可以完成，而CPU还有许多运算要处理，CPU Loading 很高。在多重程序系统中，大部分时间用来做计算、逻辑判断等CPU动作的程序称之CPU bound。例如一个计算圆周率至小数点一千位以下的程序，在执行的过程当中绝大部分时间用在三角函数和开根号的计算，便是属于CPU bound的程序。 CPU bound的程序一般而言CPU占用率相当高。这可能是因为任务本身不太需要访问I/O设备，也可能是因为程序是多线程实现因此屏蔽掉了等待I/O的时间。

(2)、IO密集型 IO密集型指的是系统的CPU性能相对硬盘、内存要好很多，此时，系统运作，大部分的状况是CPU在等I/O (硬盘/内存) 的读/写操作，此时CPU Loading并不高。 I/O bound的程序一般在达到性能极限时，CPU占用率仍然较低。这可能是因为任务本身需要大量I/O操作，而pipeline做得不是很好，没有充分利用处理器能力。

(3)、先看下机器的CPU核数，然后在设定具体参数：自己测一下自己机器的核数 System.out.println(Runtime.getRuntime().availableProcessors()); 即CPU核数 = Runtime.getRuntime().availableProcessors()

(4)、分析下线程池处理的程序是CPU密集型还是IO密集型 CPU密集型：corePoolSize = CPU核数 + 1 IO密集型：corePoolSize = CPU核数 * 2

2、maximumPoolSize：最大线程数当线程数>=corePoolSize，且任务队列已满时。线程池会创建新线程来处理任务。当线程数=maxPoolSize，且任务队列已满时，线程池会拒绝处理任务而抛出异常。

3、keepAliveTime：线程空闲时间当线程空闲时间达到keepAliveTime时，线程会退出，直到线程数量=corePoolSize。如果allowCoreThreadTimeout=true，则会直到线程数量=0。

4、queueCapacity：任务队列容量（阻塞队列）当核心线程数达到最大时，新任务会放在队列中排队等待执行

5、allowCoreThreadTimeout：允许核心线程超时

6、rejectedExecutionHandler：任务拒绝处理器

两种情况会拒绝处理任务：

当线程数已经达到maxPoolSize，且队列已满，会拒绝新任务。

当线程池被调用shutdown()后，会等待线程池里的任务执行完毕再shutdown。

如果在调用shutdown()和线程池真正shutdown之间提交任务，会拒绝新任务。线程池会调用rejectedExecutionHandler来处理这个任务。如果没有设置默认是AbortPolicy，会抛出异常。

ThreadPoolExecutor 采用了策略的设计模式来处理拒绝任务的几种场景。

这几种策略模式都实现了RejectedExecutionHandler 接口：

AbortPolicy 丢弃任务，抛运行时异常。

CallerRunsPolicy 执行任务。

DiscardPolicy 忽视，什么都不会发生。

DiscardOldestPolicy 从队列中踢出最先进入队列（最后一个执行）的任务。

三、如何设置参数，线程池的默认值如下：

corePoolSize = 1

maxPoolSize = Integer.MAX_VALUE

queueCapacity = Integer.MAX_VALUE

keepAliveTime = 60s

allowCoreThreadTimeout = false

rejectedExecutionHandler = AbortPolicy()

如何来设置呢？需要根据几个值来决定：

tasks ：每秒的任务数，假设为500~1000

taskcost：每个任务花费时间，假设为0.1s

responsetime：系统允许容忍的最大响应时间，假设为1s 做几个计算

corePoolSize = 每秒需要多少个线程处理？

threadcount = tasks/(1/taskcost) = tasks*taskcout = (500 ~ 1000)*0.1 = 50~100 个线程。

corePoolSize设置应该大于50。

根据8020原则，如果80%的每秒任务数小于800，

那么corePoolSize设置为80即可： queueCapacity = (coreSizePool/taskcost) responsetime

计算可得 queueCapacity = 80/0.11 = 800。

意思是队列里的线程可以等待1s，超过了的需要新开线程来执行。

切记不能设置为Integer.MAX_VALUE，这样队列会很大，线程数只会保持在corePoolSize大小，当任务陡增时，不能新开线程来执行，响应时间会随之陡增。

maxPoolSize 最大线程数在生产环境上我们往往设置成corePoolSize一样，这样可以减少在处理过程中创建线程的开销。

rejectedExecutionHandler：根据具体情况来决定，任务不重要可丢弃，任务重要则要利用一些缓冲机制来处理。

keepAliveTime和allowCoreThreadTimeout采用默认通常能满足。

以上都是理想值，实际情况下要根据机器性能来决定。如果在未达到最大线程数的情况机器cpu load已经满了，则需要通过升级硬件和优化代码，降低taskcost来处理。

然后是线程池队列的选择：

workQueue - 当线程数目超过核心线程数时用于保存任务的队列。主要有3种类型的BlockingQueue可供选择：

无界队列，

有界队列，

同步移交。

从参数中可以看到，此队列仅保存实现Runnable接口的任务。

这里再重复一下新任务进入时线程池的执行策略：

当正在运行的线程小于corePoolSize，线程池会创建新的线程。

当大于corePoolSize而任务队列未满时，就会将整个任务塞入队列。

当大于corePoolSize而且任务队列满时，并且小于maximumPoolSize时，就会创建新额线程执行任务。

当大于maximumPoolSize时，会根据handler策略处理线程。

1、无界队列；队列大小无限制，常用的为无界的LinkedBlockingQueue，使用该队列作为阻塞队列时要尤其当心，当任务耗时较长时可能会导致大量新任务在队列中堆积最终导致OOM。阅读代码发现，Executors.newFixedThreadPool 采用就是 LinkedBlockingQueue，而博主踩到的就是这个坑，当QPS很高，发送数据很大，大量的任务被添加到这个无界LinkedBlockingQueue 中，导致cpu和内存飙升服务器挂掉。当然这种队列，maximumPoolSize 的值也就无效了。当每个任务完全独立于其他任务，即任务执行互不影响时，适合于使用无界队列；例如，在 Web 页服务器中。这种排队可用于处理瞬态突发请求，当命令以超过队列所能处理的平均数连续到达时，此策略允许无界线程具有增长的可能性。

2、有界队列；当使用有限的 maximumPoolSizes 时，有界队列有助于防止资源耗尽，但是可能较难调整和控制。常用的有两类，一类是遵循FIFO原则的队列如ArrayBlockingQueue，另一类是优先级队列如PriorityBlockingQueue。 PriorityBlockingQueue中的优先级由任务的Comparator决定。使用有界队列时队列大小需和线程池大小互相配合，线程池较小有界队列较大时可减少内存消耗，降低cpu使用率和上下文切换，但是可能会限制系统吞吐量。

3、同步移交队列；如果不希望任务在队列中等待而是希望将任务直接移交给工作线程，可使用SynchronousQueue作为等待队列。 SynchronousQueue不是一个真正的队列，而是一种线程之间移交的机制。要将一个元素放入SynchronousQueue中，必须有另一个线程正在等待接收这个元素。只有在使用无界线程池或者有饱和策略时才建议使用该队列。