线程池面试题

最新推荐文章于 2024-08-30 19:48:46 发布

五音诗.

最新推荐文章于 2024-08-30 19:48:46 发布

阅读量135

点赞数

文章标签：面试 java 数据库

本文链接：https://blog.csdn.net/weixin_46685542/article/details/127014434

版权

多线程同时被 2 个专栏收录

5 篇文章 0 订阅

订阅专栏

面试

3 篇文章 0 订阅

订阅专栏

参考 https://mp.weixin.qq.com/s/F0on3-cf1VtSAlzLfKAQBw

1.平时有用过线程池吗，什么是线程池，为什么要用线程池？

什么是线程，什么是线程池

线程是计算机操作系统能够进行运算调度的最小单位，被包含在进程里，是应用程序执行进程的实际运行单位；是操作系统宝贵的资源；使用池化技术，对线程进行统一控制管理，就是线程池；

JUC 提供了ThreadPoolExecutor 线程池继承体系，可以借此创建线程池；

线程池的好处

降低资源消耗。降低频繁创建、销毁线程带来的额外开销，复用已创建线程
降低使用复杂度。将任务的提交和执行进行解耦，我们只需要创建一个线程池，然后往里面提交任务就行，具体执行流程由线程池自己管理，降低使用复杂度
提高线程可管理性。能安全有效的管理线程资源，避免不加限制无限申请造成资源耗尽风险
提高响应速度。任务到达后，直接复用已创建好的线程执行

使用线程池的场景

快速响应用户请求

注册或提交什么信息，需要修改调用的服务组件很多，串行执行的话，要等一个服务调用成功后再进行下一个调用，这样会导致处理时间过长，用户等待时间久；

可以使用线程池异步调用服务，直接先返回用户响应，提高用户体验；
单位时间内处理更多的请求，提高吞吐量

MQ队列的消息过多，消费时间久，容易造成消息积压，或批量插入数据库时间久；

可以使用线程池，多线程执行，执行速度更快；

2. JUC提供的 ThreadPoolExecutor 体系线程池有哪些重要的参数？

青铜回答：

包含核心线程数（corePoolSize）、最大线程数（maximumPoolSize），

空闲线程超时时间（keepAliveTime）、时间单位（unit）、阻塞队列（workQueue）、

拒绝策略（handler）、线程工厂（ThreadFactory）这7个参数。

钻石回答：

回答完包含这几个参数之后，会再主动描述下线程池的执行流程，也就是 execute() 方法执行流程。

public void execute(Runnable command) {
    if (command == null)
        throw new NullPointerException();
    int c = ctl.get();
    if (workerCountOf(c) < corePoolSize) {
        if (addWorker(command, true))
            return;
        c = ctl.get();
    }
    if (isRunning(c) && workQueue.offer(command)) {
        int recheck = ctl.get();
        if (! isRunning(recheck) && remove(command))
            reject(command);
        else if (workerCountOf(recheck) == 0)
            addWorker(null, false);
    }
    else if (!addWorker(command, false))
        reject(command);
}

判断线程池的状态，如果不是RUNNING状态，直接执行拒绝策略
如果当前线程数 < 核心线程池，则新建一个线程来处理提交的任务
如果当前线程数 > 核心线程数且任务队列没满，则将任务放入阻塞队列等待执行
如果核心线程池 < 当前线程池数 < 最大线程数，且任务队列已满，则创建新的线程执行提交的任务
如果当前线程数 > 最大线程数，且队列已满，则执行拒绝策略拒绝该任务

王者回答：

在回答完包含哪些参数及 execute 方法的执行流程后。然后可以说下这个执行流程是JUC 标准线程池提供的执行流程，主要用在 CPU 密集型场景下，认为CPU的线程资源更重要。

像 Tomcat、Dubbo 这类框架，他们内部的线程池主要用来处理网络 IO 任务的，所以他们都对 JUC 线程池的执行流程进行了调整来支持**IO 密集型场景 **使用，认为处理请求任务更重要。

