上个月服务上线后，用户反馈接口很慢，平均响应时间2秒多。
排查了一圈，发现是线程池配置不当导致的。
调优之后，响应时间降到200ms，记录一下完整过程。
问题现象
用户反馈下单接口很慢，看了下监控：
- 平均响应时间：2.3秒
- P99响应时间：5秒+
- 偶尔还会超时
但CPU、内存、数据库都正常，没有明显瓶颈。
排查过程
第一步：看线程池状态
用Arthas看了下线程池：
# 进入Arthasjava -jar arthas-boot.jar# 查看线程池状态thread -n3发现大量线程处于WAITING状态，在等待任务。
再看线程池的具体参数：
// 项目中的配置ThreadPoolExecutorexecutor=newThreadPoolExecutor(10,// corePoolSize10,// maximumPoolSize60L,// keepAliveTimeTimeUnit.SECONDS,newLinkedBlockingQueue<>(10000)// 队列容量);问题找到了：核心线程数只有10，但队列容量是10000。
第二步：分析问题
这个配置的问题：
- 核心线程数太小：只有10个线程处理任务
- 队列太大：新任务会先进队列，而不是创建新线程
- 最大线程数等于核心线程数：队列满了才会创建新线程，但队列有10000容量，几乎不会满
结果：高并发时，任务在队列里排队等待，响应时间自然就慢了。
线程池工作原理
先复习一下线程池的工作流程：
新任务到来 ↓ 当前线程数 < corePoolSize？ ↓ 是 创建新线程执行 ↓ 否 队列未满？ ↓ 是 放入队列等待 ↓ 否 当前线程数 < maximumPoolSize？ ↓ 是 创建新线程执行 ↓ 否 执行拒绝策略关键点：任务会优先进队列，而不是创建新线程！
这就是为什么队列太大会导致响应慢——任务都在排队。
优化方案
方案1：调整参数
// 优化后的配置intcpuCores=Runtime.getRuntime().availableProcessors();ThreadPoolExecutorexecutor=newThreadPoolExecutor(cpuCores*2,// corePoolSize：CPU核心数的2倍cpuCores*4,// maximumPoolSize：CPU核心数的4倍60L,TimeUnit.SECONDS,newLinkedBlockingQueue<>(100),// 队列容量减小newThreadPoolExecutor.CallerRunsPolicy()// 拒绝策略);参数计算公式：
- CPU密集型：
corePoolSize = CPU核心数 + 1 - IO密集型：
corePoolSize = CPU核心数 * 2（或更高）
我们的业务是IO密集型（有数据库查询、RPC调用），所以用CPU核心数 * 2。
方案2：使用SynchronousQueue
如果想让任务尽快被执行，可以用SynchronousQueue：
ThreadPoolExecutorexecutor=newThreadPoolExecutor(10,100,// 最大线程数调大60L,TimeUnit.SECONDS,newSynchronousQueue<>(),// 不缓存任务newThreadPoolExecutor.CallerRunsPolicy());SynchronousQueue不存储任务，新任务来了直接创建线程执行。
方案3：动态线程池（推荐）
更好的方案是动态调整线程池参数：
@ComponentpublicclassDynamicThreadPool{privateThreadPoolExecutorexecutor;@PostConstructpublicvoidinit(){executor=newThreadPoolExecutor(20,50,60L,TimeUnit.SECONDS,newLinkedBlockingQueue<>(200),newThreadPoolExecutor.CallerRunsPolicy());}// 动态调整核心线程数publicvoidsetCorePoolSize(intsize){executor.setCorePoolSize(size);}// 动态调整最大线程数publicvoidsetMaxPoolSize(intsize){executor.setMaximumPoolSize(size);}// 获取线程池状态publicMap<String,Object>getStatus(){Map<String,Object>status=newHashMap<>();status.put("corePoolSize",executor.getCorePoolSize());status.put("maximumPoolSize",executor.getMaximumPoolSize());status.put("activeCount",executor.getActiveCount());status.put("queueSize",executor.getQueue().size());status.put("completedTaskCount",executor.getCompletedTaskCount());returnstatus;}}配合配置中心（Nacos/Apollo），可以在线调整参数，不用重启服务。
优化后效果
调整参数后，对比数据：
| 指标 | 优化前 | 优化后 |
|---|---|---|
| 核心线程数 | 10 | 32 |
| 最大线程数 | 10 | 64 |
| 队列容量 | 10000 | 200 |
| 平均响应时间 | 2.3秒 | 180ms |
| P99响应时间 | 5秒+ | 500ms |
效果：响应时间降低了10倍以上。
监控告警
优化完不能不管了，要加监控：
@Scheduled(fixedRate=60000)publicvoidmonitorThreadPool(){intactiveCount=executor.getActiveCount();intqueueSize=executor.getQueue().size();intpoolSize=executor.getPoolSize();// 记录到监控系统log.info("ThreadPool status: active={}, queue={}, pool={}",activeCount,queueSize,poolSize);// 队列积压告警if(queueSize>100){alertService.send("线程池队列积压: "+queueSize);}// 线程数告警if(activeCount>=executor.getMaximumPoolSize()*0.8){alertService.send("线程池接近饱和: "+activeCount);}}常见错误配置
错误1：队列无界
newLinkedBlockingQueue<>()// 默认是Integer.MAX_VALUE问题：任务无限堆积，最终OOM。
错误2：核心线程数太小
corePoolSize=5// 8核CPU只配5个核心线程问题：CPU利用率低，任务排队等待。
错误3：拒绝策略选错
newThreadPoolExecutor.AbortPolicy()// 直接抛异常问题：高并发时大量任务被拒绝，用户看到报错。
建议：用CallerRunsPolicy，让调用线程自己执行，起到限流作用。
线程池配置建议
| 场景 | corePoolSize | maximumPoolSize | 队列 |
|---|---|---|---|
| CPU密集型 | N+1 | N+1 | 小队列（100以内） |
| IO密集型 | 2N | 4N | 中等队列（200-500） |
| 混合型 | N*1.5 | 2N | 根据实际调整 |
（N = CPU核心数）
远程排查技巧
如果线上服务出问题，需要远程查看线程池状态，可以：
- Arthas：
thread命令看线程状态 - JMX：通过JMX远程连接查看
- 自定义接口：暴露线程池状态接口
如果服务器在内网，可以用星空组网工具把本地和服务器连起来，直接用IDE的Remote Debug功能，比看日志效率高很多。
总结
| 优化点 | 说明 |
|---|---|
| 增大核心线程数 | IO密集型用 CPU核心数*2 |
| 减小队列容量 | 避免任务积压 |
| 合理设置最大线程数 | 给突发流量留余地 |
| 选对拒绝策略 | CallerRunsPolicy比较稳 |
| 加监控告警 | 及时发现问题 |
核心原则：让任务尽快被线程执行，而不是在队列里排队。
线程池配置踩过其他坑的，欢迎评论区交流~
