面试题简述

你平时用过线程池吧？那你说一下线程池有哪些核心参数？提交任务有哪几种方式？如果线程池里的任务抛异常了，你一般是怎么感知和处理的？

面试官想听的

这道题本质上考察的是并发模型的理解。核心考点在于：

1、你是否理解线程池设计背后的资源控制和并发治理，而不仅仅是记住参数；

2、你是否理解不同任务提交方式的语义差异，特别是它们如何影响任务的执行和异常处理；

3、你是否处理过线程池异常丢失的问题，并能在生产环境中做到预防和监控。

面试回答举例

线程池的核心目标在于 复用线程、控制并发度、避免资源耗尽。

线程池的设计围绕着资源控制和并发治理展开，其核心参数都是为了确保在并发任务量突增的情况下，既能保证系统稳定运行，又能避免资源浪费。以下是我对线程池核心参数的理解。

核心参数

1、corePoolSize（核心线程数）：这个参数决定了系统中常驻的线程数。它用于应对系统的稳定负载，保证在没有任务波动的情况下，系统始终保持一定的线程数来处理请求。一般来说，corePoolSize 应该与机器的 CPU 核数或系统的 I/O 比例相关。比如，如果是计算密集型的任务，线程数不能太高；如果是 I/O 密集型，线程数可以适当增大。

2、maximumPoolSize（最大线程数）：这是系统能够承受的最大并发上限，类似一个保护阈值。这个值定义了线程池在面对高并发请求时，可以扩容的最大线程数。合理的设置 maximumPoolSize 可以有效防止线程池过度扩展，导致系统资源耗尽。

3、workQueue（任务队列）：这个参数定义了任务队列的类型和容量。它决定了当系统线程池中的核心线程都在忙碌时，新的任务是被放入队列排队等待，还是直接增加新的线程来执行。如果使用有界队列，当队列满时，线程池会拒绝任务；如果使用无界队列，可能会导致内存溢出。常用的队列有：LinkedBlockingQueue（有界队列）、SynchronousQueue（每个提交的任务都会立即有一个线程来执行）等。

4、keepAliveTime（非核心线程空闲时间）：这个参数控制非核心线程的回收时间。当线程池中的线程数量超过核心线程数时，这些非核心线程会被保留一段时间，如果空闲时间超过这个设定值，线程池会回收这些线程。这可以防止高并发时大量线程一直占用系统资源，降低内存浪费。

5、RejectedExecutionHandler（拒绝策略）：当线程池的任务队列满，且线程池的线程数已经达到 maximumPoolSize 时，线程池会拒绝新任务。RejectedExecutionHandler 定义了任务拒绝时的行为。常见的策略有：AbortPolicy（默认）: 抛出 RejectedExecutionException；CallerRunsPolicy: 由调用线程执行该任务，阻塞当前调用线程；DiscardOldestPolicy: 丢弃最旧的任务；DiscardPolicy: 丢弃当前任务。

这些参数和设计可帮助我们在系统负载高峰时做出合理决策，从而避免线程池内存泄漏、系统崩溃。

总结： 我理解这套参数设计的顺序是先用核心线程，再排队，再扩容，最后拒绝。这些设计确保了线程池的性能和稳定性，并有效控制了系统的资源使用。

提交任务的方式

线程池提供了几种不同的任务提交方式，每种方式的语义和异常处理方式也不一样：

1、execute(Runnable)：这是线程池中最简单的提交方式，它不关心任务的返回值，也没有异常回调机制。适合那些fire-and-forget的任务，比如日志记录、定时任务等。如果任务执行过程中发生异常，这个异常会被吞掉，不会反馈给调用者。

2、submit(Callable/Runnable)：这个方法会返回一个 Future 对象，调用者可以通过 Future.get() 获取任务的执行结果或异常。适用于需要任务执行结果或者捕获异常的情况。不过需要注意，Future.get() 会阻塞调用线程，直到任务完成。

3、invokeAll / invokeAny： 这两个方法适用于批量任务的提交：invokeAll：提交一组任务并等待所有任务完成；invokeAny：提交一组任务，只要有一个任务完成就返回结果。

通常情况下，submit 是最常用的提交方式，因为它能返回 Future，并能让我们获取任务的执行结果和异常。

异常处理

异常处理是线程池中非常重要的环节，尤其是在并发任务多、异常可能被吞掉的情况下。以下是我处理线程池异常的一些常用做法：

1、任务内部的 try-catch： 这是最直接、最推荐的方式。对于每个提交的任务，最好在任务内部做好异常捕获，避免异常直接传播到线程池。这样即使任务失败，也不会影响其他任务的执行。

2、Future.get() 捕获 ExecutionException： 如果你用 submit 提交任务，异常会被封装在 ExecutionException 中。调用 Future.get() 时，我们可以捕获到该异常。对于异步执行结果比较重要的任务，我会优先使用 submit，这样可以确保任何异常都不会被吞掉。

3、自定义 ThreadFactory + UncaughtExceptionHandler： 对于全局未捕获的异常，ThreadFactory 和 UncaughtExceptionHandler 是一个不错的选择。通过自定义线程工厂和异常处理器，我们可以监控到线程池中所有未被捕获的异常，从而进行日志记录或通知运维人员。

4、日志和监控： 在生产环境中，我通常会配合日志和监控，避免线程池中的异常“静默失败”。通过监控任务执行时间、异常频率等指标，能够快速定位潜在问题。

由浅入深分析

1、线程池参数背后的资源治理

• corePoolSize 不是越大越好，它应当与系统的 CPU 核数 / I/O 比例相关。
• 任务队列的选择直接影响到系统的行为：有界队列：让线程池能够承受较大的负载，防止无休止的扩容。无界队列：允许任务积压，但可能导致内存溢出。

2、提交方式的本质区别

• execute 是典型的 fire-and-forget，适合无需关心任务结果的场景。
• submit 提供了任务的结果和异常捕获，适合有执行结果或错误处理需求的场景。
• 很多线上事故的本质：你用 submit 提交任务，但从来没调用 get()，导致异常被吞掉。

3、为什么线程池中的异常会消失？

线程池不会把异常抛回主线程。如果你用 submit 提交任务，异常被封装在 Future 中，如果没有调用 get()，异常就会像黑洞一样消失。

面试加分点

1、能明确指出线程池设计的核心目的是资源治理，而非简单的性能调优。

2、清晰区分 execute 和 submit 的行为差异，特别是它们如何处理异常。

3、介绍 UncaughtExceptionHandler 和 监控体系，表明你已经考虑过生产环境。

4、能够提到线程池参数背后的并发控制策略，而不仅仅是性能优化。