10道线程池面试题，都答上来算你赢

首席架构师专栏

已于 2024-10-08 09:58:02 修改

阅读量1.1k

点赞数 42

分类专栏：面试文章标签：面试 java

于 2024-08-16 16:34:37 首次发布

本文链接：https://blog.csdn.net/u010020088/article/details/141263017

版权

面试专栏收录该内容

4 篇文章 0 订阅

订阅专栏

大家好，本文旨在深入探讨Java线程池在面试中可能遭遇的各类核心问题，为您的求职之路铺设坚实基石。

全程内容精炼且实用，相信在掌握这些知识点后，您将能游刃有余地应对任何关于线程池的面试挑战，并进一步深化对线程池机制的理解。

作为Java开发者，面试中遭遇线程池相关提问几乎成为了一种“常规操作”。线程池作为一个既复杂又强大的系统，其广阔的讨论空间让面试官能够设计出丰富多样的问题，考验应聘者的专业知识与实战经验。
在这里插入图片描述

如果您对线程池了如指掌，那么这将是您在面试中大展身手的绝佳机会。想象一下，您能够自信满满地与面试官深入探讨线程池的每一个细节，甚至可能占据整个面试时间的一半以上，这不仅展示了您的专业深度，还无形中压缩了面试官提出其他难题的空间，使得面试过程更加顺畅，无疑为您的求职成功增添了重重的砝码。因此，充分准备线程池的相关知识，无疑会大大提升您通过面试的几率。

1. 面试官：日常工作中有用到线程池吗？什么是线程池？为什么要使用线程池？
在面试中，面试官往往倾向于以询问对线程池的了解作为评估你Java并发编程能力的一个切入点。如果你直接表示未曾使用或对此不熟悉，那么很可能后续的深入交流就会因此中断，面试结果也自然不容乐观。

线程池，作为java.util.concurrent（JUC）包中的璀璨明星，无疑是JUC领域的领军角色。对其缺乏了解，不仅反映出你对JUC包内其他并发工具的认识可能也仅限于表面，更深层次地，它可能暗示着你对Java并发编程的精髓尚未真正掌握。这样的印象一旦在面试官心中形成，面试的结果自然也就不言而喻了。

因此，把握住这个初始问题，展现你的专业素养至关重要。你可以这样条理清晰地回答：

“随着计算机技术的飞速发展，摩尔定律所描述的芯片性能提升趋势在现有工艺水平下正面临物理极限的挑战。为了突破这一瓶颈，业界普遍采用多核CPU并行计算来提升服务器性能，多线程技术应运而生，成为实现这一目标的关键手段。

线程，作为操作系统中极为宝贵的资源，其管理和调度直接关系到程序的执行效率和稳定性。因此，对线程的有效控制与管理显得尤为重要。线程池正是基于这一需求，通过池化思想（类似于连接池、常量池、对象池等概念），实现了对线程的复用和管理，有效降低了线程创建与销毁的开销，提高了资源利用率。

Java的JUC包为我们提供了强大的并发编程支持，其中ThreadPoolExecutor类及其体系更是管理线程、执行并行任务的首选工具。通过合理配置线程池的参数，我们可以灵活地应对不同的并发场景，实现高效、稳定的并发执行。”

下图是 Java 线程池继承体系：在这里插入图片描述

顶级接口Executor巧妙地提供了一种机制，实现了任务提交与执行的解耦。其核心在于定义了一个execute(Runnable command)方法，专门用于任务的提交，而将任务的具体执行逻辑留给接口的实现者去灵活定义。这一设计原则极大地增强了系统的灵活性和可扩展性。

ExecutorService接口，作为Executor的继承者，不仅保留了任务提交的基础功能，还进一步扩展了接口的功能范围。它引入了生命周期管理的方法，允许开发者对执行器进行更加精细的控制；提供了返回Future类型结果的方法，使得异步执行的结果可以被查询或等待；同时，还支持批量提交任务，提高了任务处理的效率。