提供了阻塞队列 TaskQueue，该队列继承 LinkedBlockingQueue，重写了 offer() 方法来实现执行流程的调整
```
@Override
    public boolean offer(Runnable o) {
        //we can't do any checks
        if (parent==null) 
            return super.offer(o);
        //we are maxed out on threads, simply queue the object
        if (parent.getPoolSize() == parent.getMaximumPoolSize()) 
            return super.offer(o);
        //we have idle threads, just add it to the queue
        if (parent.getSubmittedCount()<=(parent.getPoolSize())) 
            return super.offer(o);
        //if we have less threads than maximum force creation of a new thread
        if (parent.getPoolSize()<parent.getMaximumPoolSize())
            return false;
        //if we reached here, we need to add it to the queue
        return super.offer(o);
    }
```
队列在入队时有判断，parent 就是当前线程池对象

1.如果 parent 为 null，直接调用父类 offer 方法入队

2.如果当前线程数等于最大线程数，则直接调用父类 offer()方法入队

3.如果当前未执行的任务数量小于等于当前线程数，仔细思考下，是不是说明有空闲的线程呢，那么直接调用父类 offer() 入队后就马上有线程去执行它

4.如果当前线程数小于最大线程数量，则直接返回 false，然后回到 JUC 线程池的执行流程回想下，是不是就去添加新线程去执行任务了呢

5.其他情况都直接入队

和JUC的区别

当前线程数大于核心线程数时，JUC 原生线程池首先是把任务放到队列里等待执行，而不是先创建线程执行。

如果 Tomcat 接收的请求数量大于核心线程数，请求就会被放到队列中，等待核心线程处理，这样会降低请求的总体响应速度。

所以 Tomcat并没有使用 JUC 原生线程池，利用 TaskQueue 的 offer() 方法巧妙的修改了 JUC 线程池的执行流程，改写后 Tomcat 线程池执行流程如下：
1. 判断如果当前线程数小于核心线程池，则新建一个线程来处理提交的任务
2. 如果当前线程数大于核心线程池，小于最大线程数，则创建新的线程执行提交的任务
3. 如果当前线程数等于最大线程数，则将任务放入任务队列等待执行
4. 如果队列已满，则执行拒绝策略
个人总结 ：

就是对创建线程和任务放进阻塞队列的顺序不同；
- 当前线程数大于核心线程数，应用于CPU使用密集场景的JUC原生线程池不会轻易的创建线程执行任务，CPU的线程资源很宝贵，线程资源更重要，而是放入一个队列里存着，如果队列满了压不住了，才继续创建线程，直到线程数达到最大线程数；
- 而应用于网络IO请求密集场景的Tomcat，网络IO请求的速度更重要，如果也是这样放进队列里存着，呐响应速度就会很受影响，于是做出修改，如果线程数大于核心线程数，就继续创建线程，直到最大线程数，然后再放进队列里，可以理解为，能用线程尽快处理的就创建线程处理，而不是放进队列里等着，用户请求等不起
还可以再说下线程池的 Worker 线程模型，继承 AQS 实现了锁机制。线程启动后执行 runWorker() 方法，runWorker() 方法中调用 getTask() 方法从阻塞队列中获取任务，获取到任务后先执行 beforeExecute() 钩子函数，再执行任务，然后再执行 afterExecute() 钩子函数。若超时获取不到任务会调用 processWorkerExit() 方法执行 Worker 线程的清理工作。

3.什么是阻塞队列？说说常用的阻塞队列有哪些？

阻塞队列 BlockingQueue 继承 Queue

特点是：

当从阻塞队列中获取数据时，如果队列为空，则等待直到队列有元素存入。

当向阻塞队列中存入元素时，如果队列已满，则等待直到队列中有元素被移除。

提供 offer()、put()、take()、poll() 等常用方法。

JDK提供的阻塞队列：

1）ArrayBlockingQueue：由数组实现的有界阻塞队列，该队列按照 FIFO 对元素进行排序。维护两个整形变量，标识队列头尾在数组中的位置，在生产者放入和消费者获取数据共用一个锁对象，意味着两者无法真正的并行运行，性能较低。

