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

2.2 线程池工作流程

这个流程很多人记错顺序：先核心线程 → 再队列 → 再非核心线程 → 最后拒绝。不是核心线程满了就创建非核心线程。

2.3 核心参数设置原则

为什么CPU密集型用"CPU核数+1"？

CPU密集型任务的特点：任务执行时CPU一直在工作，几乎没有等待时间（等IO、等锁等）。

理想情况：N个CPU核心同时跑N个线程，CPU利用率100%，没有浪费。

为什么+1？多一个线程，是为了防止某个线程因为偶尔的内存缺页中断、GC停顿等情况导致CPU空闲。这个备用线程可以立刻顶上去，保持CPU持续满载。

如果线程太多（比如设成100），100个线程竞争N个CPU核心，线程上下文切换（Context Switch）本身就消耗大量CPU，反而更慢。

为什么IO密集型用"CPU核数 * 2"？

IO密集型任务的特点：任务大部分时间在等IO（磁盘读写、网络请求、数据库查询等），CPU实际工作时间很短。

当线程A在等IO时，CPU是空闲的。如果有线程B，CPU可以立刻切换去执行线程B，提高CPU利用率。

公式推导：如果一个任务有50%的时间在等IO，50%时间在用CPU：

理想情况：当线程A等IO时，线程B用CPU；当线程B等IO时，线程A用CPU
2个线程就能让CPU100%利用
等待比例越高，需要的线程越多

更精确的公式（Little's Law变种）：

线程数 = CPU核数 × (1 + 等待时间/计算时间)

纯CPU密集（等待时间=0）：线程数 = CPU核数 × 1 = CPU核数（+1是实践经验）
等待时间/计算时间=1（各50%）：线程数 = CPU核数 × 2
等待时间/计算时间=9（等待90%，计算10%）：线程数 = CPU核数 × 10

三、标准答案 + 代码验证

3.1 线程池参数配置示例

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

public class ThreadPoolConfig {
    
    /**
     * CPU密集型线程池
     * 场景：大量计算、图像处理、数据压缩等
     */
    public static ExecutorService cpuIntensivePool() {
        int cpuCores = Runtime.getRuntime().availableProcessors();
        
        return new ThreadPoolExecutor(
            cpuCores + 1,        // 核心线程数：CPU核数+1
            cpuCores + 1,        // 最大线程数：和核心线程数一样，不需要扩展
            0L,                  // 非核心线程存活时间（核心=最大，这个参数无意义）
            TimeUnit.MILLISECONDS,
            new LinkedBlockingQueue<>(100), // 有界队列，防止OOM
            new NamedThreadFactory("cpu-pool"),
            new ThreadPoolExecutor.CallerRunsPolicy() // 队列满时，调用者自己执行
        );
    }
    
    /**
     * IO密集型线程池
     * 场景：数据库查询、HTTP调用、文件读写等
     */
    public static ExecutorService ioIntensivePool() {
        int cpuCores = Runtime.getRuntime().availableProcessors();
        
        // 假设IO等待时间是计算时间的1倍，用CPU核数*2
        // 实际应根据监控数据调整这个倍数
        int poolSize = cpuCores * 2;
        
        return new ThreadPoolExecutor(
            poolSize,            // 核心线程数
            poolSize * 2,        // 最大线程数（允许在高峰期扩展）
            60L,                 // 非核心线程空闲60秒后销毁
            TimeUnit.SECONDS,
            new LinkedBlockingQueue<>(500), // IO密集型队列可以稍大
            new NamedThreadFactory("io-pool"),
            new ThreadPoolExecutor.AbortPolicy() // 超出直接拒绝，快速失败
        );
    }
    
    /**
     * 混合型线程池
     * 场景：既有计算又有IO的业务逻辑
     * 最佳实践：拆分成两个线程池分别处理CPU部分和IO部分
     */
    public static void mixedTaskBestPractice(Runnable cpuTask, Runnable ioTask) {
        ExecutorService cpuPool = cpuIntensivePool();
        ExecutorService ioPool = ioIntensivePool();
        
        // CPU密集部分提交给cpuPool
        cpuPool.submit(cpuTask);
        // IO密集部分提交给ioPool
        ioPool.submit(ioTask);
    }
    