AbstractExecutorService抽象类，作为ExecutorService接口的实现基础，为接口中的诸多方法提供了默认实现。它通过利用RunnableFuture接口的实现类FutureTask来封装Runnable任务，并巧妙地将这些封装后的任务提交给execute()方法执行。这一机制不仅简化了任务执行流程，还使得执行结果可以通过FutureTask对象以阻塞方式获取，极大地方便了异步编程的实践。此外，该抽象类还对批量任务的提交进行了优化编排，提升了任务处理的并发性和吞吐量。

ThreadPoolExecutor类，作为AbstractExecutorService的具体实现，将线程池的概念引入并发执行框架中。它采用池化思想，智能地管理一定数量的线程资源，以高效地调度和执行提交的任务。ThreadPoolExecutor定义了一套精细的线程池生命周期状态，并通过一个精心设计的ctl原子变量来同时跟踪和记录线程池的状态（使用变量的高3位）以及当前线程池中的线程数量（使用变量的低29位）。这种设计不仅保证了在高并发环境下的数据一致性，还简化了代码实现，提高了系统的稳定性和性能。深入探讨ctl变量的应用，我们还能进一步理解线程池状态之间的转换逻辑，这对于优化系统性能、调试并发问题具有重要意义。

在这里插入图片描述

使用线程池可以带来以下好处：

**1、降低资源消耗：**通过重用已存在的线程，减少线程的创建和销毁次数，从而显著降低因线程创建和销毁所带来的资源消耗。线程创建和销毁是重量级的操作，涉及到操作系统层面的资源分配和回收，频繁进行这些操作会严重影响系统性能。

**2、提高响应速度：**当任务到达时，线程池能够立即分配线程来执行任务，而无需等待新线程的创建。这缩短了任务等待执行的时间，提高了系统的响应速度。

**3、提高线程的可管理性：**线程池允许开发者对线程的数量、优先级等属性进行统一的管理和配置，从而避免线程的无序竞争和资源消耗。此外，线程池还提供了对线程执行状态的监控和统计功能，便于开发者对系统性能进行分析和优化。

**4、便于并发控制：**通过线程池，开发者可以更容易地控制并发执行的任务数量，避免过多的线程同时运行导致系统资源耗尽或系统不稳定。线程池可以根据系统的负载情况动态调整线程的数量，以达到最优的并发控制效果。

**5、提高系统稳定性：**通过合理的配置和管理线程池，可以避免因为线程数量过多或过少而导致的系统不稳定问题。线程池能够自动调整线程的数量以适应系统的负载变化，从而保持系统的稳定运行。

线程池的使用场景可以概括如下：

**1、快速响应用户请求，响应速度优先。**设想一个典型的用户请求案例，该请求需跨多个服务通过RPC机制并行搜集数据并最终聚合结果返回。在此情境下，线程池的引入实现了并行调用的高效执行，确保整体响应时间主要由最耗时的RPC接口决定，从而极大缩短了用户等待时间。另一实例则是用户注册流程，注册操作完成后，为提升用户体验，系统可将发送短信及邮件通知等耗时操作异步委托给线程池处理，主流程则迅速返回成功响应，让用户无需等待这些非关键性任务的完成。

**2、单位时间处理更多请求，吞吐量优先。**以接收MQ消息并调用第三方接口查询数据为例，这里的关键不在于追求每个请求的超快响应，而是侧重于整体资源的有效利用。线程池结合任务队列的策略，不仅为任务提供了缓冲空间，还通过并行处理机制最大化地利用了系统资源，确保在给定时间内能够处理尽可能多的任务，从而显著提高了系统的吞吐量。这种设计思路尤其适用于那些需要处理大量并发请求且对单请求响应时间要求相对宽松的应用场景。

这样的回答不仅展现了你的专业知识，还体现了你对线程池及其背后原理的深刻理解，相信会给面试官留下深刻印象。

