ThreadPoolExecutor 介绍

什么是ThreadPoolExecutor？

ThreadPoolExecutor 是一种线程池实现类，它是 Java 平台 java.util.concurrent 包中提供的一个核心组件，用于管理和调度线程以高效地执行一组可并行或异步处理的任务。作为一个 ExecutorService 的子类，ThreadPoolExecutor 提供了一套灵活且强大的线程池框架，允许用户自定义线程池的各种行为和参数，以适应不同应用场景的需求。

以下是 ThreadPoolExecutor 的主要特点和功能：

1. 线程管理：

   • 核心线程池大小（corePoolSize）：线程池中始终保持活跃的最小线程数。即使这些线程没有任务执行，它们也不会被销毁。
   • 最大线程池大小（maximumPoolSize）：线程池允许的最大线程数。当任务队列满载且仍有新任务提交时，线程池会创建新的线程，但总数不超过这个上限。

2. 任务队列：

   • 工作队列（workQueue）：用于暂存等待执行的任务。当核心线程都在忙碌且未达到最大线程数时，新提交的任务会被放入队列中等待。常见的队列类型包括无界队列（如 LinkedBlockingQueue）、有界队列（如 ArrayBlockingQueue）和优先级队列（如 PriorityBlockingQueue）等。

3. 线程创建与回收：

   • 线程工厂（threadFactory）：用于创建新线程的工厂对象，允许自定义线程的名称、优先级、是否为守护线程等属性。
   • 饱和策略（RejectedExecutionHandler）：当线程池和工作队列都已满，无法再接受新任务时，定义如何处理新提交的任务。预定义策略包括：
     • AbortPolicy：抛出 RejectedExecutionException。
     • CallerRunsPolicy：调用者线程（即提交任务的线程）自己执行该任务。
     • DiscardPolicy：默默地丢弃新任务。
     • DiscardOldestPolicy：移除队列中最旧的任务，尝试提交当前任务。

4. 任务调度与执行：

   • 任务提交：通过 execute(Runnable) 或 submit(Callable) 方法提交任务到线程池。
   • 任务执行：线程池根据当前线程数和任务队列状态决定是否创建新线程、复用已有线程或将任务入队等待。任务执行完毕后，线程可能会被回收（取决于线程池配置和策略）或继续等待队列中的下一个任务。

5. 监控与控制：

   • 统计信息：提供诸如线程池大小、活动线程数、已完成任务数等统计信息。
   • 生命周期管理：
     • shutdown()：不再接受新任务，等待现有任务执行完毕后关闭线程池。
     • shutdownNow()：尝试停止所有正在执行的任务，并返回尚未开始的任务列表。
     • awaitTermination(long, TimeUnit)：阻塞等待线程池终止，或者在指定超时时间内返回。
     • isTerminated()：检查线程池是否已经完全终止。
     • 可以重写 terminated() 方法，在线程池完全终止后执行特定清理或通知操作。

总的来说，ThreadPoolExecutor 提供了一个高度可配置和可扩展的线程池框架，能够有效地支持任务的并发执行、资源管理和异常处理，帮助开发者在编写多线程应用时简化线程管理的复杂性，提高程序性能和响应速度，同时防止因过度创建线程而导致的系统资源耗尽问题。

ThreadPoolExecutor 在项目中的场景及使用方式

ThreadPoolExecutor 在实际项目中使用非常广泛，尤其是在涉及多线程任务处理、异步执行、任务调度等场景。由于它提供了对线程池大小、任务队列、线程创建策略、拒绝策略等的高度自定义能力，使得它能很好地适应各种复杂的应用需求。以下是一些常见使用 ThreadPoolExecutor 的场景及使用方式：

