Java线程池定制指南：ThreadPoolExecutor详解

答案：定制ThreadPoolExecutor需根据业务类型合理设置核心参数。计算密集型任务应设corePoolSize为CPU核心数±1，maximumPoolSize可相近；IO密集型可提高corePoolSize至2倍CPU核心数以上，配合较大maximumPoolSize。优先选用有界队列如ArrayBlockingQueue防OOM，避免无界队列导致内存溢出。SynchronousQueue适用于高实时性场景。拒绝策略按业务容忍度选型：AbortPolicy用于关键任务并配异常重试，CallerRunsPolicy实现调用方限流，DiscardPolicy或DiscardOldestPolicy处理可丢弃任务。通过ThreadFactory命名线程便于排查，并设置UncaughtExceptionHandler捕获Runnable异常；Callable任务需在Future.get()时处理ExecutionException。结合beforeExecute、afterExecute和terminated扩展监控与资源清理，提升线程池可观测性与稳定性。

在Java里，要说定制线程池，那核心其实就是围绕ThreadPoolExecutor来的。它不是让你简单地扔个任务进去就算了，而是要你像个老道的工程师一样，精细地去调配线程资源，确保你的应用在高并发下既能跑得快，又能稳如磐石，不至于因为线程数量失控而OOM，或者因为任务堆积而响应迟缓。说白了，就是把并发这把双刃剑，磨砺得更趁手，更安全。

解决方案

定制ThreadPoolExecutor，本质上就是通过它的构造函数来定义线程池的行为。这个构造函数参数有点多，但每一个都至关重要，它们共同决定了线程池的“性格”：

public ThreadPoolExecutor(int corePoolSize, // 核心线程数
                          int maximumPoolSize, // 最大线程数
                          long keepAliveTime, // 空闲线程存活时间
                          TimeUnit unit, // 存活时间单位
                          BlockingQueue workQueue, // 任务队列
                          ThreadFactory threadFactory, // 线程工厂
                          RejectedExecutionHandler handler) // 拒绝策略

我的理解和实践是这样的：

1. corePoolSize (核心线程数): 这就像你公司里的“正式员工”。即使没活儿干，他们也不会被解雇。我通常会根据CPU核心数和任务类型来定。如果是计算密集型任务，通常设为CPU核心数加1或2；如果是IO密集型，可以适当调高，因为线程在等待IO时，CPU可以去处理其他线程。初期我总喜欢给个大数，后来发现很多时候反而拖慢了速度，因为上下文切换的开销也很大。

2. maximumPoolSize (最大线程数): 这是你公司的“临时工上限”。当核心线程都在忙，任务队列也满了，线程池就会创建新的线程来处理任务，但数量不会超过这个值。这个参数设置得太高，内存和CPU资源可能会被耗尽；太低，又可能导致任务大量被拒绝。这是一个需要权衡的点，我一般会根据预期的峰值并发量和系统资源来估算。

3. keepAliveTime 和 unit (空闲线程存活时间): 这些是用来管理“临时工”的。当线程数超过corePoolSize，并且这些“临时工”在keepAliveTime时间内没有接到任务，它们就会被销毁。这有助于节省资源。我通常会设一个比较短的时间，比如60秒，让不必要的线程尽快回收。

4. workQueue (任务队列): 这是线程池的“待办事项列表”。当核心线程都在忙时，新提交的任务会先放到这里排队。选择哪种队列非常关键：

   • ArrayBlockingQueue：有界队列，固定大小。适合任务量可预测，需要防止无限堆积的场景。
   • LinkedBlockingQueue：默认无界队列（构造时可指定容量）。如果使用无界队列，maximumPoolSize参数就基本失效了，因为任务会无限堆积，直到内存溢出。这是我刚开始最容易犯的错误，导致生产环境OOM。
   • SynchronousQueue：一个不存储元素的阻塞队列。每个插入操作都必须等待一个对应的移除操作。适合需要立即执行，或者任务量瞬时爆发但能快速处理的场景。
   • PriorityBlockingQueue：支持优先级的无界队列。如果你的任务有优先级之分，可以考虑。

5. threadFactory (线程工厂): 这个参数允许你自定义线程的创建过程。比如，你可以给线程命名，设置是否为守护线程，或者设置线程的优先级。给线程起个有意义的名字，在排查问题时简直是神器，一眼就能看出是哪个业务模块的线程在搞事情。

