★ FEATURED ARTICLE 最近两周我一直在调一个 Java 写的 AI 应用真真切切体会到了什么叫“并发一上来问题全暴露”。这个应用本身不复杂用户提需求我们把 prompt 拆解成多路子任务丢给不同的大模型并行处理再把结果汇总返回。听起来很常规对吧但上线之后大模型推理的耗时、下游服务的抖动、用户量一冲Tomcat 缺省线程池瞬间被打满接口响应从 200ms 一路涨到 10 秒CPU 和内存双双告警。那段时间我几乎每天都在看线程 dump、调线程池参数、改异步编排最后才把整个架构理顺。这篇文章就是想把这些实操经验沉淀下来讲讲 Java AI 应用在异步化与高并发设计这件事上我踩过的坑、验证过的手段以及一些可以直接抄作业的配置和代码范式。如果你正在做 AI Agent、模型网关、智能问答这类 Java 后端服务或者单纯对高并发场景下的异步设计感兴趣这篇应该能给你一些实用的参考。我不打算讲太多教科书级的理论更多的是“为什么这么选”“实际跑了之后效果如何”这类的真实体感。1. 为什么 Java AI 应用必须面对异步化这道坎1.1 AI 调用与 Web 请求的天然矛盾先看一组最基本的数字对比传统 Web 接口比如一个订单查询或用户信息接口数据库查询加缓存命中整体耗时通常在 50ms~200ms。而一次大模型推理即使是最简单的文本生成也往往需要 2~5 秒复杂一点的 Agent 链路甚至要 10 秒以上。也就是说AI 应用的一个接口天然就是“慢接口”。如果你用同步模型处理这类慢接口问题就变得非常直接一个请求占住一个 Tomcat 线程这段线程既不干别的就干等着模型响应。Tomcat 默认的 max-threads 通常配置在 200 左右这意味着在模型平均耗时 3 秒的情况下你的应用在任意瞬间大约只能同时处理 200 个请求换算成 QPS 大概也就 60~70。一旦流量超过这个数后面来的请求全部在队列里排队响应时间开始指数级恶化。这个矛盾是根本性的不是靠堆机器就能完全解决的。异步化的核心思路是没有事情做的时候不要让线程傻等把线程释放出来处理别的请求等模型结果回来了再通过回调或事件机制继续处理。这才是解决“慢接口”与“高并发”冲突的正道。1.2 同步阻塞模型与异步非阻塞的取舍我在项目初期偷懒直接用同步方式写public ChatResponse chat(String prompt) { String result aiClient.generate(prompt); // 阻塞等待大模型 return new ChatResponse(result); }这段代码逻辑极简但代价就是每个请求对应一个线程的“占用期≈模型推理期”。在用户量少的内部工具场景下完全够用一旦对外开放立刻变成瓶颈。异步改造并不是要你完全推翻业务逻辑而是把“等待模型返回”这个过程由阻塞改为挂起。Java 里做这件事有几种主流姿势CompletableFuture、回调函数、Reactive Stream比如 WebFlux以及 JDK 21 引入的虚拟线程。这些方案各有取舍我在后面几个章节会逐一展开。选型时我给团队定过一个原则能用同步逻辑表达清楚的就用同步只有长耗时 IO比如大模型调用、下游 HTTP 请求、文件读写才做异步化。不要为了异步而异步过度设计反而会把代码变得难以维护。2. Java 侧异步化与高并发的核心技术选型2.1 用 CompletableFuture 编排多模型调用在我的项目中最常用的异步工具是 CompletableFuture。它解决的不只是“单次调用异步化”更重要的是多个 AI 调用之间的依赖编排。举个实际场景我们的 Agent 在回答用户问题时需要同时做三件事调用对话模型生成主回答调用向量检索服务补充知识库片段调用独立的关键词模型抽取标签。主回答不依赖后两者完全可以并行发起。后两个结果只是作为补充信息随响应返回。用 CompletableFuture这段逻辑可以安排得非常干净CompletableFutureString answerFuture CompletableFuture.supplyAsync( () - chatModel.generate(prompt), chatExecutor); CompletableFutureListString contextFuture CompletableFuture.supplyAsync( () - vectorSearch.search(prompt), contextExecutor); CompletableFutureListString tagsFuture CompletableFuture.supplyAsync( () - tagModel.extract(prompt), tagExecutor); CompletableFuture.allOf(answerFuture, contextFuture, tagsFuture).join(); ChatResponse response new ChatResponse( answerFuture.get(), contextFuture.get(), tagsFuture.get() );这里有几个细节值得注意。allOf().join()是整体等待但如果你希望“主回答先返回、其他内容后补”就不能用 join而是给主回答单独设置回调把副任务的结果通过 listener 推送。另外supplyAsync如果没显式指定线程池默认用 ForkJoinPool.commonPool这个池子一旦被某个慢任务拖住全应用都会受害。所以我上面的代码里特意传入了独立的chatExecutor、contextExecutor各司其职。2.2 线程池参数设计不是越大越好异步化绕不开线程池而线程池的参数设计往往是新手翻车重灾区。我先说一个最常见的错误以为高并发就是线程数拉满于是把 corePoolSize 配成 500然后看着内存飙升、上下文切换疯狂应用直接卡死。AI 应用本质上是 IO 密集型程序线程大部分时间花在等待下游响应上而不是做 CPU 计算。对于 IO 密集型理论值是线程数 CPU 核数 × 2但这只适用于“等待时间不太长”的场景。因为大模型调用动辄几秒一个线程阻塞几秒实际能支撑的并发请求数还是有限。我的经验是对线程池做分层设计线程池核心线程最大线程队列用途chatExecutorCPU×250200主对话模型调用耗时最长contextExecutorCPU×220100向量检索、知识库检索tagExecutorCPU×11050轻量标签抽取webExecutorCPU×2100500接收 Web 请求后的初始分发核心思路是根据下游的容量和超时时间来决定线程数而不是根据 CPU 核数拍脑袋。比如 chatExecutor 最大 50是因为我们对接的模型服务单实例只能扛 50 并发再多就会触发对方限流。线程池大小本质上是一项“流量管控”手段而不是“性能榨干”手段。队列长度也要克制。我之前把队列设成 10000结果流量高峰时所有请求全部积压在内存队列里客户端早就超时放弃了线程池还在继续消费这些没意义的任务。现在我的做法是队列设小一点满了就触发拒绝策略直接快速失败配合前端重试或提示用户稍后再试整体体验反而更好。2.3 WebFlux 与虚拟线程两种新思路的对比这两年“Java 异步化”的版图又变了主要因为两个新东西WebFlux 和虚拟线程。WebFlux 是 Spring 5 引入的响应式栈基于 Netty从 HTTP 层到数据访问层全链路非阻塞。它的优势是单线程能支撑非常高的并发连接数原理是事件驱动一个 Netty 的 EventLoop 可以管理成千上万个连接等待 IO 的时候不占线程。我在一个轻量 AI 网关项目里试过 WebFlux场景是转发请求到多个模型服务并聚合。代码确实要换个思维方式普通 Service 层里无处不在的阻塞调用比如 JDBC、RestTemplate都会成为拦路虎需要全部替换成 WebClient、R2DBC。对于一个小团队来说这个改造成本不低。虚拟线程就友好得多。JDK 21 正式发布了虚拟线程平台线程不再是一对一绑定操作系统线程而是可以创建几十万个轻量级虚拟线程。最妙的是你的代码可以继续用同步阻塞风格写但底层由 JVM 帮你做挂起和恢复。这就等于把“异步化的复杂度”从开发者手里接走了。我在目前的项目里是这么搭配的Web 层先用传统 Spring MVC 虚拟线程把业务代码写得简单直白只有在大模型并行编排、消息推送这类需要精细控制超时和背压的地方才用 CompletableFuture 和响应式 Stream。这个组合实测下来既保住了开发效率又把高并发下的线程占用压到了一个极低的水平。3. 高并发场景下的资源管控与设计细节3.1 连接池与 Redis 的配合异步化和高并发并不只是线程层面的问题IO 连接资源同样会卡脖子。我在排查一次事故时发现应用的下游模型调用用的是最朴素的 HTTP 请求——每次调用都新建连接。单看每次调用性能差异不大但在每秒几十并发的情况下新建连接的成本被无限放大最终TIME_WAIT 连接数爆炸端口耗尽应用彻底无法发起新请求。解决方案是引入 HTTP 连接池并且设置合理的参数。我用的是 Apache HttpClient 的 PoolingHttpClientConnectionManager配置如下PoolingHttpClientConnectionManager manager new PoolingHttpClientConnectionManager(); manager.setMaxTotal(200); manager.setDefaultMaxPerRoute(100);这里有两个关键参数MaxTotal 是连接池总量DefaultMaxPerRoute 是单个下游服务的连接上限。因为模型服务的并发上限一般是有限的这里的 DefaultMaxPerRoute 应该和线程池的 maxPoolSize 对齐避免连接池过大反而把下游打挂。Redis 也是同样的道理。我们最初用 Jedis 直连后来发现高并发下频繁地创建连接Redis 服务端报“max number of clients reached”。换用 Lettuce 之后底层是共享连接 异步命令一个连接就能承担大量并发资源占用明显下降。如果你仍然用 Jedis至少应该配置一个连接池并且把池的最大大小压到 64 以下——绝大多数场景 32 就足够因为 Redis 单实例的核心瓶颈在 IO 和内存单值命令的耗时通常小于 0.1ms本地并发根本拉不满连接。3.2 重试、熔断与背压机制AI 应用的下游全部是外部服务而外部服务没有一个是永远稳定的。大模型服务经常因为限流、额度耗尽、推理超时而报错。我们的系统必须对这些异常有抵抗力否则一次上游抖动就会引发下游雪崩。这里我推荐一个组合拳重试 熔断 限流背压。重试不等于无限重试。我踩过的坑是“无脑重试 3 次”结果模型服务本来只是瞬时过载我们这 3 次重试直接把对方彻底打挂了。现在的做法是只对连接超时和 429/503 这类临时错误重试重试次数最多 1 次且使用指数退避。第一次重试等待 500ms第二次等 1s绝对不要用固定间隔。熔断我用的是 Resilience4j没有上 Sentinel虽然 Sentinel 的界面更友好但引入额外组件太重。核心配置大概是这样CircuitBreakerConfig config CircuitBreakerConfig.custom() .failureRateThreshold(50) // 失败率超过 50% .waitDurationInOpenState(Duration.ofSeconds(10)) // 熔断开启时间 .slidingWindowSize(20) // 统计窗口大小 .build();当模型服务的失败率达到阈值熔断器打开后续请求直接快速失败不再白白等待上游。这相当于给系统装了一个保险丝保护的是我们自己的线程池和连接池不被拖垮。背压这个词听起来玄乎落地到 Java 服务就是两个手段一个是信号量或令牌桶限流限制同时进入模型调用层的请求数量防止线程池被瞬间塞满另一个是有界队列处理不过来时宁可拒绝也不要无限堆积。客户端那边的背压则是通过流式响应实现——简单说就是 AI 生成一个 token 推一个 token客户端能按自己的消化能力消费避免把整段长文本一次性塞给客户端。这个我在第 4 节会展开。3.3 从高并发 IM 场景借鉴的消息设计做 AI 应用之后我发现很多设计思路其实和高并发 IM即时通讯很像。因为两者都是“请求量大、单次处理慢、需要实时性与异步解耦”。IM 系统有一个经典做法用户产生的消息先进队列由后端异步分发不直接与发送方的请求线程绑定。AI 应用也一样尤其是涉及 Agent 多轮任务时单个用户请求可能在后台跑几分钟甚至更久你不可能让 HTTP 请求一直挂着等它。我们后来引入了 MQ 做异步任务队列请求到达后先落库再发一条“任务事件”进队列后台消费者去执行真正的 AI 编排流程执行结果通过回调地址或 WebSocket 推送给用户。这个架构的额外好处是天然支持失败重试。任务消息在队列里如果消费失败可以设置死信队列单独处理不干扰主流程。对于高并发场景MQ 还帮我们做了削峰——用户请求再猛消费者端处理速率是可控的不至于直接把下游模型服务打垮。4. AI Agent 多步骤协作场景下的异步编排4.1 Agent 调用链中的并发任务规划如果你接触过 AI Agent大概率知道 Agent 的任务流程往往不是线性的而是树状甚至图状的一个主任务可能分解成多个子任务部分子任务之间没有依赖可以并行执行。我第一次写 Agent 编排时用的是同步 for 循环子任务一个一个跑整个流程耗时等于所有子任务耗时之和。后来意识到这完全不合理——并行子任务明明是同时进行的为什么代码非要串行等待改造之后就变成了基于 CompletableFuture 的图执行引擎public TaskResult execute(TaskNode node) { if (node.getDependencies().isEmpty()) { return CompletableFuture.supplyAsync( () - executeSingle(node), agentExecutor).join(); } ListCompletableFutureTaskResult dependencyFutures node.getDependencies().stream() .map(child - CompletableFuture.supplyAsync( () - execute(child), agentExecutor)) .collect(Collectors.toList()); CompletableFuture.allOf(dependencyFutures.toArray(new CompletableFuture[0])) .join(); return mergeAndExecute(node, dependencyFutures); }这个函数式写法初看有点绕但说白了就是当前节点先等它的依赖节点全部并行完成然后再执行自己。依赖关系天然变成了 DAG有向无环图的遍历模型调用层被彻底解耦。这里要特别提醒CompletableFuture 的递归调用要小心线程池的自我阻塞。当我们的 agentExecutor 线程池所有线程都阻塞在dependencyFutures的等待上时后面排队的任务反而无法获得线程执行造成死锁。解决思路是确保编排逻辑所在线程池与任务执行线程池分离或者给每个 DAG 节点分配足够的并行度。我在实际中遇到过几次诡异的任务悬挂最后都定位到这个原因。另外多 AI 协作还有一个经验值能并行的大模型调用尽量控制在 3~5 路以内。超过这个数不仅下游模型服务的并发配额容易打满聚合阶段的吞吐也会因为等待最慢的那个分支而下降。并行是手段不是目的过度并行只会放大长尾延迟。4.2 超时控制与降级策略异步化有一个大坑线程不阻塞了但“请求到底什么时候能结束”变得不好控制。如果编排链路中有一个模型调用迟迟不返回整个响应就会悬挂在那里直到客户端自己超时断开。超时控制必须做两层。第一层是单次调用的超时我用的是 CompletableFuture 配合orTimeoutCompletableFutureString future CompletableFuture.supplyAsync( () - chatModel.generate(prompt), chatExecutor) .orTimeout(5, TimeUnit.SECONDS);5 秒是我观察到的对话模型 P95 耗时的两倍留出余量但又不会等太久。一旦触发超时orTimeout会让 future 以TimeoutException完成后续的exceptionally或handle可以把失败分支接管返回预设的兜底文案。第二层是整体编排的超时。即使每个子任务都设置了 5 秒超时如果有 5 个串行依赖环节理论上整体最长可能等到 25 秒。所以我在入口处会做一个统一超时控制超过 15 秒直接返回半成品结果——“我已经生成了前半部分剩余内容请稍后在历史记录中查看”同时后台继续把完整结果算完存储。这个降级策略比“让用户一直傻等”要好得多。降级策略的优先级顺序我的经验是优先保证主回答其次是关键附加信息最后才是锦上添花的功能。比如标签抽取失败了完全可以忽略但主回答生成失败必须要有兜底话术。4.3 流式响应解决长耗时与用户体验的终极方案上面提到的所有方案本质上都是在“尽力缩短请求的感知响应时间”。但还有一条更彻底的路既然模型生成本身要花很久那就别让用户等最终结果直接把生成过程流式地推给用户。我现在的 AI 对话接口已经全部改成 SSEServer-Sent Events 流式响应。后端不再返回一个完整 JSON而是通过SseEmitter或 Spring WebFlux 的FluxString一段一段地推送生成的 tokenGetMapping(value /chat/stream, produces MediaType.TEXT_EVENT_STREAM_VALUE) public SseEmitter chatStream(String prompt) { SseEmitter emitter new SseEmitter(60_000L); asyncChatService.streamGenerate(prompt, emitter); return emitter; }异步线程在收到模型流式输出的每个分片时立刻通过emitter.send()推给客户端客户端可以边生成边展示。这样即使用户问题很复杂、完整生成需要 20 秒用户在第 3 秒就已经能看到文字在屏幕上一个一个蹦出来感知延迟被大幅降低。流式响应还有一个隐藏好处它天然实现了背压。如果客户端消费速度慢TCP 窗口自然会限制服务端发送速度服务端不必为慢客户端维护大量完整响应数据内存压力小得多。不过流式响应也带了一个新问题不能简单用 HTTP 状态码表示成败了因为响应头已经发出去链路中后面环节的错误无法通过改状态码表达。我目前的做法是在 SSE 消息 message 里带上事件类型比如[ERROR]事件客户端收到后中断展示并提示用户重试。5. 数据链路与 MySQL 高并发问题5.1 异步写库与最终一致性AI 应用的请求量一旦上来MySQL 往往成为“最后一个瓶颈”。我们之前是同步写库每次对话结束后把完整对话内容、Token 用量、耗时统计等全部插入数据库。高峰期批量写库把数据库 IO 撑高主库的读写延迟都上去了直接拖累整个应用。后面我把写库操作全部改成了异步化。业务流程不再直接调用 Mapper 的 insert而是先发送一条写库事件到内存队列或者 MQ由专门的消费者线程批量落库。异步写库带来一个数据一致性的问题如果用户刚对话完立刻查询历史记录可能查不到刚写进去的数据。处理这个问题我的做法是双轨制用户明文内容对话记录同步写因为这是核心业务数据不能丢也不能延迟可见统计类数据Token 用量、耗时明细、操作日志异步批量写这类数据偶发延迟完全可接受。想清楚哪些数据能容忍延迟是异步化数据链路设计的入门课。5.2 缓存与数据库的更新顺序另外一个高并发下经常被问到的细节缓存和数据库的更新顺序。网上讨论很多我直接说结论——更新数据库再删除缓存。先更新 DB 再删缓存存在一个极短的时间窗口更新 DB 之后、删缓存之前可能有读请求命中旧缓存。但这个窗口非常小而且缓存过期兜底之后自然能恢复。反过来先删缓存再更新 DB 反而会出现更麻烦的空窗期删完缓存后一个读请求查库拿到旧值并回填缓存之后更新的 DB 值就被旧缓存挡住了。我们在 AI 场景里还有一种特殊缓存模型生成的中间向量。这种缓存的重建成本极高一次向量化调用几秒钟因此缓存一般不过期只做主动失效。主动失效也走“先更新 DB 再删缓存”的顺序同时用延迟双删兜底——删除缓存成功后延迟几百毫秒再删一次进一步降低脏数据概率。5.3 分库分表要等真扛不住再做很多团队一看到“高并发与 MySQL”就马上想到分库分表。我的建议是先做缓存和异步化再考虑分库分表。分库分表引入的复杂度是数量级的——分布式 ID、跨库 join 失效、事务一致性、迁移工具每一项都够呛。判断分库分表时机的标准不是 QPS而是单表数据量和写入吞吐的长期趋势。如果单表超过 2000 万行或者日增数据超过 100 万行再考虑按用户 ID sharding。在 AI 应用里大部分业务表对话记录、任务状态天然有用户维度按 user_id 取模分库非常自然迁移和查询都容易对齐。如果你的 AI 应用还没有到这个量级老老实实用好以下三板斧就够了加索引、读写分离、合理事务边界。我在实际中发现很多 MySQL 慢查询问题都是缺索引导致的而不是数据库本身扛不住。6. 实操中的坑与排查实录6.1 线程池与 ThreadLocal 的相爱相杀异步化之后最隐蔽的一类问题来自 ThreadLocal。在普通 Spring MVC 里requestId、用户身份、TraceId 通常放在 ThreadLocal 里请求结束后清理。但线程池中的线程是复用的任务切到别的线程后ThreadLocal 里的值就丢了。我调试过一个“异步任务日志里有大量 null TraceId”的问题根源就是这个。CompletableFuture 的supplyAsync默认把任务交给公共线程池而公共线程池和 Web 请求线程是两拨人马上下文根本没传过去。解决方法是启用线程池的TaskDecoratorThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setTaskDecorator(runnable - { MapString, String context MDC.getCopyOfContextMap(); return () - { MDC.setContextMap(context); try { runnable.run(); } finally { MDC.clear(); } }; });这个装饰器在任务提交时抓取主线程的日志上下文在任务线程执行前恢复。想传递别的 ThreadLocal 值思路是一样的。这个细节直接影响线上问题排查能力——没有全链路 TraceId 贯穿异步化之后你会连失败链路都看不清楚。6.2 响应悬挂与线程泄漏排查异步化后最怕的就是“请求发出去了然后就没有然后了”。我遇到的典型案例是主线程用future.get()等待模型结果但负责执行模型调用的线程池因为某个下游连接挂起而全部阻塞get()永远等不到结果请求线程也被占住不放。从线程 dump 看大量线程停在LockSupport.parkNanos上状态是WAITING。排查这类问题我建议按这几个步骤走先用jstack -l pid抓线程快照统计每个线程池中线程的分布和状态重点看WAITING和BLOCKED的数量找有没有线程长时间停在某个第三方调用的 socketRead 上说明下游连接没有超时给所有下游调用强制加读超时连接超时 2s、读超时 5s这是最粗暴也最有效的防线。我的经验是大部分“看起来像死锁”的异步问题本质上都是“某个环节没有设置超时导致线程无限挂起”。把超时补齐之后这类问题能消除八成。6.3 GC 压力与内存抖动高并发 AI 应用还有一个隐形杀手短生命周期的大对象。AI 响应内容往往较长而且每个请求都会生成新的字符串、JSON 对象、Token 缓冲这些对象很快变成不可达触发频繁的 Minor GC。我优化过的一个典型案例是模型返回的内容以字符串拼接方式构建大量中间 String 对象产生后立刻废弃。改成 StringBuilder 或者直接使用流式分片输出后GC 压力降了一半。另一个经验是控制好队列积压量因为积压的任务对象本身也占用堆内存队列越大内存峰值越高。把线程池队列从 10000 压到 500 之后堆内存的峰值下降了大概 30%。如果你想少走弯路可以在压测时配合-XX:PrintGCDetails和-Xlog:gc*观察 GC 频率结合堆转储分析对象分布。但最本质的解决方案还是“减少无效对象的创建控制队列积压别把大量数据堆在内存里等处理”。最后再分享一个我的真实体会异步化和高并发设计这件事不是上线前做好“设计文档”就一劳永逸的。我是在一次严重线上事故之后用几个小时盯着线程 dump才真正把“同步”和“异步”的本质区别想明白。线程和连接池都不是越大约好异步也不是把代码全部改成回调就是最好。真正重要的是搞清楚下游的容量、请求的特性、业务的容忍度然后拿这几个数据去倒推你的线程池、队列、超时和限流参数。后面的路你就是一次压测、一次事故、一次调优这样走出来的。
阅读完成 · 觉得有帮助？
