线程池如何运行，核心参数有什么作用、如何配置？

核心回答

以 Java 的 ThreadPoolExecutor 为例，线程池把任务提交与线程执行分开，通过复用工作线程、缓冲短时突发并限制并发，控制资源消耗。

正常运行且线程能够创建时，新任务按以下顺序处理：

1. 工作线程数小于 corePoolSize：优先新建线程执行该任务。
2. 达到核心线程数：先尝试把任务放进 workQueue，由工作线程后续取出执行。
3. 队列无法接收：再尝试创建线程，直到 maximumPoolSize。
4. 仍不能接收：调用拒绝策略。线程池关闭后提交新任务，也会触发拒绝。

核心参数中，corePoolSize 决定优先建立多少工作线程，maximumPoolSize 限制池内线程总量，workQueue 决定能缓冲多少任务；keepAliveTime 和 unit 控制空闲线程回收；threadFactory 负责创建与命名线程；handler 决定接不下任务时怎样处理。

配置要看任务的计算与等待比例、CPU 和内存、下游连接数、业务时限及峰值流量，再通过压测调整。线程数、队列和拒绝策略要一起设计，不能只套“CPU 核数”或“核数的两倍”。

参数如何共同影响任务执行？

核心线程默认也是按需创建，不是构造线程池时就全部启动；需要时可以提前启动。核心线程数也不是“正在忙的线程数”：低于这个数量时，新任务会优先创建线程，即使已有线程空闲。

保活时间默认用于线程数超过核心数时的空闲回收；启用 allowCoreThreadTimeOut 后，核心数量以内的空闲线程也可超时回收。它限制的是空闲等待时间，不是任务最多能运行多久。

队列选择会改变扩容方式：

• 有界队列吸收一定突发，满后才继续扩线程。队列过大可能让任务排到超时，最大线程数迟迟用不上。
• 无界或近似无界队列通常一直能接收，因而不会通过“入队失败”扩到最大线程数；继续提高 maximumPoolSize 不能解决积压，还可能一直占用堆内存。
• SynchronousQueue 不存储等待任务，而是直接交接。没有线程立即接收时，就需要创建线程或拒绝，所以必须限制最大线程数并评估突发流量。

假设核心数 5、最大数 10、队列容量 10，依次快速提交 30 个慢任务，且提交期间没有任务完成，使用抛异常的拒绝策略，调用方捕获拒绝异常后继续尝试余下任务：前 5 个由新线程执行，接着 10 个入队，再接着 5 个通过扩容执行，最后 10 个被拒绝。这个推演依赖上述条件；若任务已经完成或拒绝策略改为调用者执行，结果会变化。

线程数、队列和拒绝策略怎样配置？

先看任务占用什么资源。 计算密集任务重点看可用 CPU 与上下文切换，增加大量线程通常不会增加有效算力；阻塞 I/O 任务可以用更多线程重叠等待，但上限仍受数据库连接池、HTTP 连接数、下游配额和内存约束。多个实例、多个线程池也要共享这些容量预算。

再看任务能等多久。 队列主要吸收短时突发，容量要同时满足等待期限和内存预算。任务携带大请求体或集合时，即使队列长度不大也可能占用大量堆。长期提交速率高于完成速率时，扩大队列只是延迟失败，需要限流、优化任务、扩容或把适合异步处理的任务交给可靠队列。

最后明确接不下任务时的业务行为。 AbortPolicy 抛出异常，由调用方明确失败或补偿；CallerRunsPolicy 在池仍运行时让提交线程执行任务，可减慢提交速度，但也可能占住 Web 请求线程或延长事务。池已关闭时它会丢弃任务，因此不是可靠交付保证。丢弃策略只适合业务确实允许丢失的任务；关键任务需要可观测的拒绝和可靠补偿。

不同耗时、优先级和下游依赖的任务，可按需隔离线程池，避免慢报表任务占满在线请求的执行资源；不必为每个接口都建一个池。

怎样发现异常和积压？

监控应同时覆盖提交与完成速率、工作与活跃线程数、队列长度和等待时间、任务执行时间、拒绝数、异常与超时数，再关联 CPU、内存、连接池和下游延迟。

排队先上涨而执行时间稳定，通常要检查突发流量与容量；执行时间先变长，再出现排队，应先查慢任务、锁等待和下游故障。单看队列长度，无法判断它正在消化积压还是持续恶化。

通过 execute() 直接执行的任务若抛出未捕获异常，可能使工作线程异常结束；通过 submit() 提交的任务通常把异常保存在返回的 Future 中，调用方应消费结果、处理失败，或统一记录任务异常。afterExecute() 也不能只看传入的 Throwable，因为被 FutureTask 保存的异常不会直接传进来。

常见追问

线程池有了拒绝策略，就有背压了吗？ 不一定。抛异常后若调用方立即无界重试，压力反而放大；调用者执行也只有在确实减慢上游提交时才形成反馈。还需要明确限流、退避、降级或停止拉取等行为。

等待 Future 超时，任务会自动停止吗？ 不会。等待超时只结束本次等待；取消也只是按实现尝试中断，任务要能响应中断，下游调用还需配置超时，避免超时请求继续长期占用线程。

参考资料