项目里一个核心接口需要异步执行多个任务，你会怎么设计线程池参数、隔离和监控？
我的判断
核心接口的线程池要围绕下游容量和超时预算设计：隔离、有限并发、有界队列、明确拒绝，并让每个阶段都可观测。
我不会直接套“CPU 核数乘二”。先画出这些异步任务调用哪些资源：商品和库存可能走不同 RPC，推荐可能更慢且允许降级。不同故障域会拆独立线程池，避免推荐超时把库存查询的线程也占满。
线程数从下游允许并发和本服务耗时估算，再用压测修正；队列一定有界。核心任务队列满时可以让调用线程执行形成背压，非核心任务则快速失败或降级，不能继续堆积。每个 Future 都继承总请求 deadline，单任务超时后取消，接口结束后不让后台任务继续消耗资源。
上线会盯这些信号：
- active 线程、队列长度和最老任务等待时间；
- 提交量、完成量、拒绝量和任务耗时分位数；
- 下游超时率，以及主接口还有多少剩余时间预算。
线程池只能管理本机排队，不能提高下游容量。即使线程还能开，也会用信号量或限流保护数据库和 RPC 服务。
容易答偏踩坑误区
- 多个核心链路共用一个大池。 一个慢下游会拖住所有任务。
- 使用无界队列。 告警出现时任务可能已经排了几分钟。
- 只配置任务超时，不配置请求总 deadline。 多层重试后总耗时仍会失控。