1. 异步任务处理：
在 Web 服务、微服务等环境中，为了提高响应速度，常常将耗时较长但不需要立即返回结果的操作（如发送邮件、文件上传、数据库批量操作等）异步化。通过 ThreadPoolExecutor 提交这些任务，主线程可以立即返回给客户端，而实际工作在后台线程池中完成。

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    corePoolSize, // 核心线程数
    maximumPoolSize, // 最大线程数
    keepAliveTime, // 空闲线程存活时间
    TimeUnit.SECONDS, // 时间单位
    new LinkedBlockingQueue<>(queueCapacity), // 工作队列
    new ThreadFactoryBuilder().setNameFormat("async-task-%d").build(), // 线程工厂
    new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略
);

// 提交异步任务
executor.execute(() -> {
    // 执行具体的业务逻辑
});

2. 定时任务与周期任务：
虽然 ScheduledExecutorService 更适合定时任务，但有时也可以通过 ThreadPoolExecutor 结合 ScheduledFuture 实现简单的定时或周期性任务调度。

ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(poolSize);
Runnable task = () -> {
    // 任务逻辑
};

// 延迟执行
ScheduledFuture<?> future = scheduler.schedule(task, delay, TimeUnit.MILLISECONDS);

// 周期性执行
future = scheduler.scheduleAtFixedRate(task, initialDelay, period, TimeUnit.SECONDS);

3. 任务分发与负载均衡：
在分布式系统中，ThreadPoolExecutor 可用于将接收到的任务均匀分配给后台工作线程，实现负载均衡。例如，在消息处理系统中，接收到消息后，将其提交至线程池执行，避免单个线程处理过多消息导致的瓶颈。

4. 数据库连接池管理：
尽管不是直接使用 ThreadPoolExecutor，但许多数据库连接池实现（如 HikariCP、Druid 等）内部都会基于类似原理管理数据库连接，确保高效且可控地复用和分配连接资源。

使用注意事项：

• 合理配置线程池参数：根据系统的资源限制、任务特性（CPU 密集型或 I/O 密集型）以及预期的并发负载来设定核心线程数、最大线程数、队列容量等参数。

• 监控与调整：在生产环境中，应定期监控线程池的运行状态（如线程数、队列长度、任务执行情况等），根据实际情况动态调整参数或优化任务处理逻辑。

• 异常处理：确保在任务执行代码中妥善处理异常，避免线程池中的线程因未捕获异常而终止。可以使用 Future.get() 方法捕获异步任务的异常，或通过自定义 RejectedExecutionHandler 处理无法接纳的任务。

• 资源清理：在应用关闭时，应正确关闭线程池，防止资源泄漏。通常调用 executor.shutdown()，并确保所有任务完成后才退出应用。

综上所述，ThreadPoolExecutor 在项目中被广泛应用，尤其在处理异步任务、定时任务、任务分发与负载均衡等方面。正确配置和使用 ThreadPoolExecutor 能有效提升系统并发处理能力，改善响应速度，同时避免因不当的线程管理引发的问题。

异步任务处理实际场景的例子

以下是一个实际场景的例子，说明如何在 Web 应用程序中使用异步任务处理技术（如 ThreadPoolExecutor）来提高响应速度和用户体验：

场景描述：
假设我们正在开发一个电商网站，用户在下单购买商品后，系统需要执行一系列后台操作，包括：

1. 订单持久化：将订单信息保存到数据库。
2. 库存扣减：减少相关商品的库存数量。
3. 支付处理：调用第三方支付平台接口发起支付请求。
4. 发送通知：向用户和管理员发送订单确认邮件或短信。
5. 生成订单报告：异步生成包含订单详细信息的 PDF 报告，以便用户下载。

这些操作中，有些可能涉及到网络通信、数据库事务处理、文件生成等耗时操作。如果全部在用户提交订单的主线程中同步执行，会导致用户界面长时间无响应，严重影响用户体验。因此，我们可以利用异步任务处理将这些操作分解为异步任务，交给 ThreadPoolExecutor 执行。

异步任务处理样例代码：

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.ThreadPoolExecutor;

public class OrderService {

    private static final int CORE_POOL_SIZE = 5;
    private static final int MAX_POOL_SIZE = 10;
    private static final int QUEUE_CAPACITY = 200;
    private static final long KEEP_ALIVE_TIME = 60L;
    private static final TimeUnit TIME_UNIT = TimeUnit.SECONDS;

