上周有个哥们儿去字节跳动面后端，刚坐下没多久，面试官就甩出了一道经典的场景题：“线上服务接口频繁超时报错堆得像山一样，你查了日志发现是因为线程池队列满了导致任务被拒绝。这时候，你会怎么优化？”

这哥们儿当时心里可Neng有点慌，想了大概两分钟，回答说：“那是不是把核心线程数调大一点，队列容量也改大一点，这样不就Neng装geng多请求，处理得geng快了吗？”

面试官听完，嘴角微微上扬，笑了一下：“你管这叫高并发优化？” 然后就没有然后了。这场景其实挺扎心的，hen多候选人并不是不懂线程池，而是太急于给出一个“万Neng药方”，反而掉进了陷阱里。

说实话，这真不Neng全怪他。咱们平时写代码，对线程池的理解往往停留在“创建它”的时候填那几个参数：核心线程数、Zui大线程数、存活时间、队列类型。只要这几个填上了任务Neng跑，就觉得万事大吉。真到了线上出问题，全靠感觉瞎调参数，蒙对了就沾沾自喜，蒙错了可Neng就是一场生产事故。

geng有意思的是我见过不少公司的线程池配置，从项目上线那天起就仿佛被“封印”了默认参数用到底。不出问题则Yi，一出问题就慌慌张张改一改，结果往往是按下葫芦浮起瓢，旧问题没解决，新问题又来了。

面试官其实并不在乎你Neng不Neng背出那几个参数的含义，他真正想考察的是：当线上真的炸了你有没有一套清晰的诊断逻辑。你把这套思路讲出来比背十个公式dou有用。

所以碰到接口超时全是线程池拒绝的情况，第一步绝对不是去改配置文件，而是要冷静下来问自己：到底是请求真的太多了还是线程卡在那里动不了？

这完全是两种情况，解法天差地别。Ru果是某个慢查询把线程dou给“借走”了导致线程dou在阻塞状态，你就算开一百个线程，hen快也会被占满，问题根本没解决，反而浪费了资源。这时候，正确的Zuo法是去优化那个慢接口，而不是扩容线程池。

这里有个简单的判断技巧，大家平时Ke以记一下：去观察一下线程的平均等待时间和实际执行时间。Ru果等待时间hen长，但执行时间hen短，那就说明是线程数不够，请求排不上队。但Ru果执行时间本身就hen长，那问题肯定出在任务本身，别赖线程池。

在动线程池参数之前，请先Zuo一件事：缩小任务本身的执行时间。这是性价比Zui高的优化手段，没有之一。

你想想，Ru果每个任务dou要跑半天你开再多线程也没用。把那些慢SQL优化一下加上索引；把不必要的串行调用改成并行；该上缓存的地方加上缓存。这些操作往往Neng解决80%以上的性Neng问题。任务跑得快了自然就不需要那么多线程在那傻傻地排队了。

举个例子，假设你的接口处理一次请求需要100ms，8核机器开了8个线程，理论上每秒Neng处理80个请求。Ru果每秒来了100个请求，那自然排不过来。但Ru果每个请求dou要等1秒去查数据库，那你开多少线程dou会瞬间占满。这时候，优先优化SQL比加线程有用多了。

任务本身优化得差不多了接下来才是调整线程数。这里有个误区，hen多人以为核心线程数设成CPU核数乘以2就行。其实这个公式只适用于CPU密集型任务。

Ru果你的任务大部分时间dou在等IO——比如等数据库响应、等第三方接口回调——那线程数完全Ke以设得大hen多。因为hen多线程dou在“摸鱼”等待，CPU其实是空的，不多开点线程岂不是浪费资源？

这里有个通用的计算公式，大家Ke以参考一下：

线程数 = CPU核数 ×

我之前Zuo过一个推送服务，大部分时间dou在等第三方网关回调。按照这个逻辑，我把线程数开到了CPU核数的几十倍，结果吞吐量反而geng高了。因为闲着也是闲着，多开线程就Neng多处理并发请求。

当然这里也要踩个坑：线程池调优绝不是越大越好。队列加太大，请求堆积多了反而会让平均响应时间变长，用户那边还是超时。线程开太多，CPU切换不过来上下文切换的开销就Neng把性Neng吃光。所以CPU密集型的任务，线程数接近CPU核数就够了；IO密集型的，等待时间越长，需要的线程才越多。

线程数定好了接下来就是队列。这地方也是个雷区。

你敢用无界的LinkedBlockingQueue试试？请求一来瞬间堆积几万条，内存直接溢出，服务直接挂掉。所以生产环境一定要用有界队列。

那用SynchronousQueue好不好？这个队列比较特殊，它不存任务，来了任务直接提交给线程，线程不够就拒绝。这适合请求量大但处理极快的场景，Neng减少排队延迟。Ru果你希望请求尽量douNeng处理，Neng接受一点延迟，那就老老实实用有界的LinkedBlockingQueue。

这里还要强调一点：队列不Neng太长。队列太长，请求排队时间久了用户那边早就超时了你堆积那么多请求干嘛？还不如早点拒绝，让用户重试或者降级处理，体验反而geng好。

队列满了线程忙不过来这时候拒绝策略就非常关键了。

hen多人默认用的是AbortPolicy，队列满了直接抛异常，用户直接kan到500报错，体验极差。其实geng合理的是用CallerRunsPolicy，这个策略hen有意思，它让提交任务的线程自己去执行这个任务。

这招叫“背压”，Neng有效地把请求速率降下来。既然主线程dou在忙着执行任务了它提交新任务的速度自然就慢了不至于把所有用户dou直接拒之门外。

当然你也Ke以自己动手实现拒绝策略。比如把请求放到Redis队列里慢慢削峰填谷，或者直接返回“系统繁忙，请稍后重试”给用户，这比直接抛一个冷冰冰的异常要强得多。

还有一点特别容易被忽略：不同类型的任务一定要分开线程池。

我见过太多系统，把推送任务、Excel导出任务、普通的接口请求全部塞到同一个线程池里。这简直是灾难。一旦某个导出任务把线程dou占满了其他正常的请求也别想处理了全被连累挂掉。

拆分之后就算一个非核心业务的池子炸了也不影响核心业务。这就是所谓的“资源隔离”，在微服务架构里尤为重要。

其实hen多问题，只要监控一kan就明白。你调完参数，不Neng拍拍屁股走人，得观察一天kankan拒绝次数还多不多，接口超时率降了没有，数据一目了然。

调优不是一锤子买卖。线程池有几个关键指标必须死死盯着：活跃线程数、队列大小、拒绝任务数、任务执行耗时。Ru果发现等待时间越来越长，说明系统压力在增大；Ru果发现CPU利用率飙高但吞吐量上不去，可Neng就是上下文切换太严重了。

回到Zui开始那个面试题，Ru果你Neng按照这个思路回答：

“别上来就说加大线程加大队列，先问清楚：任务是CPU密集还是IO密集？现在每个任务平均执行时间多少？是不是有慢接口拖后腿？然后再一步步来先优化任务本身，再调整参数，再拆分隔离，Zui后上监控。”

这么说面试官基本就满意了。毕竟线程池解决的是排队问题，不是慢问题。先治病还是先止痛，得分清楚。搞清楚问题之后再动手优化，才不会在面试官面前露怯。