2）LinkedBlockingQueue：由链表组成的有界阻塞队列，如果不指定大小，默认使用 Integer.MAX_VALUE 作为队列大小，该队列按照 FIFO 对元素进行排序，对生产者和消费者分别维护了独立的锁来控制数据同步，意味着该队列有着更高的并发性能。

3）SynchronousQueue：不存储元素的阻塞队列，无容量，可以设置公平或非公平模式，插入操作必须等待获取操作移除元素，反之亦然。

4）PriorityBlockingQueue：支持优先级排序的无界阻塞队列，默认情况下根据自然序排序，也可以指定 Comparator。

5）DelayQueue：支持延时获取元素的无界阻塞队列，创建元素时可以指定多久之后才能从队列中获取元素，常用于缓存系统或定时任务调度系统。

6）LinkedTransferQueue：一个由链表结构组成的无界阻塞队列，与LinkedBlockingQueue相比多了transfer和tryTranfer方法，该方法在有消费者等待接收元素时会立即将元素传递给消费者。

7）LinkedBlockingDeque：一个由链表结构组成的双端阻塞队列，可以从队列的两端插入和删除元素。

4.你知道那些线程锁？ThreadPoolExecutor 都用到了哪些锁？为什么要用锁？

什么是重入锁？

就是支持重新进入的锁，表示支持一个线程对资源的重复加锁，方法执行的时候，执行线程在获取了锁后，还能继续对这个资源方法多次获取锁，而不会在下一次获取锁的时候出现阻塞自己的情况，用在递归方法里；

两者都是同步重入锁，线程独占锁，一个锁在一个时刻只能被一个线程占有，实现方式不同，都是悲观锁

synchronized

是JVM层面实现的，隐式加锁，不需要用户操作，操作简单，但是不够灵活

可以放在递归方法里，不需担心是否最后释放锁的操作；

不可中断，除非抛出异常；

实现原理：重量级锁，悲观锁，

经过编译，在同步块的前后会有 monitorenter和monitorexit 两个字节码指令，执行前面的指令时，会尝试获取对象锁，如果这个对象没有被锁定，或当前线程已经获取了这个锁，就将锁的计数器加1，然后执行后面这个指令的时候就将计数器减1，当计数器为0，呐锁就被释放了，

如果当前线程获取锁失败，就进入阻塞状态，直到锁被释放；

作用在普通方法上就是对象实例加锁

作用在静态方法就是对类加锁，会锁住所有使用该方法的线程；
ReentrantLock

是JDK层面实现的，可以直接看到源码，需要手动加锁解锁，操作比较复杂，使用灵活，可以跨越方法；

重入时需要保证重复获取锁的次数和重复释放锁的次数一致，否则会出问题；

可以设置中断，长期占用不释放锁，其他等待的线程可以放弃等待，也可以调用interrupt()方法可中断

有公平锁，构造器传入true就是公平锁，默认是非公平锁；

多个线程等待，按照等待时间顺序获取锁，等的最久的先获取锁

有很多方法可以调用监听当前锁的信息；

实现原理：轻量级锁，悲观锁

是一种自旋锁，循环调用CAS比较交换来实现加锁，用了AQS（同步阻塞的框架，实现轻量级线程同步，作用主要是提供加锁、释放锁，并在内部维护一个FIFO等待队列，用于存储由于锁竞争而阻塞的线程）

获取锁

ReentrantLock在采用非公平锁构造时，首先检查锁状态，如果锁可用，直接通过CAS设置成持有状态，且把当前线程设置为锁的拥有者。
如果当前锁已经被持有，那么接下来进行可重入检查，如果可重入，需要为锁状态加上请求数。如果不属于上面两种情况，那么说明锁是被其他线程持有，
当前线程应该放入等待队列。
在放入等待队列的过程中，首先要检查队列是否为空队列，如果为空队列，需要创建虚拟的头节点，然后把对当前线程封装的节点加入到队列尾部。由于设置尾部节点采用了CAS，为了保证尾节点能够设置成功，这里采用了无限循环的方式，直到设置成功为止。
在完成放入等待队列任务后，则需要维护节点的状态，以及及时清除处于Cancel状态的节点，以帮助垃圾收集器及时回收。如果当前节点之前的节点的等待状态小于1，说明当前节点之前的线程处于等待状态(挂起)，那么当前节点的线程也应处于等待状态(挂起)。挂起的工作是由LockSupport类支持的，LockSupport通过JNI调用本地操作系统来完成挂起的任务(java中除了废弃的suspend等方法，没有其他的挂起操作)。
在当前等待的线程，被唤起后，检查中断状态，如果处于中断状态，那么需要中断当前线程。

