面经策

让你设计一个线程池，怎么设计？ ​

  • 标签：后端、系统设计、场景题

🏛 业务架构师 ​

设计线程池这题，我会从参数权衡、业务隔离、失败语义、可运营性四个层面回答——前两个是设计，后两个是架构师真正拉开差距的地方。

核心参数的权衡逻辑

java
new ThreadPoolExecutor(
    corePoolSize,      // 常驻: 按Little's law估算 QPS × 平均耗时
    maxPoolSize,       // 峰值缓冲, 不是越大越好
    keepAliveTime,
    new ArrayBlockingQueue<>(200),  // 必须有界!
    new ThreadFactory("biz-order"), // 命名, 排查必备
    new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略=业务决策
);
  • 线程数：CPU 密集 = 核数 + 1；IO 密集 = 核数 × (1 + 平均等待/计算时间)，别背 2 倍公式，用压测数据说话
  • 队列必须有界：无界队列（默认 LinkedBlockingQueue）会掩盖饱和信号，任务无限堆积直到 OOM——我review 到无界队列一律打回
  • 拒绝策略是业务语义：交易类用 CallerRunsPolicy 反压（慢但不丢）；通知类用 DiscardPolicy（丢一条无所谓）；核心任务落 MQ 延后补偿——没有普适策略，只有按业务分

业务隔离（舱壁模式） 不同业务绝不共享线程池：订单、营销、评价各自独立。否则营销活动把线程占满，下单跟着陪葬——故障爆炸域隔离是花小钱防大事故。

可运营性

  • 暴露指标：活跃线程、队列深度、拒绝次数、任务耗时，队列深度 80% 告警
  • 参数进配置中心动态调参（Nacos + setCorePoolSize），流量变化不用重启
  • 命名线程工厂 + MDC 传递 traceId，否则出了问题 jstack 一片 pool-1-thread-N 根本没法查

收尾：线程池设计的本质不是算参数，是给每类业务定义清楚"满了之后怎么办"。

🏗 系统架构师 ​

我不会从"背七大参数"开始，而是先讲设计约束：任务类型（CPU 密集 / IO 密集）、调用方能否等待、任务丢弃时业务能否接受，这三问决定一切参数。

核心结构设计：

  • 线程管理：corePoolSize 按任务类型定——CPU 密集取 N+1，IO 密集用 N * (1 + 等待/计算比)，或者直接用Little定律：线程数 = 目标QPS × 平均耗时。2026 年跑在 JDK21+ 上的 IO 密集服务，我的首选其实是虚拟线程（Executors.newVirtualThreadPerTaskExecutor()），池化价值大幅下降，只保留信号量限并发
  • 队列：我用 ArrayBlockingQueue 有界队列，容量 = 削峰目标；绝不的无界队列——那是 OOM 的定时炸弹
  • 拒绝策略：这是设计重点。CallerRunsPolicy 天然反压让提交方减速，适合可延迟任务；核心链路用自定义策略：落 MQ 削峰 + 打监控 + 报警
  • 线程命名 + UncaughtExceptionHandler：出问题能定位，异常不静默吞掉

可运维性设计（拉开差距的部分）：参数全部走配置中心支持动态调参（参考美团的 DynamicTp 思路，setCorePoolSize 运行时生效）；暴露活跃线程数、队列水位、任务耗时、拒绝数等指标；提供优雅关闭——shutdown() 后 awaitTermination 超时再 shutdownNow，且关闭前拒绝新任务。

最后给动态反馈：队列水位持续 > 80% 说明容量不足，自动扩容或告警，而不是等故障才发现。

💻 全栈开发专家 ​

设计线程池我从五个问题出发：任务什么类型？队列多大？满了怎么办？怎么观测？怎么调参？

核心参数设计

java
ThreadPoolExecutor pool = new ThreadPoolExecutor(
    10, 20, 60, TimeUnit.SECONDS,       // 核心/最大/回收时间
    new ArrayBlockingQueue<>(500),       // 有界队列，防 OOM
    new ThreadFactoryBuilder().setNameFormat("biz-pool-%d").build(), // 命名，排查必备
    new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略：让提交线程执行，起到反压作用
);
  • 线程数：CPU 密集 = 核数 + 1；IO 密集 = 核数 × (1 + 平均等待时间/计算时间)，压测校准为准。
  • 队列必须有界：Executors.newFixedThreadPool 的无界 LinkedBlockingQueue 会把内存堆爆，我们公司直接禁用 Executors 工厂方法。
  • 拒绝策略按业务选：丢不得的用 CallerRunsPolicy 或 MQ 缓冲；可丢的记日志 + 打点。

监控与动态调参（生产必备）

  • 暴露指标：活跃线程数、队列水位、已完成任务数、拒绝次数，接入 Prometheus 告警（队列水位 > 80% 告警）。
  • 线程池参数不该写死：核心参数运行时可改（setCorePoolSize/setMaximumPoolSize），监听 Nacos 配置变更动态生效，或直接接 Hippo4j 这类动态线程池框架。

隔离 核心业务与边缘业务分池（甚至按入口分舱），一个慢接口拖垮线程池连累全局的事故我见过不止一次。