2. 面试官：ThreadPoolExecutor 都有哪些核心参数？
实际上，当面试官询问关于线程池的问题时，他们往往期待的不仅仅是参数名称的罗列，更侧重于考察你对线程池内部工作机制的深刻理解，特别是其执行流程的理解。

青铜级回答：

你提到线程池包含核心参数如核心线程数（corePoolSize）、最大线程数（maximumPoolSize）、空闲线程存活时间（keepAliveTime）、时间单位（unit）、任务队列（workQueue）、拒绝策略（handler）以及线程工厂（ThreadFactory），这些参数的概述虽然准确，但未能触及面试官的真正关注点，因此只能算作基础水平，评分大约在及格线附近。

钻石级回答：

在准确列举出线程池的关键参数之后，我会进一步深入探讨线程池的执行流程，特别是execute()方法的执行细节。具体而言，当调用execute()方法提交一个任务时，线程池会按照以下步骤处理：

在这里插入图片描述

**1、检查线程池状态：**首先，检查线程池当前的状态，如果线程池已关闭，则直接拒绝新任务。

**2、尝试创建新线程：**如果当前线程数少于核心线程数（corePoolSize），则尝试立即创建一个新线程来执行任务，无需将任务放入队列等待。

**3、任务入队：**如果当前线程数已达到核心线程数，但任务队列未满，则将新任务放入任务队列中等待执行。

**4、动态增加线程：**若任务队列已满，且当前线程数未达到最大线程数（maximumPoolSize），则尝试再创建一个新线程来执行任务，而不是阻塞等待。

**5、执行拒绝策略：**如果线程池已满（即线程数已达最大线程数且任务队列也满），则根据配置的拒绝策略处理新任务，可能是直接抛出异常、忽略新任务、将任务放入调用者所在的线程中运行，或是将任务放入某个等待队列中稍后再尝试执行。

这样的回答不仅展现了你对线程池参数的熟悉程度，更重要的是，它体现了你对线程池内部执行逻辑的深刻理解，这无疑会给面试官留下深刻印象，从而获得更高的评价。

3. 面试官：你刚也说到了 Worker 继承 AQS 实现了锁机制，那 ThreadPoolExecutor 都用到了哪些锁？为什么要用锁？
回答思路：

1、mainLock 锁：用于访问共享资源（如workers集合）时的同步控制。

2、Worker 线程锁：通过继承AQS实现，用于维护线程的中断状态。

3、锁的必要性：解释为何需要锁来保证线程安全和避免竞态条件。

"ThreadPoolExecutor 内部使用了两种锁机制：

1、mainLock 锁：是一个ReentrantLock实例，用于在访问共享资源（如workers集合、largestPoolSize、completedTaskCount等）时进行同步控制，保证线程安全。

2、Worker 线程锁：Worker类继承自AbstractQueuedSynchronizer（AQS），实现了自己的锁机制，主要用于维护线程的中断状态，确保在执行任务和中断线程时不会出现竞态条件。"

4. 面试官：你在项目中是怎样使用线程池的？Executors 了解吗？
在探讨线程池的应用时，面试官尤为关注你在实际工作环境中的操作实践。当前业界，尤其是遵循阿里巴巴Java开发规范的企业，普遍强调避免直接使用Executors工具类来创建线程池，转而推荐通过显式配置ThreadPoolExecutor的参数来精细管理线程池，以确保系统的稳定性和安全性。在这里插入图片描述

对于Executors工具类的认知，你可以这样表达：我熟悉Executors工具类，并在早期的项目实践中有所应用，但也亲身体验过其潜在风险。具体而言，Executors.newFixedThreadPool和Executors.newSingleThreadExecutor方法创建的线程池内部，依赖于容量上限为Integer.MAX_VALUE的LinkedBlockingQueue队列。这种无界队列在极端情况下可能累积海量待处理任务，进而消耗大量内存资源，最终引发OutOfMemoryError（OOM）。

同样地，Executors.newCachedThreadPool和Executors.newScheduledThreadPool创建的线程池，由于允许最大线程数达到Integer.MAX_VALUE，也存在因创建过多线程而耗尽系统资源的风险，同样可能触发OOM问题。