释放锁

(1)首先尝试释放锁，如果要求释放数等于锁状态数，那么将锁状态位清0，清除锁所有者，返回true；否则返回false;
(2)如果(1)返回的是true，说明锁完全释放。接下来将检查等待队列，并选择一个waitStatus处于等待状态的节点下的线程unpark(恢复)，选择的依据是从尾节点开始，选取最靠近头节点的等待节点,同时清理队列中线程被取消的节点；
(3)如果(1)返回false，说明锁只是部分释放，当前线程仍旧持有该锁；

1）mainLock 锁重入锁

ThreadPoolExecutor 线程池内部维护 ReentrantLock(重入锁) 的 mainLock，

在获取一些成员变量 workers时，还有相关的数据统计,访问 largestPoolSize（池的最大容量）、completedTaskCount(已经完成的任务数)就会使用到这个重入锁 mainLock

private final ReentrantLock mainLock = new ReentrantLock();

/**
 * Set containing all worker threads in pool. Accessed only when
 * holding mainLock.
 */
private final HashSet<Worker> workers = new HashSet<Worker>();

/**
 * Tracks largest attained pool size. Accessed only under
 * mainLock.
 */
private int largestPoolSize;

/**
 * Counter for completed tasks. Updated only on termination of
 * worker threads. Accessed only under mainLock.
 */
private long completedTaskCount;

为什么要用这个 mainLock 锁？

关键是这些成员变量使用的是线程不安全的HashSet，变量也没有volatile 修饰，所以需要使用这个锁来保证安全

呐为什么用线程安全的map呢？

直接原因是有串行化方法，避免了中断风暴

什么是中断风暴？

就是不加锁的情况下，一个串行化方法在多线程的调用下，线程A调用方法对worker进行中断，此时worker处于正在中断中的状态，还没有成功完全中断，然后多线程又来一个线程B，对线程A的中断操作进行中断，也就是中断了正在中断的worker，然后线程A的中断被破坏了；

为什么不直接用volatile修饰这些成员变量？

其他内部变量能用volatile修饰的都加上了，就这两个 largestPoolSize（池的最大容量）、completedTaskCount(已经完成的任务数)没有加
为了保证数据的准确性，获取这两个值的时候保证一定是修改方法执行完成后的；
如果不加锁而是用volatile 修饰，如果在方法还没执行完就来获取值，返回的是修改方法完成前的值

2)Worker 线程锁

Worker 线程继承 AQS，实现了 Runnable 接口，内部持有一个 Thread 变量，一个 firstTask，及 completedTasks 三个成员变量

基于 AQS 的 acquire()、tryAcquire() 实现了 lock()、tryLock() 方法，类上也有注释，该锁主要是用来维护运行中线程的中断状态。在 runWorker() 方法中以及刚说的 interruptIdleWorkers() 方法中用到了。

维护运行中线程的中断状态怎么理解呢

protected boolean tryAcquire(int unused) {
      if (compareAndSetState(0, 1)) {
          setExclusiveOwnerThread(Thread.currentThread());
          return true;
      }
      return false;
  }
  public void lock()        { acquire(1); }
  public boolean tryLock()  { return tryAcquire(1); }

在runWorker() 方法中获取到任务开始执行前，需要先调用 w.lock() 方法，lock() 方法会调用 tryAcquire() 方法，tryAcquire() 实现了一把非重入锁，通过 CAS 实现加锁。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nyslC7gG-1663923591514)(p\1663645525816.png)]

