互联网大厂Java面试实录：JVM、Spring Boot、Redis、Kafka、Spring Cloud、MCP与RAG三轮拷打

一、故事背景

谢飞机最近混进了一家互联网大厂的面试现场，岗位是高级Java开发工程师。
这家公司主营业务很复杂：既有求职招聘平台，也有内容社区与UGC，还在做AIGC简历优化、AI客服、企业知识库问答。
系统架构从单体一路演进到微服务，技术栈覆盖Spring Boot、Spring Cloud、Redis、Kafka、MyBatis、JVM、Docker、Kubernetes、Prometheus、ELK，最近还在试点Spring AI、MCP、RAG、向量数据库。

面试官姓李，风格严肃，说话像线上故障复盘。
谢飞机表面稳如老狗，内心慌得一批，但他有个特点：简单题会，复杂题就开始云里雾里胡侃。

二、第一轮面试：招聘主链路的Java基础与系统设计

业务背景：
用户在招聘平台投递简历，系统需要完成职位展示、简历投递、推荐排序、消息通知等流程。
面试官先从基础架构和后端核心能力开始问。

问题1：你先说说，招聘平台为什么大多数后端还是以 Spring Boot 为主，而不是一上来就 WebFlux？

面试官：
你做过招聘系统吧？如果我们做一个职位投递平台，为什么很多团队还是优先 Spring Boot + Spring MVC，而不是直接上 Spring WebFlux？

谢飞机：
这个我会。Spring Boot 开箱即用，生态好，和 Spring MVC、MyBatis、Spring Security、Redis 这些都很好集成。
WebFlux 也挺好，就是……它比较“响应式”，适合那种特别高并发、I/O很多的场景。
但我们大多数招聘系统，其实很多地方还是数据库操作、业务校验、权限判断比较多，所以 Spring MVC 更稳一点。

面试官：
嗯，回答得还行，至少没把 WebFlux 说成前端框架。那你继续说，什么时候会考虑 WebFlux？

谢飞机：
比如要接很多外部服务、长连接、流式返回、AI问答流式输出、WebSocket消息推送这种，可以考虑。

面试官：
不错，继续。

问题2：JVM 调优你做过什么？如果投递高峰时服务频繁 Full GC，你怎么排查？

面试官：
周一早上九点，校招投递高峰，投递服务突然 RT 飙高，Full GC 频繁。你怎么排查？

谢飞机：
这个也见过。先看监控，比如 CPU、内存、GC 次数。
然后……可以看 JVM 堆是不是太小，或者对象太多。
再看日志，必要时 dump 一下。
一般我会调大堆内存，比如-Xms -Xmx，然后用 G1 收集器。

面试官：
这只能算“会背关键词”。你说具体点，什么对象多？为什么会多？

谢飞机：
呃……可能是简历列表查询查太大了，一次查几千条，放进内存了。
也可能是 JSON 序列化对象太多，或者缓存没用好。
还有就是线程池堆积任务，那个……对象一直释放不掉。

面试官：
行，勉强有点思路，继续。

问题3：职位列表接口你会怎么做缓存？Redis、Caffeine、Spring Cache 各怎么用？

面试官：
职位列表是高频读接口，首页和搜索页流量大，你怎么做缓存设计？

谢飞机：
这个简单。
Redis 放分布式缓存，多个服务都能用。
Caffeine 放本地缓存，速度快。
Spring Cache 就是方便，不想每次手写缓存逻辑时可以用注解。

面试官：
你这回答像目录，不像方案。实际怎么组合？

谢飞机：
可以二级缓存嘛。
先查 Caffeine，本地没有再查 Redis，Redis 没有再查数据库。
热点职位、热门搜索条件可以缓存。
然后设置过期时间，避免缓存雪崩。
再加随机过期时间，防止一起失效。

面试官：
还行，终于说到点子上了。