    private final ExecutorService executor;

    public OrderService() {
        this.executor = new ThreadPoolExecutor(
                CORE_POOL_SIZE,
                MAX_POOL_SIZE,
                KEEP_ALIVE_TIME,
                TIME_UNIT,
                new LinkedBlockingQueue<>(QUEUE_CAPACITY),
                new ThreadFactoryBuilder().setNameFormat("order-service-pool-%d").build(),
                new ThreadPoolExecutor.CallerRunsPolicy()
        );
    }

    public void processOrder(Order order) {
        // 同步执行订单持久化和库存扣减
        orderRepository.save(order);
        inventoryService.decrease(order.getItems());

        // 异步执行后续操作
        executor.execute(() -> {
            try {
                paymentGateway.processPayment(order.getPaymentInfo());
            } catch (PaymentException e) {
                log.error("Failed to process payment for order {}", order.getId(), e);
            }
        });

        executor.execute(() -> {
            try {
                notificationService.sendOrderConfirmationEmail(order.getUser());
                notificationService.sendAdminNotification(order);
            } catch (NotificationException e) {
                log.error("Failed to send notifications for order {}", order.getId(), e);
            }
        });

        executor.execute(() -> {
            try {
                reportGenerator.generateOrderReport(order).ifPresent(reportFile -> {
                    fileStorageService.upload(reportFile);
                    order.setReportUrl(fileStorageService.getPublicUrl(reportFile));
                    orderRepository.update(order);
                });
            } catch (ReportGenerationException | FileStorageException e) {
                log.error("Failed to generate and store order report for order {}", order.getId(), e);
            }
        });

        // 向用户返回订单已创建的消息，此时异步任务已经开始执行
        return "Order created successfully. Details will be sent via email.";
    }
}

在这个例子中：

• 创建了一个 ThreadPoolExecutor 实例，配置了核心线程数、最大线程数、队列容量、线程存活时间等参数，用于执行异步任务。
• 当用户下单时，processOrder 方法首先同步执行订单持久化和库存扣减，这两个操作必须原子化完成，不能异步处理。
• 接下来，分别将支付处理、发送通知、生成订单报告三个耗时操作封装为 Runnable 对象提交给 executor 执行。这些操作在后台线程中异步进行，不影响主线程快速返回结果给用户。
• 如果异步任务执行过程中发生异常，会在任务内捕获并记录错误日志，确保不会影响其他任务或线程池的正常运行。

通过这样的异步任务处理设计，用户在提交订单后几乎立即收到“订单创建成功”的提示，而实际的支付处理、通知发送、报告生成等工作则在后台默默进行。这样既提升了用户体验，又充分利用了系统的并发处理能力，避免了单个长耗时操作阻塞整个请求流程。

构造函数中参数中 corePoolSize，maximumPoolSize，keepAliveTime等参数的合适的值

//构造函数
public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                          RejectedExecutionHandler handler) {
 //xxx
}

corePoolSize、maximumPoolSize 和 keepAliveTime 是 ThreadPoolExecutor 中非常关键的几个参数，它们的值设置需要考虑以下几个因素：

1. corePoolSize（核心线程数）：

• 这是线程池在初始阶段和空闲时保持的最小线程数。这些线程即使在没有任务执行时也会一直存在，直到线程池被关闭。
• 建议设置为系统在正常负载下可以充分利用的并发线程数。这个值通常与系统的 CPU 核心数有关，如果是 CPU 密集型任务，一般设置为 CPU 核心数或略大于核心数（如核心数 + 1）。如果是 I/O 密集型任务，由于这类任务在等待 I/O 时不会占用 CPU，所以可以设置得更高，但要注意不要超过系统承受能力，避免过度竞争资源。
• 另外，还需要考虑任务的性质和相互依赖关系。如果有大量相互独立、可以并行处理的任务，corePoolSize 可以适当增大；如果任务间存在较多的同步限制，可能需要减小该值以避免过度并发带来的锁竞争。

