企业官网建设流程全解析

上个月服务上线后，用户反馈接口很慢，平均响应时间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。

第二步：分析问题

这个配置的问题：

1. 核心线程数太小：只有10个线程处理任务
2. 队列太大：新任务会先进队列，而不是创建新线程
3. 最大线程数等于核心线程数：队列满了才会创建新线程，但队列有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倍以上。

监控告警

优化完不能不管了，要加监控：

@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，让调用线程自己执行，起到限流作用。

线程池配置建议

（N = CPU核心数）

远程排查技巧

如果线上服务出问题，需要远程查看线程池状态，可以：

1. Arthas：thread命令看线程状态
2. JMX：通过JMX远程连接查看
3. 自定义接口：暴露线程池状态接口

如果服务器在内网，可以用星空组网工具把本地和服务器连起来，直接用IDE的Remote Debug功能，比看日志效率高很多。

总结

核心原则：让任务尽快被线程执行，而不是在队列里排队。

线程池配置踩过其他坑的，欢迎评论区交流~