组里的实习生问我"Java 是不是没前途了"
2025 年春节后回来的第一周，组里新来的实习生私下问我："现在 AI 不都是 Python 写的吗，我学 Java 是不是选错方向了？" 这话我没法用一句"不会"糊弄过去，因为他说的是事实的一部分——过去两年所有模型层的创新确实都在 Python 生态里发生。
但事实的另一部分是：我们公司去年上线的两个 AI 系统，模型推理是 Python 同学搞的，外面那一层——权限、审计、限流、计费、跟二十几个内部系统的对接——全是我们 Java 组写的。这两件事不矛盾，我花了半小时把我们的真实分工和压测数据给他讲了一遍。
AI 系统里真正重的是什么
很多人对 AI 应用的想象是"调个模型 API 返回结果"。真到企业里跑，一次问答请求背后大概是这样的：
- 鉴权：这个用户能不能访问这个知识库？能看到哪些文档切片？
- 检索：向量库召回 + BM25 混合 + Rerank；
- 编排：多轮工具调用，中间状态要落库；
- 治理：限流、配额、计费、审计日志；
- 兜底：模型超时、返回垃圾 JSON、额度耗尽。
模型调用本身可能只占整个链路耗时的 60%~80%，但代码量占比不到 15%。剩下 85% 是传统的后端工程活——而这块恰好是 Java 生态最强的地方。
一组真实的性能对比
我们不空谈，去年 11 月做过一次对照实验。同一个 RAG 编排服务，一份用 Python FastAPI + asyncio 写（组里 Python 最强的同学写的），一份用 Spring Boot 3.4 + 虚拟线程写。业务逻辑等价，都调同一个 vLLM 部署的 Qwen2.5-32B。
| 指标 | FastAPI(uvicorn, 4 worker) | Spring Boot 3.4 + 虚拟线程 |
|---|---|---|
| 并发 200 时 P99 | 320ms | 110ms |
| 并发 1000 时 P99 | 1840ms | 390ms |
| 并发 1000 时错误率 | 3.7% | 0.1% |
| 单实例 CPU 占用 | 3.2 核 | 1.4 核 |
| 常驻内存 | 410MB | 680MB |
需要说明的是，这个对比没有侮辱 Python 的意思——瓶颈在 asyncio 单线程事件循环被同步的数据库驱动和 HTTP 客户端阻塞，换成 run_in_executor 或者上多进程能缓解。但 Java 这边我们几乎什么都没调，虚拟线程一开，JDBC 这种阻塞代码直接跑到 1000 并发也没事。这就是 JVM 二十多年攒下来的家底。
虚拟线程让 Java 在这一轮重新变简单
这是我今年最想强调的一点。以前 Java 想扛高并发，要么上响应式（WebFlux 那一套），代码写得人神共愤；要么堆线程池，一个 IO 慢就把池打满。JDK 21 的虚拟线程把这事儿彻底简化了：
@Bean
TaskExecutor taskExecutor() {
return new VirtualThreadTaskExecutor("rag-");
}
// 业务代码里没有任何"异步"的痕迹
public Answer ask(Question q) {
var docs = vectorStore.similaritySearch(q.text()); // 阻塞 IO，无所谓
var reranked = rerankService.rerank(q.text(), docs); // 还是阻塞
return chatClient.prompt()
.system(systemPrompt)
.user(q.text())
.call()
.entity(Answer.class);
}同步的写法，异步的性能。我们线上的 RAG 网关，16 核机器单实例扛住了 3200 QPS，P99 稳定在 130ms 以内，堆内存 2GB 够用。这个数字在 2023 年用线程池方案是不可想象的。
该承认 Python 强的地方
我不主张用 Java 硬啃一切。下面这些场景我们坚决用 Python：
- 模型训练与微调：PyTorch、DeepSpeed、LoRA 全套工具链，Java 生态是空白，别挣扎；
- 数据处理与实验：pandas、numpy、Jupyter，探索性分析的速度 Java 追不上；
- 新模型首发适配：一个新架构出来，Python 当天就能跑，Java 侧往往要等几周甚至几个月；
- 推理服务本身：vLLM、SGLang、TGI 都是 Python 写的，我们直接用 HTTP 调，不重复造轮子。
我们的分工线画得很清楚：Python 负责"智能"的部分，Java 负责"可靠"的部分。中间用 HTTP 或者 gRPC 隔开，各干各的，互不干扰。这套分工上线跑了八个月，没出过职责扯皮。
Java 在 AI 工程里真正吃香的几块
要说具体优势，我觉得排得上前三的是这些：
- 企业集成能力。Spring 生态里现成的东西太多了：Spring Security 接公司的 SSO，Spring Data 访问十几种数据库，Micrometer + OpenTelemetry 一套埋点打全链路。我们接入公司统一审计只写了 40 行配置；
- 长生命周期服务。AI 应用经常要跑长任务——一个 Agent 流程可能跑十几分钟。Java 的状态管理、持久化、事务回滚是成熟到骨子里的，Python 这边要做到同等可靠需要额外投入；
- 可观测性。JFR、async-profiler、Arthas 这一套排查工具，线上出问题时的定位速度差一个数量级。上周我们有个 RAG 服务 P99 突然抖到 2s，用 JFR 抓了 30 秒就定位到是向量库连接池被打满。
反过来说，Java 这一轮的短板也很明显：算法库和社区热度确实不如 Python，Spring AI 到现在还在快速迭代，M6 到 M7 之间 API 就变过好几次。选型时要接受这种不稳定。
留个问题
关于《Java 在 AI 时代的定位与优势》里这个坑，你当时是怎么处理的？欢迎在评论区聊聊你踩过的类似情况。