java线程池配置参数包括corepoolsize、maximumpoolsize、keepalivetime、unit、workqueue、threadfactory和rejectedexecutionhandler。1.corepoolsize是核心线程数，始终存活除非设置允许超时；2.maximumpoolsize是最大线程数，决定高峰期可创建的线程上限；3.keepalivetime和unit控制非核心线程空闲存活时间；4.workqueue用于缓存任务，常见类型有arrayblockingqueue（有界队列，适合任务量可控场景）、linkedblockingqueue（无界或有界队列，适合突发任务但需防内存溢出）、synchronousqueue（不存储任务，适合强同步场景）、priorityblockingqueue（优先级队列）和delayqueue（延迟获取任务）；5.threadfactory用于自定义线程创建过程，便于调试与监控；6.rejectedexecutionhandler为拒绝策略，包括abortpolicy（抛异常）、callerrunspolicy（调用者执行）、discardoldestpolicy（丢弃最老任务）和discardpolicy（静默丢弃），也可自定义策略以实现日志记录、告警或降级处理。合理配置需结合任务类型（cpu密集型建议corepoolsize为cpu核数+1，io密集型可根据阻塞系数调整线程数），并配合负载测试与性能监控持续优化。
Java多线程池的配置参数是平衡系统资源、响应速度和稳定性的关键，理解并合理设置它们能显著提升应用性能。这不仅仅是填几个数字那么简单，它关乎你的应用在不同负载下的表现，甚至决定了它能否在高峰期稳定运行。
多线程池的核心，ThreadPoolExecutor，其构造函数里那几个参数，每一个都蕴含着对系统行为的深远影响。首先是corePoolSize，核心线程数。这就像你公司里的正式员工，无论活多活少，他们都在岗。这些线程创建后会一直存在，除非设置了allowCoreThreadTimeOut。然后是maximumPoolSize，最大线程数，这代表了你的公司在业务高峰期能雇佣的临时工加上正式员工的总数。当核心线程都在忙，并且工作队列也满了的时候，线程池才会创建新的非核心线程，直到达到这个上限。
接着是keepAliveTime和unit，非核心线程的空闲存活时间。当线程池中的线程数量超过corePoolSize，且这些非核心线程在keepAliveTime时间内没有任务可执行时，它们就会被终止，回收资源。这很像临时工，活干完了就让他们回家，节省开支。
立即学习“Java免费学习笔记（深入）”；
workQueue，工作队列，这是线程池最关键的一个环节。当提交的任务数超过corePoolSize时，多余的任务会先被放入这个队列中等待。它的选择直接影响到线程池的行为模式：是任务先入队等待，还是先创建新线程？不同的队列类型有不同的特性，比如有界队列和无界队列，这会深刻影响系统的内存占用和任务拒绝策略的触发时机。
threadFactory，线程工厂，这通常是一个被忽视但很有用的参数。它允许你自定义如何创建线程，比如给线程命名，设置优先级，或者绑定异常处理器。这对于调试和监控来说非常方便，能让你一眼看出是哪个线程池里的哪个任务出了问题。
最后是RejectedExecutionHandler，拒绝策略。当线程池和工作队列都满了，无法再接收新任务时，就会触发这个策略。这就像你的公司实在忙不过来了，你得决定是拒绝新客户，还是让老客户等，甚至让客户自己想办法。这是系统过载时的最后一道防线，选择不当可能导致任务丢失或系统崩溃。
如何根据业务场景选择合适的线程池大小？
选择合适的线程池大小，并没有一个放之四海而皆准的公式，它更像是一门艺术，需要结合你的应用特性、硬件资源以及预期的负载模式来权衡。我个人在实践中，通常会从任务类型入手去思考。
如果你的任务是CPU密集型的，比如进行大量计算、数据加密解密、图像处理等，那么线程池的核心线程数就应该接近于你的CPU核心数。为什么呢？因为这类任务会长时间占用CPU，过多的线程反而会导致频繁的上下文切换，降低整体效率。通常我会设置corePoolSize为“CPU核数 + 1”，那个“+1”是为了应对偶尔的页缺失或少量IO操作。maximumPoolSize可以和corePoolSize保持一致，或者略大一点，因为这类任务的并发瓶颈通常不在于线程数量，而在于CPU的计算能力。工作队列通常会选择一个有界队列，防止任务堆积导致内存溢出。
而对于IO密集型任务，比如数据库操作、网络请求、文件读写等，情况就大不相同了。这类任务在执行时会有大量的等待时间，线程在等待IO完成时并不会占用CPU。因此，你可以设置更多的线程来提高并发度，让CPU在等待一个IO任务时可以去处理另一个任务。一个经验法则可以是“CPU核数 * (1 + 阻塞系数)”，阻塞系数通常在0.8到0.9之间。这意味着你可能需要设置一个远大于CPU核心数的corePoolSize和maximumPoolSize。工作队列的选择可以更灵活，无界队列在IO密集型场景下可以容纳更多等待中的任务，但要警惕内存消耗。
当然，这只是一个起点。在实际部署前，你还需要进行充分的负载测试和性能监控。观察CPU利用率、内存使用情况、线程池队列长度以及任务的平均响应时间。这些数据会告诉你当前的配置是否合理，是需要增加线程数来提高吞吐量，还是减少线程数以降低资源消耗和上下文切换开销。记住，没有“完美”的配置，只有“最适合当前场景”的配置。
线程池中的队列（BlockingQueue）有哪些类型，各自适用场景是什么？
线程池里的工作队列，也就是BlockingQueue，是连接任务生产者和线程消费者之间的桥梁，它的选择直接决定了任务的缓冲机制和线程池的扩容逻辑。这块我经常看到有人直接用默认的LinkedBlockingQueue，但其实不同的队列类型，在特定场景下表现差异巨大。
首先是ArrayBlockingQueue，它是一个基于数组的有界阻塞队列。这意味着你必须在创建时指定它的容量。它的优点是内部实现是数组，数据结构相对紧凑，并且可以指定是公平（fair）还是非公平（non-fair）访问。公平模式下，等待时间最长的线程会优先获取锁，避免饥饿，但性能开销会大一些。我通常会在需要严格控制任务数量，并且对内存占用有较高要求，或者需要公平性保证的场景下使用它。比如，一个上游系统发送数据量非常大，但我们下游处理能力有限，用ArrayBlockingQueue可以防止任务无限堆积，从而避免OOM。
然后是LinkedBlockingQueue，它是一个基于链表的阻塞队列。默认情况下，它的容量是Integer.MAX_VALUE，也就是一个几乎无界的队列。这使得它在处理突发大量任务时表现良好，因为任务可以直接入队而无需等待线程创建。它的吞吐量通常比ArrayBlockingQueue高。但无界队列的风险在于，如果任务生产速度持续大于消费速度，它会无限增长，最终耗尽内存导致OOM。我个人在使用时，除非明确知道任务量不会失控，或者有其他机制来限制任务提交，否则我都会给它指定一个合理的容量，把它当成一个有界队列来用。
SynchronousQueue则是一个非常特殊的队列，它不存储任何元素。每次插入操作都必须等待一个对应的移除操作，反之亦然。它更像是一个直接传递的通道，而不是一个存储容器。这种队列的特点是吞吐量极高，因为它没有内部存储的开销。它适用于那些任务提交和执行之间需要强同步的场景，或者当线程池的maximumPoolSize被设置得很大，希望优先创建新线程而不是将任务入队时。使用SynchronousQueue时，线程池的行为更倾向于“有多少任务就创建多少线程（直到maximumPoolSize），而不是先排队”。
还有PriorityBlockingQueue，一个支持优先级的无界阻塞队列。它会根据元素的自然顺序或构造函数中提供的Comparator来决定元素的优先级。这在需要处理不同优先级任务的场景下很有用，比如高优先级的用户请求应该比低优先级的后台任务更快得到执行。但需要注意的是，它也是无界的，同样存在内存溢出的风险。
最后是DelayQueue，一个无界阻塞队列，只有当元素的延迟时间到期时才能从队列中获取元素。这在实现定时任务调度、缓存过期等场景非常实用。
选择队列时，我的思考路径通常是：首先评估任务量是否可控，如果不可控，我会倾向于有界队列（如ArrayBlockingQueue或有界的LinkedBlockingQueue）；如果任务需要优先级，PriorityBlockingQueue是首选；如果追求极致的吞吐量且任务是瞬时传递的，SynchronousQueue值得考虑。但无论哪种，都要结合实际的业务场景和预期的负载进行测试验证。
线程池的拒绝策略（RejectedExecutionHandler）有哪些，又该如何选择和自定义？
拒绝策略，即RejectedExecutionHandler，是线程池在资源耗尽时的最后一道防线。当线程池中的核心线程都在忙碌，工作队列也已满，并且当前线程数已经达到maximumPoolSize时，新提交的任务就会被拒绝。理解并合理设置拒绝策略至关重要，它决定了你的系统在过载时如何优雅地降级，而不是直接崩溃。
Java ThreadPoolExecutor 内置了四种标准的拒绝策略：
-
AbortPolicy(默认策略)：这是最粗暴但也最直接的策略。它会直接抛出RejectedExecutionException运行时异常。这意味着如果你的代码没有捕获这个异常，程序可能会崩溃。我通常在对任务丢失非常敏感，且希望通过异常来明确告知调用方系统已过载，需要采取措施（比如限流、熔断）的场景下使用它。 -
CallerRunsPolicy：这个策略比较有趣。它不会拒绝任务，而是让提交任务的线程（调用者线程）自己去执行这个任务。这实际上是一种反压机制：当线程池处理不过来时，它会把压力传导回任务提交方，从而减缓任务提交的速度。我个人比较喜欢在一些批处理或后台服务中使用它，因为它能有效避免任务丢失，并起到一种天然的限流作用。但要注意，如果调用者线程是主线程或关键线程，可能会导致其阻塞，影响用户体验。 -
DiscardOldestPolicy：这个策略会丢弃队列中等待时间最久（最老）的那个任务，然后尝试重新提交当前被拒绝的任务。它适用于那些对实时性要求较高，可以接受少量任务丢失，但希望系统能持续运行的场景。比如，在处理实时数据流时，偶尔丢弃一些旧数据可能比完全停止处理要好。 -
DiscardPolicy：这个策略更直接，它会直接丢弃当前尝试提交的任务，不抛出任何异常。这意味着任务会静默地丢失。我很少直接使用它，除非是在一些对任务丢失完全不敏感的场景，比如日志记录（但即使是日志，也希望能尽量记录下来）。因为它缺乏反馈，一旦任务丢失，很难追踪问题。
在实际项目中，我发现内置策略往往不能完全满足所有需求，这时候就需要自定义拒绝策略。自定义策略非常简单，你只需要实现RejectedExecutionHandler接口，并重写它的rejectedExecution方法。
例如，一个常见的自定义需求是记录被拒绝的任务日志并发送告警。你可以这样做：
public class CustomRejectedExecutionHandler implements RejectedExecutionHandler {
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
// 记录日志
System.err.println("Task " + r.toString() + " rejected from " + executor.toString());
// 发送告警（例如通过邮件、短信或监控系统）
// LogManager.getLogger().warn("Thread pool is full, task rejected: " + r.toString());
// AlertService.sendAlert("Thread pool overload!", r.toString());
// 根据业务需求，可以选择：
// 1. 抛出异常：throw new RejectedExecutionException("Task " + r.toString() + " rejected.");
// 2. 将任务重新放回队列（如果队列允许且有空间）：executor.getQueue().offer(r);
// 3. 降级处理：比如将任务放入一个降级队列，等待后续处理或持久化到磁盘
// FallbackQueue.add(r);
}
}在选择和自定义拒绝策略时，我的核心原则是：明确你对任务丢失的容忍度，以及你希望系统在过载时如何表现。是宁愿抛异常让系统停下来以便修复，还是宁愿丢弃一些任务也要保持部分服务可用？是希望将压力传导回上游，还是默默消化？这些思考决定了你最终的选择。拒绝策略不是万能药，它只是系统过载时的一个应急预案，真正的解决方案通常需要结合限流、熔断、降级等更全面的架构设计。