问题4：MyBatis、JPA、Hibernate 在这个招聘系统里你怎么选？

面试官：
你别只会背框架名。职位搜索、简历投递、用户画像这三类业务，你会怎么选 ORM 层方案？

谢飞机：
我一般会选 MyBatis。SQL 可控，复杂查询方便。
JPA 和 Hibernate 适合那种增删改查比较标准的业务。
比如用户基础信息、企业基础档案这些可以用 JPA。
复杂搜索、报表统计、多表联查还是 MyBatis 更顺手。

面试官：
嗯，这个回答不错。那数据库变更怎么做版本管理？

谢飞机：
Flyway 或 Liquibase。
每次建表、加索引、字段变更都要脚本化，跟代码一起走发布流程。

面试官：
可以，至少干过活。

三、第二轮面试：微服务、消息队列与稳定性治理

业务背景：
平台已经拆成多个服务：用户服务、职位服务、投递服务、推荐服务、消息服务、风控服务。
这一轮重点考察微服务拆分、异步化、容错治理。

问题1：简历投递成功后，为什么不直接同步调用消息服务、推荐服务、风控服务？

面试官：
用户点击“投递简历”，你要同步调用消息服务发通知、调用推荐服务更新画像、调用风控服务审查内容。
你会全同步做吗？

谢飞机：
不会。
因为同步调用太多，链路会变长，接口容易慢，还容易一个服务挂了拖死全部。
所以可以把部分流程异步化，比如发 Kafka 或 RabbitMQ。

面试官：
那哪些适合同步，哪些适合异步？

谢飞机：
投递主流程里，核心写库得同步，比如投递记录必须先成功。
通知、画像更新、埋点、统计这些可以异步。
风控嘛……如果是强校验就同步，如果是补充审核就异步。

面试官：
这个回答不错，有业务意识。

问题2：Kafka、RabbitMQ、Pulsar 你怎么选？

面试官：
你刚提了 MQ。那你说说，在招聘平台里，投递事件流、通知消息、AI处理任务，这三类场景怎么选 Kafka、RabbitMQ、Pulsar？

谢飞机：
Kafka 吞吐高，适合大数据日志流、埋点流、推荐事件流。
RabbitMQ 比较适合业务消息，路由灵活。
Pulsar……也挺强，存算分离，功能比较全。
如果公司已经有 Kafka，就先用 Kafka。

面试官：
这回答有点“见过 PPT”。再具体点。

谢飞机：
比如：

• 投递行为流、推荐特征流，用 Kafka；
• 短信、站内信、邮件通知，用 RabbitMQ；
• AI 异步任务如果要求租户隔离强、积压处理灵活，Pulsar 也可以考虑。

面试官：
行，至少比刚才强。

问题3：Spring Cloud 里 OpenFeign、Gateway、Resilience4j 分别怎么配合？

面试官：
一个微服务系统里，用户服务调职位服务、推荐服务、AI服务，链路复杂。你说说 OpenFeign、Gateway、Resilience4j 怎么用？

谢飞机：
Gateway 放最前面，做统一路由、鉴权、限流。
OpenFeign 是服务间调用。
Resilience4j 用来做熔断、限流、重试、隔离。

面试官：
那如果 AI 简历优化服务很慢，经常超时怎么办？

谢飞机：
Feign 调用超时要设置合理一点，别无限等。
Resilience4j 可以做超时控制、熔断。
还可以降级，比如先返回“简历优化任务已提交，请稍后查看结果”。

面试官：
不错，这个回答是在线上的。

问题4：注册中心你会选 Eureka 还是 Consul？Dubbo 或 gRPC 又怎么插进来？

面试官：
你们老系统可能是 Netflix OSS，新系统可能想上 Consul，部分高性能内部调用还想上 Dubbo 或 gRPC。你怎么理解这几种组合？