2. maximumPoolSize（最大线程数）：

• 这是线程池允许的最大线程数。当工作队列满且仍有新任务提交时，线程池会尝试创建新线程直至达到这个上限。
• 建议设置为系统在极端负载下仍能承受的最大并发线程数。这个值应高于 corePoolSize，以应对任务突然激增的情况。设置过高可能导致系统资源（如内存、CPU 时间片）过度分配，设置过低则可能导致任务积压，无法充分利用系统资源。
• 考虑到任务的突发性，maximumPoolSize 可设置为 corePoolSize 的几倍，具体倍数需根据历史负载数据、系统资源状况和任务的预期增长速度来判断。

3. keepAliveTime（线程空闲存活时间）：

• 当线程池中的线程数超过 corePoolSize，且空闲时间达到 keepAliveTime 后，多余的线程会被回收。这对于节省系统资源、防止资源浪费是有益的。
• 对于 CPU 密集型任务，可以设置较小的 keepAliveTime（如几秒或几十秒），因为在这种情况下，闲置线程意味着浪费 CPU 资源。
• 对于 I/O 密集型任务或任务提交较为平稳的场景，可以设置较大的 keepAliveTime（如几分钟），以便在任务波动时避免频繁创建和销毁线程带来的开销。

综合建议：

• corePoolSize：通常设置为 CPU 核心数或略大于核心数，根据任务性质和系统资源适当调整。
• maximumPoolSize：通常设置为 corePoolSize 的 1.5 到 3 倍，具体根据预期负载波动和系统资源承受能力来定。
• keepAliveTime：对于 CPU 密集型任务，设置为几秒到几十秒；对于 I/O 密集型任务或任务提交稳定的场景，设置为几分钟。

请注意，这些值只是通用的指导原则，实际应用中应根据具体业务需求、系统性能监控数据以及负载测试结果进行细致调整和优化。同时，配合使用合适的工作队列（如 LinkedBlockingQueue、ArrayBlockingQueue 等）和饱和策略（如 AbortPolicy、CallerRunsPolicy 等），可以进一步完善线程池的配置。

在 ThreadPoolExecutor 构造函数中，workQueue是指定工作队列的类型，而handler则是指定饱和策略（当线程池和队列都满时如何处理新提交的任务）。具体来说：

workQueue：工作队列（BlockingQueue<Runnable> 类型）
这是用于存储待执行任务的队列。Java 中提供了多种实现，每种都有不同的特性。常见的选项包括：

• LinkedBlockingQueue：

  • 默认无界（除非在构造时指定容量），理论上可以无限增长，可能导致内存溢出风险。
  • 具有良好的吞吐量，适用于大多数场景，尤其是当任务提交速率和处理速率相对稳定时。

• ArrayBlockingQueue：

  • 需要指定固定容量，队列满时会阻塞提交任务的线程。
  • 适用于对队列大小有严格限制或希望控制任务积压程度的场景。

• SynchronousQueue：

  • 特殊的无缓冲队列，每个插入操作必须等待另一个线程的对应移除操作，反之亦然。
  • 通常会导致线程池立即创建新线程处理任务，除非已有空闲线程可用。
  • 适用于任务提交和处理速率相匹配且要求低延迟的场景。

• PriorityBlockingQueue：

  • 优先级队列，元素按照自然排序或自定义比较器的顺序出队。
  • 适用于需要任务按照优先级顺序执行的场景。

最常用的工作队列类型通常是 LinkedBlockingQueue，因为它无需显式指定容量（默认无界），且在大多数情况下能提供良好的性能和易用性。不过，实际选择应根据应用的具体需求，如任务处理速度的稳定性、是否有严格的内存限制、是否需要任务优先级等来确定。

handler：饱和策略（RejectedExecutionHandler 类型）
当线程池和工作队列都已满，无法再接收新任务时，饱和策略决定了如何处理这些超出处理能力的任务。Java 提供了几种预定义的策略实现：