6. RejectedExecutionHandler (拒绝策略): 当线程池已经达到maximumPoolSize，并且任务队列也满了，新提交的任务就会被拒绝。这时候就需要一个拒绝策略来处理。默认有四种：

   • AbortPolicy (默认)：直接抛出RejectedExecutionException。这是最严格的，适合不允许任务丢失的场景。
   • CallerRunsPolicy：提交任务的线程自己来执行这个任务。这会降低提交任务的速度，给线程池一个“喘息”的机会。
   • DiscardPolicy：直接丢弃任务，不抛异常。适合那些不那么重要的任务。
   • DiscardOldestPolicy：丢弃队列里最老的任务，然后尝试重新提交当前任务。如果你的任务有“新鲜度”要求，这个可能有用。 我通常会根据业务对任务丢失的容忍度来选择，有时候也会实现自定义的拒绝策略，比如把任务记录到日志或持久化到数据库，稍后重试。

一个简单的定制示例：

import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;

public class CustomThreadPoolDemo {

    public static void main(String[] args) {
        // 自定义线程工厂，方便日志追踪
        ThreadFactory namedThreadFactory = new ThreadFactory() {
            private final AtomicInteger threadNumber = new AtomicInteger(1);
            private final String namePrefix = "my-custom-pool-thread-";

            @Override
            public Thread newThread(Runnable r) {
                Thread t = new Thread(r, namePrefix + threadNumber.getAndIncrement());
                if (t.isDaemon()) t.setDaemon(false); // 确保不是守护线程
                if (t.getPriority() != Thread.NORM_PRIORITY) t.setPriority(Thread.NORM_PRIORITY); // 设为普通优先级
                System.out.println("创建新线程: " + t.getName());
                return t;
            }
        };

        // 自定义拒绝策略：记录日志并尝试让提交者自己执行
        RejectedExecutionHandler customRejectHandler = (r, executor) -> {
            System.err.println("任务被拒绝！当前任务：" + r.toString() + "，线程池状态：" + executor.toString());
            // 尝试让提交者线程自己执行任务，以降低提交速度，给线程池一些处理时间
            if (!executor.isShutdown()) {
                System.out.println("提交者线程尝试执行被拒绝的任务...");
                r.run();
            }
        };

        // 创建一个定制的线程池
        // 核心线程数2，最大线程数4，空闲线程存活时间60秒，使用有界队列（容量10）
        ThreadPoolExecutor executor = new ThreadPoolExecutor(
                2, // corePoolSize
                4, // maximumPoolSize
                60L, // keepAliveTime
                TimeUnit.SECONDS, // unit
                new ArrayBlockingQueue<>(10), // workQueue: 有界队列，防止OOM
                namedThreadFactory, // threadFactory
                customRejectHandler // handler
        );

        // 提交一些任务
        for (int i = 0; i < 20; i++) {
            final int taskId = i;
            try {
                executor.submit(() -> {
                    System.out.println(Thread.currentThread().getName() + " 正在执行任务 " + taskId);
                    try {
                        TimeUnit.MILLISECONDS.sleep(200); // 模拟任务执行时间
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                        System.err.println(Thread.currentThread().getName() + " 任务 " + taskId + " 被中断。");
                    }
                });
            } catch (RejectedExecutionException e) {
                System.err.println("任务 " + taskId + " 提交时直接被拒绝了！");
            }
        }

        // 关闭线程池
        executor.shutdown();
        try {
            if (!executor.awaitTermination(5, TimeUnit.SECONDS)) {
                System.err.println("线程池未能正常关闭，尝试强制关闭...");
                executor.shutdownNow();
            }
        } catch (InterruptedException e) {
            executor.shutdownNow();
            Thread.currentThread().interrupt();
        }
        System.out.println("线程池已关闭。");
    }
}

定制线程池时，如何根据业务场景选择核心参数？

选择ThreadPoolExecutor的核心参数，从来都不是拍脑袋决定的事，它需要结合你的业务类型、系统资源以及对延迟和吞吐量的要求来综合考量。我个人觉得，这就像在设计一个生产线，你得知道你的产品是什么，生产能力有多大，才能合理配置工人数量和流水线长度。

对于corePoolSize和maximumPoolSize，最关键的是区分你的任务是计算密集型还是I/O密集型。

