Java线程池调优与拒绝策略实战配置

Java线程池是高并发系统的核心基础设施。线程池参数配置不当，轻则任务排队延迟飙升，重则OOM导致服务不可用。生产环境中，不同业务场景对线程池的需求差异巨大：CPU密集型任务需要少线程多队列，I/O密集型任务需要多线程短队列，混合型任务需要动态调整。本文从参数含义、场景选型、拒绝策略到监控调优，系统讲解Java线程池的实战配置方法。

ThreadPoolExecutor核心参数解析

ThreadPoolExecutor有7个核心参数，理解每个参数的含义和相互作用是调优的基础：

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    2,                      // corePoolSize
    10,                     // maximumPoolSize
    60L, TimeUnit.SECONDS,  // keepAliveTime
    new LinkedBlockingQueue<>(100),
    new NamedThreadFactory("biz-pool"),
    new ThreadPoolExecutor.CallerRunsPolicy()
);

任务提交到线程池的执行顺序：核心线程优先 → 队列排队 → 非核心线程扩容 → 拒绝策略。这个顺序经常被误解。一个常见的错误配置是corePoolSize设为0，所有任务先入队列再由最大线程数处理，实际上这会导致队列未满时不会创建新线程，与预期完全相反。

不同业务场景的线程池参数组合

线程池参数没有万能公式，需要根据业务类型和SLA要求组合配置：

CPU密集型任务（计算、加密、压缩）：corePoolSize = CPU核数 + 1，maximumPoolSize = CPU核数 + 1，队列用LinkedBlockingQueue（无界或大容量），拒绝策略用CallerRunsPolicy。+1的线程用于在某个线程偶尔因为缺页中断等原因暂停时，保持CPU不空闲。

I/O密集型任务（HTTP调用、数据库查询、文件读写）：corePoolSize = CPU核数 × 2，maximumPoolSize = CPU核数 × 4，队列用SynchronousQueue或小容量LinkedBlockingQueue，拒绝策略根据业务选择。I/O等待期间线程不占用CPU，所以线程数可以远大于CPU核数。

// I/O密集型线程池
ThreadPoolExecutor ioPool = new ThreadPoolExecutor(
    Runtime.getRuntime().availableProcessors() * 2,
    Runtime.getRuntime().availableProcessors() * 4,
    30L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(200),
    new NamedThreadFactory("http-call"),
    new ThreadPoolExecutor.CallerRunsPolicy()
);
ioPool.allowCoreThreadTimeOut(true);

// CPU密集型线程池
ThreadPoolExecutor cpuPool = new ThreadPoolExecutor(
    Runtime.getRuntime().availableProcessors() + 1,
    Runtime.getRuntime().availableProcessors() + 1,
    0L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(500),
    new NamedThreadFactory("crypto"),
    new ThreadPoolExecutor.AbortPolicy()
);

allowCoreThreadTimeOut(true)让核心线程在空闲超过keepAliveTime后自动回收，适合流量有明显波峰波谷的I/O场景。CPU密集型场景通常不开启此选项，避免频繁创建销毁线程的开销。

四种拒绝策略的适用场景分析

当线程池的线程数达到maximumPoolSize且队列已满时，新提交的任务触发拒绝策略。JDK提供四种内置策略：

AbortPolicy（默认）：直接抛出RejectedExecutionException。适合不允许丢弃任务的场景，由调用方捕获异常自行处理。大多数业务场景的首选。

CallerRunsPolicy：由提交任务的线程自己执行。这会降低提交速度，形成自然背压。适合允许降速但不允许丢弃的场景，如消息消费线程池。

DiscardPolicy：静默丢弃任务，不抛异常。适合可丢弃的非关键任务，如日志采集、监控上报。

DiscardOldestPolicy：丢弃队列头部（最早提交）的任务，然后重新提交当前任务。适合实时性要求高、只关心最新数据的场景，如实时指标聚合。

生产环境通常需要自定义拒绝策略，结合降级和告警：

public class AlertRejectPolicy implements RejectedExecutionHandler {
    private final RejectedExecutionHandler fallback;
    private final AtomicInteger rejectCount = new AtomicInteger();

    public AlertRejectPolicy(RejectedExecutionHandler fallback) {
        this.fallback = fallback;
    }

    @Override
    public void rejectedExecution(Runnable r,
                                  ThreadPoolExecutor executor) {
        int count = rejectCount.incrementAndGet();
        if (count % 10 == 0) {
            Metrics.counter("threadpool.rejected",
                "pool", executor.getThreadFactory().toString(),
                "count", String.valueOf(count))
                .inc();
        }
        fallback.rejectedExecution(r, executor);
    }
}

动态线程池配置与运行时调优

生产环境中线程池参数需要根据流量变化动态调整。Spring Boot场景下结合Nacos或Apollo配置中心实现参数热更新：

@Configuration
public class DynamicThreadPoolConfig {

    @Bean
    @RefreshScope
    public ThreadPoolExecutor bizThreadPool(
            @Value("${threadpool.core-size:4}") int coreSize,
            @Value("${threadpool.max-size:16}") int maxSize,
            @Value("${threadpool.queue-capacity:200}") int queueCapacity) {

        ThreadPoolExecutor pool = new ThreadPoolExecutor(
            coreSize, maxSize, 60L, TimeUnit.SECONDS,
            new ResizableLinkedBlockingQueue<>(queueCapacity),
            new NamedThreadFactory("dynamic-biz"),
            new AlertRejectPolicy(
                new ThreadPoolExecutor.CallerRunsPolicy())
        );
        pool.allowCoreThreadTimeOut(true);
        return pool;
    }
}

线程池监控指标与告警配置

线程池的运行状态需要实时监控。关键指标包括活跃线程数、队列大小、已完成任务数和拒绝次数：

@Scheduled(fixedRate = 5000)
public void monitorThreadPool() {
    ThreadPoolExecutor pool = getBizPool();
    double queueUsage = (double) pool.getQueue().size()
        / (pool.getQueue().remainingCapacity()
           + pool.getQueue().size());
    if (queueUsage > 0.8) {
        log.warn("线程池队列使用率: {}", queueUsage);
    }
}

Java线程池调优是在资源利用和系统稳定性之间的持续权衡。根据业务类型选择核心参数组合，匹配恰当的拒绝策略，通过配置中心实现动态调整，配合监控指标及时发现问题，这四个环节形成闭环，才能构建出高可靠、可调优的线程池体系。