• AbortPolicy（默认策略）：

  • 直接抛出 RejectedExecutionException，阻止任务的提交。

• CallerRunsPolicy：

  • 由提交任务的线程自己来执行任务，而非放入队列。这会降低主线程处理其他请求的速度，起到一定的流量控制作用。

• DiscardPolicy：

  • 默默地丢弃新任务，不进行任何处理。

• DiscardOldestPolicy：

  • 移除队列中最早进入还未开始执行的任务，尝试将新任务放入队列。

除了使用预定义策略，还可以自定义 RejectedExecutionHandler 实现，以满足特定的应用需求。

最常用的饱和策略可能是 CallerRunsPolicy，因为它能确保任务不会丢失，同时通过让提交任务的线程执行任务，可以一定程度上抑制新任务的提交速度，有助于缓解系统压力。然而，具体选择应根据业务对任务丢失的容忍度、是否需要立即反馈失败、是否有能力处理额外负载等因素来定。在某些场景下，可能需要结合日志记录、报警通知或其他补偿措施来处理被拒绝的任务。

workQueue 中 工作队列容量 QUEUE_CAPACITY 大小多少是合适的

QUEUE_CAPACITY（工作队列容量）是 ThreadPoolExecutor 中另一个重要的参数，它决定了工作队列能容纳的最大任务数量。选择合适的 QUEUE_CAPACITY 值需要考虑以下几个方面：

1. 系统资源限制：

• 如果工作队列是无界的（如 LinkedBlockingQueue 未指定容量），理论上可以无限增长，但可能导致内存溢出风险。因此，对于资源有限的系统，应设置一个合理的上限，避免队列过度膨胀。

2. 任务处理速度与提交速度的匹配程度：

• 如果任务处理速度远大于任务提交速度，可以选择较大的 QUEUE_CAPACITY，以便在处理速度较慢时有足够的缓冲空间，避免频繁创建和销毁线程。
• 如果任务提交速度远大于处理速度，过大的 QUEUE_CAPACITY 可能导致大量任务积压，增加响应时间。此时，可以适当减小 QUEUE_CAPACITY，使系统在任务堆积时更快地触发饱和策略（如创建新线程、拒绝任务等），及时反馈系统压力。

3. 任务的优先级和实时性要求：

• 对于具有优先级的任务，可能需要使用优先级队列（如 PriorityBlockingQueue），此时 QUEUE_CAPACITY 的设置应考虑任务的平均大小和优先级分布，确保高优先级任务能够及时得到处理。
• 对于实时性要求较高的场景，可能希望尽快处理新提交的任务，而非让它们在队列中等待。这种情况下，可以设置较小的 QUEUE_CAPACITY，促使线程池尽快创建新线程或触发拒绝策略。

4. 系统的稳定性和监控能力：

• 设置适当的 QUEUE_CAPACITY 并配合有效的监控手段，可以帮助识别系统何时接近饱和状态，以便及时采取措施（如增加资源、优化任务处理逻辑、调整线程池参数等）。

综合建议：

• 对于大部分场景，QUEUE_CAPACITY 可设置为几百到几千的范围，具体数值应根据系统的任务提交速率、处理速度、资源限制以及监控能力来定。
• 对于资源受限的系统或任务实时性要求较高的场景，可以设置较小的 QUEUE_CAPACITY（如几十到几百），以快速反馈系统压力。
• 对于任务处理速度远大于提交速度、资源充足的系统，可以设置较大的 QUEUE_CAPACITY（如几千甚至更大），以提供足够的缓冲空间。
• 对于具有优先级的任务，应结合优先级队列的特点和任务的优先级分布来设置 QUEUE_CAPACITY。

与前面提到的 corePoolSize、maximumPoolSize 和 keepAliveTime 一样，QUEUE_CAPACITY 的设置也需要根据实际应用情况进行细致调整和优化，并结合系统监控数据进行持续评估和调整。

本文通过通义千问提问整理而来
https://tongyi.aliyun.com/qianwen/