为了规避这些风险，我在日常工作中自主封装了一系列线程池工具类，这些工具类均设计为内存安全型，要求开发者在创建时明确指定合理的参数值。此外，我还实现了一个内存安全的阻塞队列MemorySafeLinkedBlockingQueue，该队列能够在系统剩余内存接近预设阈值时，智能拒绝新任务的入队，从而有效预防OOM异常的发生，确保应用稳定运行。在这里插入图片描述

在Spring应用环境中，合理利用线程池是提升应用性能与稳定性的关键举措之一。然而，直接使用Java并发包（JUC）中的ThreadPoolExecutor时，我们往往会遇到一个潜在问题：当Spring容器关闭时，若线程池任务队列中仍有待处理任务，这些任务可能会因容器关闭而未能执行，从而面临任务丢失的风险。

鉴于Spring框架对Bean生命周期的精细管理，Bean在初始化与销毁阶段分别可以通过实现InitializingBean和DisposableBean接口来自定义行为。这一机制为我们提供了在Spring容器启动与关闭时介入线程池管理的契机。

因此，在Spring环境下，推荐避免直接操作JUC的ThreadPoolExecutor，转而采用Spring提供的ThreadPoolTaskExecutor，或是像DynamicTp框架中的DtpExecutor这样专为Spring设计的线程池实现。这些实现不仅封装了线程池的基本功能，还无缝集成了Spring的生命周期管理，确保线程池能够随着Spring容器的启动而初始化，并在容器关闭时妥善处理未完成任务，有效规避任务丢失的风险。

此外，为了进一步提升系统的健売性与可维护性，实施业务隔离的线程池策略至关重要。通过将不同业务类型的任务分配给独立的线程池实例，可以确保任务执行互不干扰，防止高耗时任务占用过多资源而影响低耗时任务的执行。同时，这一做法也有助于避免因任务间潜在的父子关系导致的死锁问题，进而可能引发的内存溢出（OOM）危机。

在实际操作中，我们倾向于通过Spring的@Bean注解来定义多个针对不同业务需求的线程池实例，以实现业务隔离。更进一步，我们借鉴了业界最佳实践，如美团的线程池管理经验，设计并实现了动态可监控的线程池解决方案。该方案充分利用了Spring的配置中心特性，允许我们在服务启动时从配置中心拉取线程池配置，动态生成并注册Bean定义至Spring容器中。这样，业务代码便无需直接声明线程池Bean，而是通过依赖注入的方式轻松获取所需线程池实例，并且支持在运行时动态调整线程池参数，极大地增强了系统的灵活性与可维护性。

通过这样的实践，我不仅提升了系统的健壮性，还深化了对线程池机制的理解，能够在复杂多变的业务场景中灵活运用并发编程技术。

5. 面试官：刚你说到了通过 ThreadPoolExecutor 来创建线程池，那核心参数设置多少合适呢？
a、CPU 密集型运算时：取最大并行数 +1

提示：+1是为了当前面的线程出问题时可以有线程可以及时补上。

b、I/O 密集型运算时：取最大并行数*期望 CPU 利用率（总时间（CPU计算时间+等待时间）/CPU 计算时间）

这公式太偏理论化了，很难实际落地下来，首先很难获取准确的等待时间和计算时间。

关于ThreadPoolExecutor核心参数的设置，并没有一个固定不变的标准答案，因为最合适的参数值高度依赖于具体的应用场景、系统资源、以及期望的性能目标。然而，我们可以根据一些基本原则和经验法则来指导参数的选择。

在设置这些参数时，建议通过压力测试和性能分析来确定最合适的值。可以先设置一个初始值，然后逐步调整并观察系统的性能指标（如吞吐量、响应时间、CPU和内存使用率等），以找到最优的配置。

