Java 线程池核心参数配置与拒绝策略调优

Java 中使用线程池能有效控制资源消耗、提升系统稳定性。但若参数配置不当，轻则性能下降，重则引发内存溢出或任务丢失。本文手把手教你根据实际业务场景，合理设置 ThreadPoolExecutor 的核心参数，并选择最合适的拒绝策略。

1. 理解线程池的五个核心参数

创建线程池时，通常通过 new ThreadPoolExecutor(...) 构造函数传入以下五个关键参数：

1. corePoolSize：核心线程数。即使空闲，这些线程也不会被回收（除非设置了 allowCoreThreadTimeOut(true)）。
2. maximumPoolSize：最大线程数。当任务队列满后，可临时创建的新线程上限。
3. keepAliveTime：非核心线程的空闲存活时间。超过此时间且无任务处理，线程会被回收。
4. unit：keepAliveTime 的时间单位，如 TimeUnit.SECONDS。
5. workQueue：用于缓存待执行任务的阻塞队列。

注意：Executors 工具类提供的 newFixedThreadPool、newCachedThreadPool 等方法存在隐患（如无界队列可能导致 OOM），建议始终使用 ThreadPoolExecutor 显式构造。

2. 按业务类型确定核心线程数

线程数并非越多越好。过多线程会因上下文切换开销反而降低吞吐量。应根据任务是 CPU 密集型 还是 IO 密集型 来估算。

CPU 密集型任务

这类任务主要消耗 CPU（如加密、复杂计算），几乎没有 IO 等待。最佳线程数接近 CPU 核心数。

计算公式：
$$ \text{corePoolSize} = \text{CPU 核心数} $$

可通过代码获取：

int cpuCores = Runtime.getRuntime().availableProcessors();

IO 密集型任务

这类任务大部分时间在等待 IO（如数据库查询、HTTP 调用）。线程在等待时可让出 CPU，因此可配置更多线程。

估算公式：
$$ \text{corePoolSize} = \text{CPU 核心数} \times (1 + \frac{\text{平均等待时间}}{\text{平均工作时间}}) $$

例如，若任务平均 90% 时间在等 IO（等待时间/工作时间 ≈ 9），CPU 为 4 核，则：
$$ 4 \times (1 + 9) = 40 $$

实际操作中：若无法精确测量，可先设为 CPU 核心数 * 2，再通过压测调整。

3. 选择合适的任务队列

任务队列决定了任务如何排队等待执行。常见选项如下：

关键原则：

• 避免无界队列：LinkedBlockingQueue 若不设容量（默认 Integer.MAX_VALUE），积压任务可能撑爆内存。
• 优先选有界队列：明确设置队列容量（如 new ArrayBlockingQueue<>(100)），配合拒绝策略保障系统稳定。

4. 设置合理的最大线程数与存活时间

maximumPoolSize 应大于 corePoolSize，用于应对突发流量。

• 若使用无界队列（如未设容量的 LinkedBlockingQueue），maximumPoolSize 实际无效——因为队列永远不会满，不会触发创建新线程。
• 若使用有界队列，当队列满且当前线程数小于 maximumPoolSize 时，才会创建新线程。

建议配置：

• 对于 IO 密集型任务，maximumPoolSize 可设为核心线程数的 1.5~2 倍。
• keepAliveTime 通常设为 30~60 秒，单位用 TimeUnit.SECONDS。

示例：

new ThreadPoolExecutor(
    10,                          // corePoolSize
    20,                          // maximumPoolSize
    60L,                         // keepAliveTime
    TimeUnit.SECONDS,            // unit
    new ArrayBlockingQueue<>(100) // workQueue
);

5. 配置拒绝策略应对过载

当线程数达上限且队列已满时，新任务将被拒绝。JDK 提供四种内置策略，也可自定义。

推荐选择：

• 高可用系统：用 CallerRunsPolicy。它让调用方线程执行任务，相当于“背压”，自然降低请求速率。
• 允许丢弃：如日志上报，可用 DiscardPolicy。
• 严禁静默丢弃：避免使用 DiscardPolicy 或 DiscardOldestPolicy，除非明确知晓后果。

自定义拒绝策略示例（记录日志并降级）：

public class LoggingRejectedExecutionHandler implements RejectedExecutionHandler {
    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        System.err.println("Task " + r.toString() + " rejected from " + executor.toString());
        // 可在此处降级处理，如写入本地磁盘或发送告警
    }
}

使用方式：

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    10, 20, 60L, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(100),
    new LoggingRejectedExecutionHandler()
);

6. 完整配置示例与验证步骤

步骤 1：确定业务类型（CPU or IO 密集）
步骤 2：计算 corePoolSize（参考第 2 节）
步骤 3：选择有界队列，如 new ArrayBlockingQueue<>(queueCapacity)
步骤 4：设 maximumPoolSize = corePoolSize * 1.5（向上取整）
步骤 5：设 keepAliveTime = 60，单位 TimeUnit.SECONDS
步骤 6：根据系统容忍度选择拒绝策略（推荐 CallerRunsPolicy）

最终代码模板：

int corePoolSize = 8; // 根据业务计算得出
int maxPoolSize = 12;
int queueCapacity = 100;
long keepAliveSeconds = 60;

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    corePoolSize,
    maxPoolSize,
    keepAliveSeconds,
    TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(queueCapacity),
    new ThreadPoolExecutor.CallerRunsPolicy()
);

验证方法：

• 使用 JMeter 或自研压测工具模拟高并发。
• 监控线程池指标：通过 executor.getQueue().size()、executor.getActiveCount() 等方法观察队列积压和活跃线程数。
• 触发拒绝策略时，确认行为符合预期（如是否降级、是否告警）。

务必在上线前进行压力测试，根据实际表现微调参数。