JVM 线程池调优：别只把 corePoolSize 调大
一、线程池问题经常被误判成机器不够
线上接口变慢时，很多团队第一反应是加机器或调大线程池。但线程池不是越大越好。线程数过多会增加上下文切换、内存占用和下游压力；队列过长会隐藏延迟，让请求在应用内排队到超时；拒绝策略不清晰会让失败表现随机。线程池调优的目标不是“吞下更多请求”，而是让系统在容量边界内稳定运行。
Java 服务中的线程池通常承载异步任务、RPC 调用、批处理、消息消费和定时任务。不同场景的瓶颈不同，CPU 密集型任务关注核心数，IO 密集型任务关注等待时间，下游受限任务关注并发控制。用同一套参数管理所有线程池，往往会把问题放大。
二、运行模型：线程、队列和拒绝策略一起决定行为
flowchart TD A[任务提交] --> B{核心线程是否空闲} B -->|是| C[核心线程执行] B -->|否| D{队列是否可放入} D -->|是| E[进入等待队列] D -->|否| F{是否可创建非核心线程} F -->|是| G[新线程执行] F -->|否| H[拒绝策略]理解这个模型很重要。corePoolSize、maximumPoolSize和队列容量不是独立参数。使用无界队列时，maximumPoolSize基本不会发挥作用；队列太大时，任务会长时间等待，用户看到的是接口慢而不是系统忙；队列太小时，流量抖动又可能频繁触发拒绝。
生产环境更推荐有界队列和明确拒绝策略。拒绝不是失败，它是系统保护机制。对于在线请求，可以快速失败并返回可理解错误；对于可延迟任务，可以转入消息队列；对于内部低优先级任务，可以丢弃或合并。没有拒绝策略，线程池会把压力传导到 JVM、数据库和下游服务。
三、参数配置：让线程池暴露真实状态
下面是一个较为保守的线程池配置示例。重点是有界队列、命名线程和自定义拒绝处理。
@Bean public ThreadPoolTaskExecutor reportExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(16); executor.setQueueCapacity(500); executor.setThreadNamePrefix("report-worker-"); executor.setRejectedExecutionHandler((task, pool) -> { throw new RejectedExecutionException("report executor is overloaded"); }); executor.initialize(); return executor; }线程池必须接入监控。至少要采集活跃线程数、队列长度、已完成任务数、拒绝次数、任务等待时间和执行时间。只看 CPU 和内存，无法判断线程池是否已经排队严重。很多慢接口的根因，是任务在队列里等了几秒，而真正执行只用了几十毫秒。
如果使用多个业务线程池，命名要清楚。线程 dump 中看到pool-1-thread-7基本没有排障价值；看到payment-callback-12或report-worker-3，才能快速定位任务来源。
四、调优方法：用压测确认边界，而不是凭经验改数
线程池参数应通过压测验证。先在接近生产配置的环境中逐步增加并发，观察吞吐、延迟、队列长度、拒绝次数和下游指标。当吞吐不再增长但延迟快速上升时，说明系统达到容量边界。此时继续加线程只会增加排队和资源争用。
还要区分应用瓶颈和下游瓶颈。如果线程大部分时间阻塞在数据库连接池、HTTP 客户端或 Redis 调用上，扩大业务线程池可能让下游更快崩溃。此时应该控制并发、优化 SQL、增加缓存或拆分任务，而不是继续调maximumPoolSize。
线上变更要灰度。线程池参数可以配置化，但不要在高峰期大幅调整。建议先选一个实例或小流量分组验证，观察拒绝率和延迟变化，再逐步扩展。线程池调优本质上是容量治理，需要证据而不是直觉。
不同业务场景的线程池应分开配置和监控。支付回调、订单创建、报表生成、消息推送的任务特征不同，混用同一个线程池会导致相互干扰。建议在监控平台上为关键线程池建立独立仪表盘，设置队列长度、拒绝次数和任务延迟的告警阈值，让容量问题在影响用户前就被发现。
五、总结
JVM 线程池调优要把线程数、队列、拒绝策略、监控和下游容量放在一起看。调大corePoolSize只能解决很少一部分问题，更多时候需要有界队列、清晰降级和压测验证。线程池暴露真实压力，系统才有机会稳定运行。