谢飞机：
Eureka 以前用得多，但现在很多团队会转向 Consul。
Consul 功能更全一点，服务发现、健康检查都比较好。
Dubbo 适合 Java 内部高性能 RPC。
gRPC 更适合跨语言。
如果 AI 服务有 Python，Java 调 Python，我觉得 gRPC 比较合适。

面试官：
嗯，这个方向对。那序列化怎么选？

谢飞机：
内部高性能一般 Protobuf，普通 HTTP 接口还是 Jackson JSON 最方便。
如果做日志或离线传输，Avro 也有场景。

面试官：
还行。

四、第三轮面试：AI、MCP、RAG、安全与可观测性

业务背景：
公司要做一个“AI求职助手”，支持简历优化、岗位问答、企业知识库问答、智能客服。
要求接入企业内部知识库，尽量减少大模型胡说八道，还要能接工具。

问题1：你说说 MCP、RAG、Agent 在 AI 求职助手里分别是干什么的？

面试官：
别背概念，放到业务里讲。我们要做 AI 求职助手，MCP、RAG、Agent 各自负责什么？

谢飞机：
RAG 我知道，是先检索资料再让大模型回答，减少胡说。
Agent 就是让模型自己规划步骤、调用工具。
MCP……就是工具调用标准化？像一个协议，把模型和工具接起来。

面试官：
嗯，这个还算靠谱。那在求职助手里怎么落地？

谢飞机：
比如用户问“某岗位面试重点是什么”，先通过 RAG 去检索岗位JD、题库、企业知识库。
如果用户要“帮我优化简历并投递”，那 Agent 可以拆步骤。
MCP 就用来统一接简历解析工具、职位搜索工具、投递工具、通知工具这些。

面试官：
不错，这个回答值得加点分。

问题2：怎么减少 AI 幻觉？只说“加 RAG”不够。

面试官：
如果求职助手乱编公司福利、乱编岗位要求，你怎么治理幻觉问题？

谢飞机：
这个……主要就是 RAG。
把知识库喂给它。
然后提示词写严谨一点，让它不要乱说。

面试官：
太泛了，继续。

谢飞机：
呃，还可以做答案引用来源。
检索不到就明确说“暂无依据”。
再做召回排序，比如向量检索加关键词检索一起上。
还有就是模型输出后做一些规则校验。

面试官：
这就好多了，继续。

问题3：向量数据库、Embedding、语义检索怎么选型？

面试官：
企业知识库有岗位JD、面试题库、员工手册、培训文档，怎么做语义检索？

谢飞机：
先把文档切块，再做 Embedding，向量化后存到 Milvus、Chroma 或 Redis 这种向量库里。
用户提问时，把问题也向量化，然后做相似度检索。
再把召回结果拼到 prompt 里给大模型。

面试官：
那为什么有时候还要加 Elasticsearch？

谢飞机：
因为纯向量检索可能对关键词不敏感。
像岗位名、城市名、薪资范围这种强过滤条件，ES 做关键词和条件过滤更好。
可以做混合检索。

面试官：
不错，这个回答是可以的。

问题4：这个 AI 系统怎么做安全和监控？

面试官：
AI求职助手要接用户简历、企业内部文档，还要访问投递接口。安全和观测你怎么做？

谢飞机：
安全这块要做 Spring Security、JWT、OAuth2。
内部统一身份可以对接 Keycloak。
接口要做权限控制、审计日志、敏感字段脱敏。
传输层走 HTTPS，敏感数据加密，必要时可以用 Bouncy Castle 做一些加密能力。

面试官：
监控呢？

谢飞机：
Micrometer 打指标，Prometheus 采集，Grafana 看图。
日志进 ELK。
链路追踪用 Jaeger 或 Zipkin。
AI 这边还要看：

• 模型响应耗时
• Token 消耗
• 检索命中率
• 幻觉反馈率
• 工具调用成功率

面试官：
这题答得不错，终于像个干过 AI 项目的人了。