    /**
     * 自定义线程工厂：给线程取有意义的名字，方便排查问题
     */
    static class NamedThreadFactory implements ThreadFactory {
        private final String namePrefix;
        private final AtomicInteger counter = new AtomicInteger(1);
        
        NamedThreadFactory(String namePrefix) {
            this.namePrefix = namePrefix;
        }
        
        @Override
        public Thread newThread(Runnable r) {
            Thread t = new Thread(r, namePrefix + "-" + counter.getAndIncrement());
            t.setDaemon(false); // 用户线程，不是守护线程
            return t;
        }
    }
    
    public static void main(String[] args) throws InterruptedException {
        System.out.println("CPU核数：" + Runtime.getRuntime().availableProcessors());
        
        ExecutorService pool = ioIntensivePool();
        
        // 提交10个模拟IO密集型任务
        for (int i = 0; i < 10; i++) {
            final int taskId = i;
            pool.submit(() -> {
                try {
                    Thread.sleep(1000); // 模拟IO等待
                    System.out.println("任务" + taskId + "完成，线程：" + Thread.currentThread().getName());
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            });
        }
        
        pool.shutdown();
        pool.awaitTermination(10, TimeUnit.SECONDS);
    }
}

3.2 监控线程池运行状态

import java.util.concurrent.*;

public class ThreadPoolMonitor {
    
    public static void printPoolStatus(ThreadPoolExecutor pool, String poolName) {
        System.out.printf("[%s] 核心线程数=%d, 当前线程数=%d, 活跃线程数=%d, " +
                "已完成任务数=%d, 队列大小=%d, 最大线程数=%d%n",
            poolName,
            pool.getCorePoolSize(),
            pool.getPoolSize(),
            pool.getActiveCount(),
            pool.getCompletedTaskCount(),
            pool.getQueue().size(),
            pool.getLargestPoolSize() // 历史最大线程数
        );
    }
    