interruptIdleWorkers() 方法会中断那些等待获取任务的线程，会调用 w.tryLock() 方法来加锁，如果一个线程已经在执行任务中，那么 tryLock() 就获取锁失败，就保证了不能中断运行中的线程了。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-h5ttqsMe-1663923591515)(p\1663645551088.png)]

所以 Worker 继承 AQS 主要就是为了实现了一把非重入锁，维护线程的中断状态，保证不能中断运行中的线程。

5.项目中是怎样使用线程池的？Executors 了解吗？

面试官主要想知道你日常工作中使用线程池的姿势，现在大多数公司都在遵循阿里巴巴 Java 开发规范，该规范里明确说明不允许使用 Executors 创建线程池，而是通过 ThreadPoolExecutor 显示指定参数去创建

你可以这样说，知道 Executors 工具类，很久之前有用过，也踩过坑，Executors 创建的线程池有发生 OOM 的风险。

Executors.newFixedThreadPool 和 Executors.SingleThreadPool 创建的线程池内部使用的是无界（Integer.MAX_VALUE）的 LinkedBlockingQueue 队列，可能会堆积大量请求，导致 OOM,内存溢出

Executors.newCachedThreadPool 和Executors.scheduledThreadPool 创建的线程池最大线程数是用的Integer.MAX_VALUE，可能会创建大量线程，导致 OOM

在日常工作中也有封装类似的工具类，但是都是内存安全的，参数需要自己指定适当的值，也有基于 LinkedBlockingQueue 实现了内存安全阻塞队列 MemorySafeLinkedBlockingQueue，当系统内存达到设置的剩余阈值时，就不在往队列里添加任务了，避免发生 OOM

在 Spring 环境中使用线程池的，直接使用 JUC 原生 ThreadPoolExecutor 有个问题，Spring 容器关闭的时候可能任务队列里的任务还没处理完，有丢失任务的风险。Spring 中的 Bean 是有生命周期的，如果 Bean 实现了 Spring 相应的生命周期接口（InitializingBean、DisposableBean接口），在 Bean 初始化、容器关闭的时候会调用相应的方法来做相应处理。

最好不要直接使用 ThreadPoolExecutor 在 Spring 环境中，可以使用 Spring 提供的 ThreadPoolTaskExecutor，或者 DynamicTp 框架提供的 DtpExecutor 线程池实现。

按业务类型进行线程池隔离，各任务执行互不影响，避免共享一个线程池，任务执行参差不齐，相互影响，高耗时任务会占满线程池资源，导致低耗时任务没机会执行；同时如果任务之间存在父子关系，可能会导致死锁的发生，进而引发 OOM

6.通过 ThreadPoolExecutor 来创建线程池，那核心参数设置多少合适呢？

这个需要根据具体情况，不断的压测修改线程池的参数，观察CPU的使用率等其他数据来找到合适的参数值；

7.线程池是咋监控的？

对线程池 ThreadPoolExecutor 做了一些增强，做了一个线程池管理框架，

利用了 ThreadPoolExecutor 类提供的一些 set、get方法以及一些钩子函数

动态调参是基于配置中心实现的，核心参数配置在配置中心，可以随时调整、实时生效，利用了线程池提供的 set 方法。

监控，主要就是利用线程池提供的一些 get 方法来获取一些指标数据，然后采集数据上报到监控系统进行大盘展示。也提供了 Endpoint 实时查看线程池指标数据。

hippo4j-server 和动态线程池DynamicTp 都是动态线程池，修改配置中心的参数就可以对线程池造成影响

8.使用线程池的过程中遇到过哪些坑或者需要注意的地方？

OOM内存溢出问题

springboot里面有 @Async异步的注解，直接在启动类上开启异步，就可以使用异步方法，

这里有个坑，@Async的默认线程池为SimpleAsyncTaskExecutor。不是真的线程池，这个类不重用线程，默认每次调用都会创建一个新的线程，而且配置是最大线程数：Integet.MAX_VALUE，队列使用LinkedBlockingQueue，容量是：Integet.MAX_VALUE，

如果不自定义配置线程池，那就会OOM内存溢出；

一般用 ThreadPoolTaskExecutor来配置自定义参数的线程池，在@Async注解里指定线程池