五、面试结束

面试官：
今天先到这里。你的基础还行，部分问题有实战痕迹，但复杂场景的深度还不够，尤其是 JVM 细化分析、消息一致性、AI治理细节这块还要再补。
你先回去等通知吧，如果后面流程推进，我们 HR 会联系你。

谢飞机：
好的李老师，我回去先把 JVM、Kafka、RAG 和工资期望一起复习一下。

六、详细答案解析：把业务场景和技术点讲透

1. 为什么招聘平台常用 Spring Boot + Spring MVC，而不是直接上 WebFlux？

业务背景

招聘平台的核心链路通常包括：

• 职位列表查询
• 简历投递
• 用户中心
• 企业后台管理
• 消息通知

这类业务大量依赖数据库事务、权限校验、缓存访问、第三方接口调用。
虽然并发高，但很多瓶颈不一定在 Servlet 模型，而是在数据库、缓存、下游依赖和系统治理。

技术结论

• Spring Boot + Spring MVC
  • 生态成熟
  • 与 MyBatis、JPA、Spring Security、Redis、Kafka 集成方便
  • 团队开发维护成本低
• Spring WebFlux
  • 更适合高 I/O、长连接、流式响应场景
  • 例如：
    • AI 对话流式输出
    • WebSocket 消息流
    • 大量并发调用外部服务
    • SSE 推送

面试要点

面试时不要说谁“绝对更先进”，而是要强调：

• 业务类型
• 团队能力
• 生态成熟度
• 系统瓶颈位置

2. JVM 调优到底怎么排查 Full GC？

业务背景

在投递高峰期，短时间大量用户发起请求，会导致：

• 对象创建量暴增
• JSON 序列化压力大
• 大分页查询/大对象加载
• 缓存未命中导致数据库回源
• 线程池任务堆积

这些都可能引发 Young GC 频繁，进一步演变为 Full GC。

排查路径

1. 先看监控

   • CPU
   • 内存
   • GC 次数
   • GC 停顿时间
   • 堆使用趋势

2. 看 GC 日志

   • 是否老年代增长过快
   • 是否存在频繁晋升
   • 是否回收效果差

3. 看堆 Dump

   • 用 MAT、jmap 等工具分析大对象、可疑引用链
   • 排查是否有内存泄漏

4. 回到代码和业务

   • 是否一次查太多数据
   • 是否把简历全文、附件、富文本一次性加载进内存
   • 是否缓存设计不合理
   • 是否线程池队列堆积导致对象迟迟不释放

常见优化手段

• 合理设置-Xms -Xmx
• 优先使用 G1（Java 11/17 中常见）
• 避免大对象和超大分页
• 优化 JSON 序列化与对象拷贝
• 用 MapStruct 替代部分反射型转换
• 热点数据走 Redis / Caffeine 缓存
• 控制线程池大小和队列长度

3. Redis、Caffeine、Spring Cache 应该怎么组合？

业务背景

职位列表、热门职位、公司详情页、推荐标签这类接口通常读多写少，非常适合做缓存。

典型方案：二级缓存

• 一级缓存：Caffeine
  • 本地缓存
  • 访问快
  • 适合热点高频数据
• 二级缓存：Redis
  • 分布式共享缓存
  • 多实例统一访问
• 封装层：Spring Cache
  • 通过注解降低模板代码量

缓存问题治理

1. 缓存穿透

   • 查不到的数据也短暂缓存
   • 布隆过滤器辅助

2. 缓存雪崩

   • 过期时间加随机值
   • 热点数据预热

3. 缓存击穿

   • 热点 Key 加互斥锁/单飞机制
   • 使用逻辑过期

面试加分点

能说出“本地缓存 + 分布式缓存 + 注解封装 + 过期策略 + 一致性治理”就比只会说 Redis 强很多。

4. MyBatis、JPA、Hibernate 怎么选？

选择思路