    public static void main(String[] args) throws InterruptedException {
        ThreadPoolExecutor pool = new ThreadPoolExecutor(
            4, 8, 60L, TimeUnit.SECONDS,
            new LinkedBlockingQueue<>(20),
            Executors.defaultThreadFactory(),
            new ThreadPoolExecutor.CallerRunsPolicy()
        );
        
        // 定时监控
        ScheduledExecutorService monitor = Executors.newSingleThreadScheduledExecutor();
        monitor.scheduleAtFixedRate(
            () -> printPoolStatus(pool, "myPool"),
            0, 1, TimeUnit.SECONDS
        );
        
        // 提交任务
        for (int i = 0; i < 50; i++) {
            pool.submit(() -> {
                try {
                    Thread.sleep(500);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            });
        }
        
        pool.shutdown();
        pool.awaitTermination(30, TimeUnit.SECONDS);
        monitor.shutdown();
    }
}

3.3 四种拒绝策略对比

// AbortPolicy（默认）：抛出RejectedExecutionException
// 适合：快速失败场景，调用方需要处理异常

// CallerRunsPolicy：由提交任务的线程自己执行
// 适合：不想丢任务，但可以接受响应变慢

// DiscardPolicy：静默丢弃任务，无通知
// 适合：允许丢失的非关键任务（如日志、统计）

// DiscardOldestPolicy：丢弃队列最老的任务，再尝试提交
// 适合：实时性要求高，新任务比旧任务重要

// 自定义拒绝策略：记录日志、发告警、存DB等
public class CustomRejectHandler implements RejectedExecutionHandler {
    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        // 1. 记录拒绝日志
        System.err.println("任务被拒绝！当前队列大小：" + executor.getQueue().size());
        // 2. 可以选择：保存到数据库后续重试、发告警、降级处理等
        // 3. 不要在这里做耗时操作，会阻塞拒绝处理链
    }
}

四、面试官追问

追问1：为什么Java建议使用ThreadPoolExecutor而不是Executors工厂方法？

我的回答：Executors的几个工厂方法都有潜在问题。newFixedThreadPool和newSingleThreadExecutor使用了无界的LinkedBlockingQueue（Integer.MAX_VALUE大小），如果任务提交速度超过处理速度，队列会无限增长导致OOM。newCachedThreadPool的maximumPoolSize是Integer.MAX_VALUE，在高并发下可能创建大量线程，每个线程占用约512KB栈内存，也会OOM。手动创建ThreadPoolExecutor，所有参数都是可见的、有意义的，能强迫你思考每个参数的取值，也更容易在出问题时定位原因。阿里Java开发手册中明确禁止使用Executors的工厂方法。

追问2：线程池的任务队列选哪种？LinkedBlockingQueue vs ArrayBlockingQueue vs SynchronousQueue？

我的回答：LinkedBlockingQueue是链表实现，可以指定容量上限，也可以不指定（默认无界），读写分别用两把锁（head锁和tail锁），并发性能好，适合大多数场景。ArrayBlockingQueue是数组实现，必须指定容量，读写共用一把锁，在读写都很频繁时可能比LinkedBlockingQueue慢，但内存更紧凑。SynchronousQueue没有存储能力，每次入队都必须等待出队，常用于newCachedThreadPool，相当于直接交给线程执行，不排队。生产环境推荐用有界的LinkedBlockingQueue，防止OOM，同时通过队列大小监控反压情况。

追问3：线程数设多少最好，有没有通用公式？

我的回答：没有通用公式，只有参考公式。CPU密集型：CPU核数+1是起点；IO密集型：CPU核数2是起点，但如果IO等待比更高（比如等待外部HTTP接口，RT 500ms），需要设更大，可能是CPU核数5或更多。最可靠的方法是：先用公式估算，然后用压测工具（JMeter、Gatling等）模拟生产流量，观察线程池的活跃线程数、队列长度、任务等待时间等指标，动态调整。也可以考虑使用动态线程池（如美团的dynamic-tp），支持不重启应用的情况下修改线程池参数，便于线上调优。

五、同类题目举一反三

CompletableFuture默认用哪个线程池，应该怎么配置？

CompletableFuture默认使用ForkJoinPool.commonPool()，这是JVM级别的公共池，默认线程数是CPU核数-1。在Web应用中，所有CompletableFuture默认共享这一个池，如果某个异步任务耗时长，会影响所有使用CompletableFuture的地方。生产环境中，对于IO密集型的异步任务，应该指定自定义线程池，不要用公共池：CompletableFuture.supplyAsync(() -> ..., myIoPool)。

六、踩坑实录

坑一：用了Executors.newFixedThreadPool，队列无限增长OOM

有个项目做异步文件处理，用了Executors.newFixedThreadPool(10)。由于文件处理速度跟不上提交速度，LinkedBlockingQueue无限增长，最终OOM。改用有界队列后，配合CallerRunsPolicy，当队列满时调用者自己处理文件，形成了自然的背压机制。

坑二：IO密集型任务用了CPU密集型配置，吞吐量极低

有个HTTP代理服务，核心业务是转发HTTP请求，纯IO等待。但线程池配成了CPU核数+1，只有5个线程（4核机器）。测试时TPS只有几十，5个线程一直在等IO，CPU利用率不到5%，白白浪费了资源。改成CPU核数×10后，TPS提升了将近10倍。

坑三：线程池没有设置线程名，排查时根本找不到哪个线程在做什么

线上出问题要排查时，用jstack看线程快照，看到一堆pool-1-thread-1、pool-2-thread-3，完全不知道对应哪个业务线程池。从那以后，所有线程池都必须自定义ThreadFactory，按业务命名，比如order-pool-1、payment-pool-2，排查问题效率提升了十倍。

七、总结

线程池参数设置没有银弹，但有方法论：

理解任务类型：CPU密集型还是IO密集型，决定了核心线程数的基准
用公式作为起点：CPU密集：核数+1；IO密集：核数×2（等待比高则更多）
用有界队列：防止OOM，通过拒绝策略处理溢出
命名线程：自定义ThreadFactory，方便排查
监控和调整：压测观察实际运行指标，动态调优

面试时能说出公式并说清楚原理，再配合一两个实际踩坑经历，这道题基本满分。