Java线程池实战：ThreadPoolExecutor参数配置与动态调优方案

Java线程池用错参数比不用线程池更危险。队列无界导致OOM、核心线程数拍脑袋设置、拒绝策略选错吞任务，这些是线上事故的高发区。ThreadPoolExecutor的七个参数各有明确含义，配置思路应基于任务类型和压测数据，而不是抄网上的固定值。

线程池参数配置：任务类型决定核心数与队列策略

任务分CPU密集型和IO密集型。CPU密集型任务线程数设为核数加1，线程多了反而增加上下文切换开销；IO密集型任务大部分时间在等待，线程数可以放大到核数乘以2，或者按公式核数乘以（1加等待时间与计算时间之比）估算。

// IO密集型任务示例：8核机器
ThreadPoolExecutor executor = new ThreadPoolExecutor(
        8,                      // corePoolSize：常驻线程
        16,                     // maximumPoolSize：峰值线程
        60L, TimeUnit.SECONDS,  // 空闲线程回收时间
        new ArrayBlockingQueue<>(200),   // 有界队列，容量200
        new ThreadFactoryBuilder()
                .setNameFormat("order-pool-%d")
                .setUncaughtExceptionHandler((t, e) ->
                        log.error("线程{}异常", t.getName(), e))
                .build(),
        new ThreadPoolExecutor.CallerRunsPolicy()  // 拒绝策略
);

关键点是队列必须有界。Executors.newFixedThreadPool用的是无界LinkedBlockingQueue，请求堆积时队列无限增长直到OOM，这也是开发规约禁用Executors工厂方法的原因。有界队列满了之后，线程池才会创建超出core的线程，直到maximumPoolSize，仍然处理不过来才触发拒绝策略。

拒绝策略选型：四种策略的适用场景对比

拒绝策略直接决定过载时系统的行为，四种内置策略对应四种取舍。

AbortPolicy抛异常，适合任务不能丢、调用方需要感知失败并做补偿的场景，异常要在调用方catch住。CallerRunsPolicy让提交任务的线程自己执行，起到天然限流作用，适合削峰场景，缺点是提交线程被阻塞。DiscardPolicy静默丢弃，绝大多数业务场景都不该用，丢了任务调用方还不知道。DiscardOldestPolicy丢队头最老任务再重试提交，适合消息类场景，新消息比老消息更有价值。

线上更推荐自定义拒绝策略：先落库或发MQ，再异步补偿，任务不丢，过载时系统也只是变慢而不是出错。

动态调参实现：参数热更新与监控埋点

线程池参数不是一次配好就完事，流量变化后需要调整。ThreadPoolExecutor本身提供了运行时set方法，配合配置中心可以做到不重启调参。

// 动态调整核心与最大线程数
executor.setCorePoolSize(newCore);
executor.setMaximumPoolSize(newMax);

// 配合Nacos监听配置变更
@NacosConfigListener(dataId = "threadpool-config")
public void onChange(String config) {
    ThreadPoolConfig c = JSON.parseObject(config, ThreadPoolConfig.class);
    OrderThreadPoolHolder.executor.setCorePoolSize(c.getCoreSize());
    OrderThreadPoolHolder.executor.setMaximumPoolSize(c.getMaxSize());
    log.info("线程池已调整: core={}, max={}", c.getCoreSize(), c.getMaxSize());
}

setCorePoolSize调大时会立即预启动差额线程，调小时空闲线程在下次空闲回收时销毁。调整后再观察队列深度和任务耗时，确认新参数生效。

运行状态监控：核心指标与告警阈值

线程池必须接入监控，四个指标直接反映健康度：活跃线程数、队列积压数、已完成任务数、拒绝任务数。通过定时任务采集上报。

@Scheduled(fixedRate = 10000)
public void collectMetrics() {
    Metrics.gauge("tp.active", executor.getActiveCount());
    Metrics.gauge("tp.queue.size", executor.getQueue().size());
    Metrics.gauge("tp.pool.size", executor.getPoolSize());

    // 队列使用率超过80%告警
    int queueSize = executor.getQueue().size();
    int capacity = executor.getQueue().size() + executor.getQueue().remainingCapacity();
    if (queueSize * 1.0 / capacity > 0.8) {
        Metrics.counter("tp.queue.nearfull").increment();
    }
}

告警看队列使用率和拒绝次数，不看活跃线程数，活跃线程打满是正常状态。队列使用率持续超80%说明容量规划不足，拒绝次数从零变正说明已经过载，这两条是扩容或降级决策的触发信号。

常见事故场景与排查思路

队列堆积OOM：堆栈里看到大量任务对象在LinkedBlockingQueue，就是无界队列堆任务。换有界队列加自定义拒绝策略。

任务执行完不返回：任务里没catch住RuntimeException，异常被吞进Worker线程看起来像卡死。ThreadFactory里设置UncaughtExceptionHandler，或者任务体最外层统一catch。

线程数上不去：队列容量配太大，maximumPoolSize形同虚设。触发条件是队列先满才会创建新线程，容量2000的队列在日常流量下永远满不了。

shutdown后任务丢失：用shutdownNow会丢弃未执行任务并中断运行中的任务，优雅停机应该用shutdown加awaitTermination组合，等待存量任务跑完再退出。