• MyBatis
  • 复杂 SQL、报表、多表联查、分页优化更灵活
• JPA / Hibernate
  • 标准 CRUD 开发效率高
  • 适合领域模型比较稳定的业务

招聘系统中的建议

• 用户基础资料、企业资料：JPA/Hibernate 可考虑
• 职位搜索、投递报表、推荐数据分析：MyBatis 更实用
• 数据版本管理：Flyway / Liquibase
• 连接池：HikariCP 优先，现代项目里比 C3P0 更常见

5. 为什么投递主流程要拆同步和异步？

业务背景

用户点击“投递简历”后，可能涉及：

• 写投递记录
• 校验岗位状态
• 风控审核
• 发送站内信/短信/邮件
• 更新推荐系统画像
• 埋点统计
• AI 生成投递建议

如果全部同步执行，会导致：

• 接口耗时长
• 下游一挂全挂
• 用户体验差

拆分原则

同步做核心，异步做扩展

• 同步：
  • 投递记录写库
  • 关键业务校验
  • 强一致风控校验
• 异步：
  • 通知发送
  • 埋点统计
  • 推荐画像更新
  • 离线特征计算
  • AI 后处理任务

相关技术

• Kafka：高吞吐事件流
• RabbitMQ：灵活业务消息
• Pulsar：多租户、存算分离场景
• JMS / ActiveMQ：偏传统系统兼容场景

6. OpenFeign、Gateway、Resilience4j 怎么配合？

典型职责

• Gateway
  • 统一入口
  • 路由、鉴权、限流、黑白名单
• OpenFeign
  • 服务间 HTTP 调用
• Resilience4j
  • 熔断、限流、重试、隔离、超时控制

业务案例

AI简历优化服务平均耗时 3 秒，偶发超时 10 秒。
如果投递服务直接同步等待，就会拖慢整体链路。

优化方式

• Feign 设置合理超时
• Resilience4j 设置：
  • timeout
  • retry
  • circuit breaker
  • bulkhead
• 降级响应：
  • “任务已提交，稍后查看结果”

面试亮点

不是只说“用了熔断”，而是说出：

• 哪类服务需要熔断
• 哪类服务适合降级
• 哪类服务不能重试（防止重复写）

7. Kafka、RabbitMQ、Pulsar 怎么选？

对比思路

Kafka

适合：

• 用户行为日志
• 推荐特征流
• 埋点数据
• 大数据消费链路

特点：

• 高吞吐
• 顺序分区
• 适合流式处理（Flink/Spark）

RabbitMQ

适合：

• 站内信
• 邮件
• 短信
• 业务通知
• 灵活路由

特点：

• 路由模型丰富
• 业务消息友好

Pulsar

适合：

• 多租户
• 大规模消息积压
• 存算分离架构

面试回答模板

不要说“哪个好”，要说“不同业务适合不同 MQ”。

8. AI 场景里，MCP、RAG、Agent 分别是什么？

RAG

检索增强生成

• 先从知识库中检索相关内容
• 再把检索结果提供给模型回答

适合：

• 岗位问答
• 企业制度问答
• 面试题解析
• 简历优化建议

Agent

智能代理

• 能理解目标
• 能拆解步骤
• 能调用工具
• 能在复杂流程中执行多步任务

适合：

• 帮用户做多轮求职任务
• 如“分析简历 -> 匹配岗位 -> 生成投递建议 -> 发送提醒”

MCP

模型上下文协议

• 统一模型和工具之间的调用方式
• 让模型通过标准协议访问外部能力

适合：

• 调职位搜索工具
• 调简历解析工具
• 调通知工具
• 调知识库检索工具

9. 如何减少 AI 幻觉？

常见方法

1. RAG 提供真实上下文
2. 混合检索
   • 向量检索 + 关键词检索
3. 结果引用
   • 输出答案时附来源
4. 检索不到就拒答
   • 不要强行编
