线程池异步编排面试怎么讲：任务拆出去以后谁来兜底

很多后端项目都会把非核心动作异步化，比如下单后发通知、查询多个下游服务、批量刷新缓存。面试官看到这类项目，通常不会只问“你用了什么线程池”，而会继续问：任务拆出去以后失败怎么办？用户请求超时了，异步任务还要不要继续？多个异步任务之间有没有依赖？线程池满了会不会影响核心接口？

面试常见追问

常见追问有三类。第一类是资源问题：线程数怎么定，队列多大，任务堆积怎么发现。第二类是业务问题：异步任务失败是否影响主流程，是否需要补偿，用户能不能感知。第三类是下游问题：多个异步任务同时打到数据库或外部服务，会不会把下游打垮。

如果回答只说“我用 CompletableFuture 并发查询”，就不够。CompletableFuture 只是异步编排工具，它不会自动帮你解决线程池隔离、超时、异常和降级。

技术细节要讲到边界

异步编排最容易踩的坑，是所有任务共用默认线程池。默认线程池里如果混入慢任务，可能影响其他业务。更稳的做法是给不同任务使用独立线程池，核心链路和非核心链路隔离。

超时也要明确。比如商品详情页并发查询价格、库存、推荐理由，如果推荐理由超时，可以不展示；价格和库存超时，就不能随便给默认值。不同任务的业务重要性不同，超时策略也不同。

异常处理要有明确结果。异步任务失败后，是返回部分结果、使用缓存兜底、写补偿记录，还是直接让主请求失败，取决于它是否影响核心业务。

项目回答示例

可以这样说：我们把详情页里的推荐理由和扩展信息改成异步查询，但价格和库存仍然作为核心链路。异步任务使用独立线程池，每个下游调用有超时限制，非核心任务失败时返回降级结果，并记录失败原因。上线后看线程池队列长度、任务等待时间、下游错误率和接口整体响应时间。

这个回答能体现你知道异步的代价。线程池不是把慢问题藏起来，而是让任务并发、隔离和失败边界都更清楚。

面试里还可以补一个易错点：异步任务如果要写数据库或调用外部接口，不要默认和主请求共享同一个事务。主请求返回成功，不代表异步任务一定成功。对于必须完成的动作，要有任务记录、重试和补偿；对于可有可无的动作，要能接受失败并告警。这样回答会比单纯讲并发工具更完整。

异步任务的兜底清单

线程池题真正拉开差距的地方，是你能不能说清楚任务失败后系统怎么继续运行。异步不是把问题丢到后台，而是把执行、失败、超时和补偿都显式设计出来。

如果面试官继续问 CompletableFuture，可以说它负责组合任务，但不替你决定线程池隔离、下游保护和业务补偿。工具和工程边界分开讲，答案会更稳。