• 计算密集型任务： 比如加密解密、复杂数据处理、图像渲染等，这类任务主要消耗CPU资源。如果线程数过多，会导致大量的上下文切换，反而降低效率。我的经验是，corePoolSize通常设置为 CPU核心数 + 1 或 CPU核心数。maximumPoolSize可以和corePoolSize保持一致，或者略高一点点，以应对偶尔的突发情况。
• I/O密集型任务： 比如网络请求、数据库读写、文件操作等，这类任务在大部分时间里都在等待I/O操作完成，CPU利用率不高。这时，可以设置较高的corePoolSize，甚至可以达到 *2 CPU核心数** 或更高，因为当一个线程等待I/O时，另一个线程可以利用CPU。maximumPoolSize可以进一步调高，但要警惕资源（如数据库连接、网络带宽）瓶颈。

至于workQueue的选择，这直接影响了线程池的缓冲能力和对maximumPoolSize的实际作用：

• ArrayBlockingQueue (有界队列): 当你需要明确控制任务堆积量，防止内存无限增长时，这是个好选择。比如你的系统处理能力有限，不能接受无限任务堆积导致崩溃，宁愿拒绝一些任务。容量的设置需要根据内存大小和单个任务的平均大小来估算。
• LinkedBlockingQueue (无界队列): 如果不指定容量，它就是无界的。这意味着任务会无限入队，直到内存溢出。这种情况下，maximumPoolSize实际上就失去了作用，因为线程池永远不会达到需要创建“临时工”的条件，所有任务都会先在队列里排队。我一般只在任务提交速度远小于处理速度，且任务总量不大的场景下谨慎使用，或者在构造时指定一个合理的容量，使其变成有界队列。
• SynchronousQueue: 这种队列不存储元素，提交任务必须立即有线程来接收。它适合那些对实时性要求高，或者任务提交和处理速度非常接近的场景。如果提交任务时没有可用线程，任务会立即被拒绝。这通常需要搭配一个较大的maximumPoolSize。

keepAliveTime则是一个资源回收的策略。如果你希望线程池在负载降低后能尽快释放多余的线程资源，就设置一个较短的时间；如果线程创建销毁开销较大，或者你希望线程池能保持一定规模以应对下一次突发，可以设置一个较长的时间。我的习惯是，除非有特殊需求，否则60秒左右是一个比较均衡的起点。

总而言之，没有“万能”的参数组合。最好的方法是先根据业务类型和经验值设置一个初始配置，然后在实际负载下进行压力测试和监控，观察CPU、内存、线程数、任务队列长度等指标，再逐步调优。

线程池任务拒绝策略有哪些，我们该如何选择和处理异常？

当线程池不堪重负，无法再接受新任务时，拒绝策略就派上用场了。这就像你的餐厅客满了，你是礼貌地告知客人稍后再来，还是直接把人拒之门外，或者让厨师加班加点在门口炒菜？Java提供了四种内置策略，但我们也可以自定义，这在实际业务中非常灵活。

内置的拒绝策略：

1. AbortPolicy (默认策略): 这是最直接的。当任务被拒绝时，它会直接抛出一个RejectedExecutionException。这意味着你的调用方必须捕获这个异常并处理。我个人觉得，如果业务对任务丢失零容忍，并且希望立即知道任务无法被执行的原因，那么这个策略是合适的。但它也要求你的代码有健壮的异常处理机制。

2. CallerRunsPolicy: 这个策略很有意思，它不会抛异常，也不会丢弃任务。而是让提交任务的线程（也就是调用execute()或submit()的那个线程）自己去执行这个被拒绝的任务。这样做的好处是，可以有效地降低任务提交的速度，给线程池一个“喘息”的机会，避免系统过载。我发现这在一些批处理或后台服务中特别有用，可以起到一种“自我限流”的效果。缺点是，如果提交任务的线程是主线程，可能会导致UI卡顿或服务响应变慢。

3. DiscardPolicy: 这个策略最简单粗暴，直接丢弃被拒绝的任务，不抛出任何异常。如果你有一些不那么重要，或者可以容忍丢失的任务（比如一些日志记录、统计数据上报），这个策略可以考虑。但一定要确保业务上可以接受任务丢失。

4. DiscardOldestPolicy: 这个策略会丢弃任务队列中“最老”的那个任务（也就是等待时间最长的任务），然后尝试重新提交当前被拒绝的任务。它适用于那些任务具有时效性，宁愿丢弃旧任务也要处理新任务的场景。比如一些实时数据处理，旧数据可能就没有价值了。

如何选择拒绝策略？

选择哪种拒绝策略，完全取决于你的业务场景对任务丢失的容忍度、对系统过载的应对方式以及对用户体验的影响。