5. Prompt 约束
   • 明确“没有依据不要生成”
6. 输出后校验
   • 对薪资、地点、岗位要求等关键字段做规则校验
7. 人工反馈闭环
   • 收集错误答案，优化知识库和检索链路

面试亮点

只说“加 RAG”是不够的，必须说到：

• 检索质量
• 召回排序
• 拒答机制
• 引用来源
• 规则校验

10. 向量数据库、Embedding、语义检索如何落地？

基本流程

1. 文档加载

   • JD、题库、制度文档、FAQ、企业知识库

2. 文档切块

   • 按段落、主题、长度切分

3. Embedding 向量化

   • 使用 OpenAI/Ollama 等 embedding 模型

4. 向量存储

   • Milvus / Chroma / Redis 向量能力

5. 查询检索

   • 用户问题向量化
   • 做相似度召回

6. 结果增强

   • 拼接到 Prompt 中交给大模型

为什么还要 Elasticsearch？

因为：

• 城市
• 岗位名
• 薪资范围
• 公司名 这类字段更适合关键词和条件过滤。
  所以很多系统采用：
• ES 做精确过滤
• 向量库做语义召回
• 再做混合排序

11. AI 系统的安全与观测怎么做？

安全

• Spring Security：认证授权基础框架
• JWT：无状态认证
• OAuth2：第三方授权体系
• Keycloak：统一身份认证中心
• Bouncy Castle：加密能力支持
• 敏感字段脱敏：手机号、身份证、邮箱、简历附件
• 审计日志：谁查了什么数据、谁调用了什么工具

观测

• Micrometer：埋业务与系统指标
• Prometheus：采集指标
• Grafana：可视化
• ELK：日志分析
• Jaeger / Zipkin：分布式链路追踪

AI专项指标

• 模型响应耗时
• 首Token时间
• Token消耗
• 检索召回率
• 工具调用成功率
• 幻觉反馈率
• 用户追问率
• 知识库命中率

12. 其他技术栈怎么自然融入面试回答？

虽然文章主线不可能把用户列出的全部技术逐个展开，但在真实面试中可以这样理解：

• 构建工具：Maven 主流，Gradle 在部分项目更灵活，Ant 多见于遗留系统
• 模板引擎：Thymeleaf、FreeMarker、Velocity、JSP 多在后台管理或旧系统
• 日志框架：SLF4J 门面 + Logback/Log4j2 实现
• 序列化：Jackson 常规 JSON；Protobuf/gRPC 高性能；Avro 偏数据链路
• CI/CD：Jenkins、GitLab CI、GitHub Actions；容器化常配 Docker、Kubernetes
• 大数据：Kafka + Flink/Spark + Elasticsearch 常见于推荐、画像、日志分析
• 测试：JUnit5、Mockito、AssertJ 做单测；Selenium/Cucumber 适合集成和行为测试
• 工具库：Guava、Apache Commons、Lombok、MapStruct 都是提效利器
• 其他框架：Dubbo 在 Java 内部 RPC 常见；R2DBC 用于响应式数据库访问；WebSocket 适合实时消息推送

七、给小白的复习路线

如果你是 Java 面试初学者，可以按下面路线学：

1. Java基础 + JVM

   • 内存结构、类加载、GC、常见排查

2. Spring Boot + Web

   • MVC、参数绑定、拦截器、异常处理、Spring Security

3. 数据库与缓存

   • MyBatis、索引、事务、Redis、缓存问题

4. 消息队列与微服务

   • Kafka、RabbitMQ、OpenFeign、Gateway、熔断限流

5. 监控与运维

   • Prometheus、Grafana、ELK、链路追踪

6. AI融合能力

   • RAG、MCP、Agent、向量检索、幻觉治理

学到这里，你就不只是“会写 CRUD”，而是能把业务场景、系统设计、稳定性、AI扩展能力串起来回答。