面经策

1000 个任务，每个任务 0.1s，最大响应时间 1s，线程池参数怎么设置？ ​

  • 标签：后端、Java、场景题

🏛 业务架构师 ​

这是一道算术清晰的容量题：1000 个任务 × 0.1s = 100s 总工作量，要在 1s 内完成，需要 100 路并行。但我会先反问一个决定性问题：**任务是 CPU 密集还是 IO 密集？**这决定方案本质不同。

情况一：IO 密集（多数场景：远程调用、查库）

线程大部分时间在等待，100 线程不占 100 核：

java
ThreadPoolExecutor pool = new ThreadPoolExecutor(
    100, 100, 60, TimeUnit.SECONDS,
    new SynchronousQueue<>(),          // 不排队, 来了直接执行
    new NamedThreadFactory("batch-io"));

用 CompletableFuture 组织并行：

java
List<CompletableFuture<Result>> futures =
    tasks.stream().map(t -> CompletableFuture.supplyAsync(t::run, pool)).toList();
List<Result> all = futures.stream().map(CompletableFuture::join).toList();

情况二：CPU 密集（纯计算）

100 线程在 8 核机器上只是上下文切换狂欢。正确做法是加机器：100 个任务分发到多台实例并行（比如 13 台 8 核），单机并行度 = 核数。这已经不是线程池调参问题，是分布式任务调度问题（XXL-JOB 分片）。

必须留的余量（工程经验）

  • 理论 100 路，实际设 110~120：总有余量应对 GC 停顿、个别任务超过 0.1s、网络抖动——压着 100 路跑，P99 必然超 1s
  • 整体入口设超时（如 900ms）+ 未完成任务的降级策略，先保证按时返回，不完美结果好过超时

业务视角收尾：这种"硬 deadline"需求通常来自同步接口聚合（1s 是用户体验红线）。我会顺势建议架构层面把这条链路异步化——先返主干结果，慢任务后补（推送/轮询），把"1s 内全算完"的刚性约束消解掉，比堆 100 个线程更治本。

🏗 系统架构师 ​

这题要先建立最坏情况思维：1000 个任务全部并发涌入时，不能超过 1s 总时限。

推算过程：

  • 单任务 0.1s，1000 个串行 = 100s，不可行，必须并行
  • 假设任务都是同质且并行无资源争抢：理论最少线程数 = 1000 × 0.1s / 1s = 100 个线程刚好在 1s 内完成
  • 但要留余量：任务耗时波动、线程调度、GC、可能的慢任务，我会设 150~200 线程，让正常情况下 ~0.6s 完成，给 1s 留 40% 余量

关键追问我一定会主动说：

  1. CPU 密集还是 IO 密集：若任务纯计算且机器只有 8 核，200 线程不会更快，瓶颈在 CPU——100s 的工作量在 8 核上最快 12.5s，1s 物理上不可能，这时要么提升算力（加节点分片，1000 任务按 100 路分发到多机），要么谈判需求。若是 IO 密集（调接口、查库），200 线程单机可行
  2. 排队策略：1000 个任务用有界队列 + 一次提交，拒绝策略设 CallerRuns，保证不丢任务
  3. 超时与失败：单任务超时 0.5s 强杀，失败重试 1 次，重试后仍失败记录下来不阻塞整体
  4. 主线程收结果：CompletableFuture.allOf + join，或 invokeAll + CountDownLatch

落地参数示例：ThreadPoolExecutor(200, 200, 0, ArrayBlockingQueue(1000), CallerRunsPolicy)，IO 密集场景 + 每任务 0.5s 超时。答题亮点是指出物理上限的判断与余量设计，而不是只给一个数字。

💻 全栈开发专家 ​

先算需求：总工作量 = 1000 × 0.1s = 100s 的计算量，要在 1s 内完成，理论并发度 = 100s / 1s = 100。

推参数

java
new ThreadPoolExecutor(
    100, 100,                          // 核心=最大=100：任务短平快，没必要留伸缩空间
    0L, TimeUnit.MILLISECONDS,
    new SynchronousQueue<>(),          // 不排队：来了直接给线程，队列等待会吃掉 1s 预算
    new ThreadPoolExecutor.CallerRunsPolicy());

再配 CompletableFuture.allOf(...) 或 invokeAll 收集结果。

但必须补一句（这是加分点）

上面的 100 只有在IO 密集或核数足够时成立。如果任务是纯 CPU 计算：

  • 8 核机器上 100 个线程并行度最多 8，1s 内只能完成 0.8s×8... 实际吞吐 = 核数 × 1s / 0.1s = 80 个任务，1000 个任务物理上不可能 1s 完成。
  • 此时正确答案是：横向扩展多实例（K8s HPA 扩 13 个 Pod，每 Pod 8 并发），或者把单任务 0.1s 的计算本身优化掉。

面试要点

  1. 给公式：线程数 = 总耗时 / 可接受响应时间，队列容量 = 0 或小值。
  2. 主动指出 CPU 密集时线程数超过核数只是徒增上下文切换，1s 目标需要靠分布式横向扩容。
  3. 提一句边界：任务提交本身有开销（创建 future、调度），1000 个任务建议分批（每批 100，10 批串行提交也可控）。