此外，还需要注意的是，线程池的参数设置并不是一成不变的，随着应用负载和资源状况的变化，可能需要动态调整线程池的参数以适应新的需求。一些高级的线程池实现（如DynamicTp框架）提供了动态调整参数的功能，可以根据系统的实时负载情况自动调整线程池的配置。

6. 面试官：你们线程池是咋监控的？
针对线程池运行状况监控这一挑战，由于线程池的运行过程往往被视为一个“黑盒”，难以直接洞察其内部运作细节，因此如何有效地感知并监控线程池的运行状态成为了一个重要议题。

我们可以这样回答：

我们可以自豪地介绍，为了应对这一挑战，我们自主研发了一套针对ThreadPoolExecutor的增强型线程池管理框架。这一框架不仅实现了对线程池运行的深度洞察，还赋予了其监控告警与动态参数调整的能力，极大地提升了线程池的管理效率与灵活性。

在监控方面，我们充分利用了ThreadPoolExecutor类提供的丰富接口，包括各种get方法来获取线程池的实时运行指标，如活跃线程数、任务队列长度、已完成任务数等关键数据。通过定期调用这些接口，我们能够实时采集到线程池的运行状态数据，并将其上报至统一的监控系统中进行可视化展示。这样，无论是运维人员还是开发人员，都能直观地了解到线程池的运行情况，及时发现潜在的性能瓶颈或异常。

此外，我们还创新性地引入了Endpoint机制，允许用户通过HTTP请求实时查询线程池的详细指标数据。这一功能极大地提升了问题排查的效率，使得在出现性能问题时能够迅速定位到具体的线程池实例及其运行状态。

同时定义了5中告警规则。

a、线程池活跃度告警。活跃度 = activeCount / maximumPoolSize，当活跃度达到配置的阈值时，会进行事前告警。

b、队列容量告警。容量使用率 = queueSize / queueCapacity，当队列容量达到配置的阈值时，会进行事前告警。

c、拒绝策略告警。当触发拒绝策略时，会进行告警。

d、任务执行超时告警。重写 ThreadPoolExecutor 的 afterExecute() 和 beforeExecute()，根据当前时间和开始时间的差值算出任务执行时长，超过配置的阈值会触发告警。

e、任务排队超时告警。重写 ThreadPoolExecutor 的  beforeExecute()，记录提交任务时时间，根据当前时间和提交时间的差值算出任务排队时长，超过配置的阈值会触发告警

7. 面试官：execute() 提交任务和 submit() 提交任务有啥不同？
execute() 和 submit() 是 ThreadPoolExecutor 类中用于提交任务到线程池中的两个方法，它们之间存在一些关键的区别：

1、返回值：

execute(Runnable command) 方法用于提交不需要返回值的任务。它接收一个实现了 Runnable 接口的对象作为参数，但不返回任何结果。

submit(Callable task) 方法用于提交一个返回结果的任务。它接收一个实现了 Callable 接口的对象作为参数，该接口与 Runnable 类似，但 Callable 可以返回一个结果，并且可以抛出异常。submit() 方法返回一个 Future 对象，通过该对象可以获取异步计算的结果。

2、异常处理：

当使用 execute() 方法提交的任务在执行过程中抛出未捕获的异常时，这个异常不会被返回给调用者。实际上，异常会被 ThreadPoolExecutor 捕获并记录在日志中（如果配置了相应的异常处理器）。这意味着调用者无法直接得知任务执行失败的原因。

相反，submit() 方法提交的任务所抛出的任何未捕获异常都会被封装在返回的 Future 对象中。当调用 Future.get() 方法以获取结果时，如果任务执行过程中抛出了异常，那么 get() 方法会抛出一个 ExecutionException，调用者可以通过这个异常获取到原始异常。

3、使用场景：

如果你提交的任务不需要返回值，那么使用 execute() 方法会更简单直接。

如果你需要知道任务执行的结果，或者任务执行过程中可能会抛出异常并且你需要处理这些异常，那么应该使用 submit() 方法。

总结来说，execute() 和 submit() 方法的主要区别在于它们如何处理任务的返回值和异常。选择哪个方法取决于你的具体需求：是否需要返回值以及是否需要处理可能发生的异常。