• 高优先级、不可丢失的任务： 优先考虑AbortPolicy，并在调用方做好异常捕获和重试机制。或者自定义策略，将任务持久化到消息队列或数据库，稍后重试。
• 可以接受延迟，但不能丢失，且希望自我保护的系统： CallerRunsPolicy是个不错的选择。
• 低优先级、可丢失的任务： DiscardPolicy或DiscardOldestPolicy。

处理线程池中的异常：

线程池中的任务执行过程中也可能抛出异常。这块的处理，我踩过不少坑。

• 对于Runnable任务： execute()方法提交的Runnable任务，如果内部抛出未捕获的异常，线程池的默认行为是直接终止该线程。这可能会导致线程池中的线程数量减少。为了更好地处理这些异常，你可以：
  • 在Runnable的run()方法内部使用try-catch块捕获所有可能的异常。
  • 通过ThreadFactory为创建的线程设置一个UncaughtExceptionHandler。这样，任何未捕获的异常都会被这个处理器捕获。
• 对于Callable任务： submit()方法提交的Callable任务，其异常会被封装到返回的Future对象中。只有当你调用Future.get()方法时，异常才会被抛出（以ExecutionException的形式）。这意味着，如果你不调用get()方法，异常可能永远不会被发现。因此，对于Callable任务，务必在Future.get()时做好异常处理。

// 使用UncaughtExceptionHandler处理Runnable任务的异常
ThreadFactory namedThreadFactoryWithExceptionHandler = r -> {
    Thread t = new Thread(r);
    t.setName("exception-handling-thread-" + t.getId());
    t.setUncaughtExceptionHandler((thread, e) -> {
        System.err.println("线程 [" + thread.getName() + "] 捕获到未处理异常: " + e.getMessage());
        e.printStackTrace();
    });
    return t;
};

// 提交Callable任务并处理其异常
Future future = executor.submit(() -> {
    if (Math.random() > 0.5) {
        throw new RuntimeException("Callable任务执行失败！");
    }
    return "Callable任务执行成功！";
});

try {
    String result = future.get(); // 阻塞获取结果，此处会抛出ExecutionException
    System.out.println("Future结果: " + result);
} catch (InterruptedException | ExecutionException e) {
    System.err.println("获取Future结果时发生异常: " + e.getMessage());
    if (e.getCause() != null) {
        System.err.println("原始异常: " + e.getCause().getMessage());
    }
}

良好的异常处理是确保线程池稳定运行的关键一环，它能让你及时发现问题，而不是等到系统崩溃才察觉。

除了基本参数，还有哪些高级特性可以提升ThreadPoolExecutor的实用性？

ThreadPoolExecutor不仅仅是那几个构造函数参数，它还提供了一些钩子方法和扩展点，能让你的线程池更加“智能”和“可控”。这些高级特性，往往在系统监控、性能分析和故障排查时显得尤为重要。

1. ThreadFactory的深度利用： 前面提到了ThreadFactory可以用来命名线程，这只是冰山一角。更进一步，你可以：

   • 设置线程组： 将同一线程池的线程归属到同一个ThreadGroup下，方便统一管理和监控。
   • 设置守护线程： 如果你的线程池任务是辅助性的，不希望它阻碍JVM退出，可以设置为守护线程。但要非常小心，守护线程会在JVM退出时被强制终止，可能导致数据丢失或不一致。
   • 设置线程优先级： 虽然Java的线程优先级在不同操作系统上的表现不尽相同，但在某些特定场景下，你可以尝试调整优先级来优化资源分配。
   • 记录线程创建信息： 在newThread方法中记录线程的创建时间、创建者等信息，便于后期审计和问题追踪。

2. 扩展ThreadPoolExecutor的生命周期方法：ThreadPoolExecutor提供了三个受保护的方法，你可以在自定义的子类中重写它们，以实现更精细的控制和监控：

   • beforeExecute(Thread t, Runnable r): 在任务r执行之前被调用。我经常用它来做日志记录（记录任务开始时间）、线程本地变量的初始化，或者设置一些监控指标（比如任务执行计数器）。
   • afterExecute(Runnable r, Throwable t): 在任务r执行完成之后被调用，无论任务是正常完成还是抛出异常。这是清理资源、记录任务耗时、更新任务状态或处理任务异常（特别是对于那些Runnable任务）的绝佳位置。如果t不为null，说明任务执行过程中抛出了异常。
   • terminated(): 当线程池完全关闭（所有任务都执行完毕，所有工作线程都已终止）时被调用。这是一个很好的机会来释放线程池可能