摘要：作为互联网软件开发人员，你是不是也遇到过这样的糟心事儿：大促前熬夜做了好几轮压测，以为系统能扛住峰值流量，结果上线后 QPS 刚涨到 10 万，服务直接报 “线程池拒绝任务”，监控面板上 CPU 飙到 100%，日志里满是 “Task rejected fro
作为互联网软件开发人员，你是不是也遇到过这样的糟心事儿：大促前熬夜做了好几轮压测，以为系统能扛住峰值流量，结果上线后 QPS 刚涨到 10 万，服务直接报 “线程池拒绝任务”，监控面板上 CPU 飙到 100%，日志里满是 “Task rejected from ThreadPoolexecutor”—— 明明配置了 200 个线程，怎么就扛不住了？
我上周帮同行业的朋友排查问题时，就碰到了一模一样的情况。他们做的是电商订单系统，大促期间预估 QPS12 万，提前把线程池核心线程数设为 200、最大线程数 300，结果压测时 QPS 刚到 10 万就崩了。后来查了半天才发现，不是硬件不够强，也不是代码有 bug，而是线程池配置踩了 3 个新手常犯的坑。今天就跟大家好好聊聊这个事儿，帮你避开这些坑，让系统在高并发下稳如老狗。
咱们先说说背景 —— 为啥线程池配置不当，会直接导致系统扛不住高并发？
首先得明确，线程池的核心作用是 “管理线程资源”，避免频繁创建销毁线程带来的性能损耗。但如果配置不合理，反而会变成 “性能瓶颈”。就像我朋友的案例里，他们犯的第一个错就是 “凭感觉设线程数”：觉得 200 个线程够多了，却没算过 “任务耗时” 和 “CPU 核心数” 的匹配关系。
这里给大家提个醒：线程池的核心线程数不是越多越好。比如你的服务器是 8 核 CPU，要是线程数设成 200，会导致大量线程在 CPU 里 “上下文切换”——CPU 刚处理完线程 A 的指令，又要切换到线程 B，来回切换的时间比实际处理任务的时间还长，结果就是 CPU 利用率拉满，但实际处理的任务量没上去，QPS 自然扛不住。
再加上他们用的是 “固定线程池（FixedThreadPool）”，核心线程数和最大线程数一样，还没设置 “动态扩容” 机制。大促时流量是突发的，前一秒 QPS5 万，下一秒突然涨到 10 万，固定线程池没法临时加线程，任务全堆在队列里，队列满了就拒绝任务，系统可不就崩了嘛。
知道了问题在哪，接下来就是实打实的解决方案。结合我朋友的优化案例，以及行业内常用的高并发线程池配置思路，给大家总结 3 个关键步骤，每个步骤都附代码示例，你直接抄作业都能用。
别再凭感觉设线程数了，这里有个通用计算公式，针对 CPU 密集型任务和 IO 密集型任务，咱们分开算：
CPU 密集型任务（如计算、排序）：线程数 = CPU 核心数 + 1。比如 8 核 CPU，线程数设为 9，这样能最大限度利用 CPU，又不会导致过多上下文切换。IO 密集型任务（如数据库查询、接口调用）：线程数 = CPU 核心数 × 2。因为这类任务里，线程大部分时间在等 IO 响应（比如等数据库返回数据），多设线程能提高 CPU 利用率。我朋友的订单系统属于 “IO 密集型”（要调用支付接口、库存接口），服务器是 16 核 CPU，按公式算线程数应该是 16×2=32。他们之前设 200，明显多了。后来改成核心线程数 32、最大线程数 64，第一步就把 CPU 利用率从 100% 降到了 75%。
很多开发兄弟习惯用 Executors.newFixedThreadPool ，但高并发场景下，更推荐用ThreadPoolExecutor 自定义配置，还能加 “动态调整” 机制。给大家上一段实战代码，你可以直接改改参数用：
// 1. 定义线程池参数（可放在配置文件里，支持动态修改）private int corePoolSize = 32; // 核心线程数（按公式计算）private int maximumPoolSize = 64; // 最大线程数（核心线程数的2倍）private long keepAliveTime = 5; // 空闲线程存活时间（5秒）private TimeUnit unit = TimeUnit.SECONDS;// 2. 用LinkedBlockingQueue做任务队列，设置合理容量（避免队列过大导致内存溢出）private BlockingQueueworkQueue = new LinkedBlockingQueue(1000);// 3. 自定义拒绝策略：任务满了别直接拒绝，先重试1次，还不行再记录日志（避免丢失任务）private RejectedExecutionHandler handler = (runnable, executor) -> { try { // 重试1次，等待1秒 executor.getQueue.offer(runnable, 1, TimeUnit.SECONDS); } catch (InterruptedException e) { // 重试失败，记录日志（后续可做任务补偿） log.error("线程池任务拒绝，任务信息：{}", runnable.toString, e); }};// 4. 创建自定义线程池public ThreadPoolExecutor orderThreadPool { return new ThreadPoolExecutor( corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, Executors.defaultThreadFactory, handler );}这里有 2 个关键点要注意：一是任务队列容量别设太大（比如别用 Integer.MAX_VALUE），否则任务堆积太多会导致内存溢出；二是拒绝策略别用默认的 AbortPolicy（直接抛异常），像上面那样加个重试机制，能减少任务丢失的风险。
大促期间流量是波动的，比如凌晨 QPS 只有 1 万，中午涨到 8 万，晚上峰值 12 万。如果线程池参数固定不变，要么闲时浪费资源，要么忙时扛不住。所以建议加个 “动态调整” 功能，通过配置中心（如 Nacos、Apollo）实时修改线程数。
给大家补一段动态调整的代码逻辑，基于 Spring Boot 的配置监听实现：
// 1. 注入配置中心的监听服务（以Nacos为例）@Autowiredprivate NacosConfigManager nacosConfigManager;// 2. 监听线程池参数变化@PostConstructpublic void listenThreadPoolConfig { try { // 监听配置文件中threadPool开头的参数 nacosConfigManager.getConfigService.addListener( "thread-pool-config.properties", // 配置文件名 "DEFAULT_GROUP", // 配置分组 new Listener { @Override public Executor getExecutor { return null; } @Override public void receiveConfigInfo(String configInfo) { // 解析配置文件，获取新的线程数参数 Properties properties = new Properties; try { properties.load(new StringReader(configInfo)); int newCoreSize = Integer.parseInt(properties.getProperty("threadPool.coreSize")); int newMaxSize = Integer.parseInt(properties.getProperty("threadPool.maxSize")); // 动态调整线程池参数 ThreadPoolExecutor executor = orderThreadPool; executor.setCorePoolSize(newCoreSize); executor.setMaximumPoolSize(newMaxSize); log.info("线程池参数已动态调整：核心线程数{}→{}，最大线程数{}→{}", corePoolSize, newCoreSize, maximumPoolSize, newMaxSize); } catch (IOException e) { log.error("解析线程池配置失败", e); } } } ); } catch (NacosException e) { log.error("注册线程池配置监听失败", e); }}这样一来，大促期间如果发现 QPS 快到阈值了，运维同事不用重启服务，直接在配置中心改一下核心线程数和最大线程数，线程池就能实时响应，比固定配置灵活多了。
讲完具体的解决方案，再给大家总结 3 个核心要点，下次配置线程池时照着做，能帮你避开 80% 的坑：
别凭感觉设线程数：先判断任务是 CPU 密集还是 IO 密集，再用公式计算（CPU 密集 = 核心数 + 1，IO 密集 = 核心数 ×2），避免线程过多导致上下文切换频繁；拒绝 “一刀切” 的线程池：别再用 Executors 的默认实现，自定义 ThreadPoolExecutor，合理设置队列容量和拒绝策略，尤其是拒绝策略要避免直接抛异常；一定要加动态调整：高并发场景下流量波动大，通过配置中心实现线程池参数动态修改，不用重启服务就能应对流量变化。其实线程池优化不算复杂，关键是要结合实际场景，别生搬硬套别人的配置。我朋友的系统优化后，大促期间 QPS 峰值到了 13 万，服务响应时间从之前的 500ms 降到了 80ms，零报错零卡顿。
最后也想问问大家：你在项目里有没有遇到过线程池导致的问题？是怎么解决的？或者你有哪些高并发线程池的优化技巧？欢迎在评论区分享你的经验，咱们一起交流学习，把系统性能做得更稳更好！
来源：从程序员到架构师