8. 面试官：什么是阻塞队列？阻塞队列有哪些？
什么是阻塞队列？
阻塞队列（BlockingQueue）是一种特殊的队列，它在继承队列（Queue）基本功能的基础上，增加了阻塞的插入和移除方法。具体来说，当队列满时，插入操作会被阻塞，直到队列不满；当队列空时，移除操作会被阻塞，直到队列非空。阻塞队列是线程安全的，因此常被用于生产者-消费者场景，以解决线程安全问题，并降低开发难度和工作量。

阻塞队列有哪些？
阻塞队列在Java中有多种实现，每种实现都有其特定的应用场景和特性。以下是一些常见的阻塞队列及其特点：

1、ArrayBlockingQueue

特点：基于数组结构的有界阻塞队列。

应用场景：适用于需要限制队列大小的场景，因为它在创建时需要指定容量。

2、LinkedBlockingQueue

特点：基于链表结构的有界阻塞队列（如果不指定容量，则为无界）。

应用场景：适用于元素数量不固定的场景，尤其是当生产者生产数据的速度可能大于消费者消费数据的速度时。

3、PriorityBlockingQueue

特点：支持优先级排序的无界阻塞队列。

应用场景：适用于需要根据元素的优先级进行处理的场景。

4、DelayQueue

特点：使用优先级队列实现的无界阻塞队列，其中的元素只能在其指定的延迟时间到了之后才能从队列中取走。

应用场景：适用于管理延时任务或需要定时执行的任务。

5、SynchronousQueue

特点：一个不存储元素的阻塞队列，每个插入操作必须等待另一个线程的对应移除操作，反之亦然。

应用场景：适用于传递性场景，比如在一个线程中生产的对象直接传递给另一个线程消费，而不保持数据。

6、LinkedTransferQueue

特点：一个由链表结构组成的无界阻塞队列，相对于LinkedBlockingQueue，它增加了transfer和tryTransfer方法。

应用场景：适用于高性能的并发场景，尤其是当消费者线程数少于生产者线程数时，它能有效地传递元素而无需阻塞生产者。

7、LinkedBlockingDeque

特点：一个由链表结构组成的双向阻塞队列，支持从队列的两端插入和删除元素。

应用场景：适用于需要双端操作的场景，如双端队列、栈等。

这些阻塞队列的实现各有特色，选择哪一种取决于具体的应用场景和需求。例如，如果需要限制队列大小，可以选择ArrayBlockingQueue或指定容量的LinkedBlockingQueue；如果需要处理延时任务，可以选择DelayQueue；如果希望元素能按照优先级进行处理，可以选择PriorityBlockingQueue等。

9. 面试官：线程池拒绝策略有哪些？适用场景是怎么样的？
线程池的拒绝策略是在线程池无法再接受新任务时采取的策略，主要有四种，它们分别是：

1、AbortPolicy：

功能：默认策略，当任务无法被线程池执行时，抛出RejectedExecutionException异常。

适用场景：适用于比较关键的业务场景，通过异常反馈系统不能承载更大的并发量，以便及时采取措施。

2、CallerRunsPolicy：

功能：如果添加到线程池失败，则主线程会调用执行器中的execute()方法来运行被拒绝的任务。

适用场景：适用于不允许任务失败的场景，对性能要求不高、并发量较小的场景。由于调用者线程自己执行任务，当多次提交任务时，可能会阻塞后续任务的执行，导致性能和效率降低。

3、DiscardPolicy：

功能：如果添加到线程池失败，则默默丢弃该任务，不抛出任何异常。

适用场景：适用于任务无关紧要，执行与否对系统没有实质性影响的场景。然而，由于任务可能被丢弃，使用时需要谨慎考虑数据丢失的风险。

4、DiscardOldestPolicy：

功能：如果线程池没有能力执行新任务，它会丢弃队列中等待时间最长的任务，并尝试执行新任务。