Java 大厂面试实录：Spring Boot + Kafka + Redis + AI RAG 场景下，燕双非的“水”与“稳”
场景：互联网大厂 Java 求职面试，业务方向为企业协同与 SaaS + 大数据与 AI 服务。面试官严肃，候选人燕双非嘴贫但偶尔能答对。共三轮提问，层层递进。
第一轮：基础与工程化能力
面试官：先说说你在 Java 11/17 里最常用的特性有哪些？在企业协同 SaaS 项目里为什么要升级？
燕双非：嗯……最常用的就是 var、Optional、Stream，还有一些更方便的语法糖。升级的话，主要是为了写代码更短、更优雅，也能跟上时代……
面试官：说得不算差，至少知道是“升级不是为了面子”。那你再说说 JVM 里你会重点关注哪些指标，线上频繁 Full GC 该怎么排查？
燕双非：这个嘛，先看内存是不是不够，再看是不是对象太多，可能还有代码里一直 new……然后我会先重启试试，毕竟重启能解决 80% 的问题。
面试官：重启是运维手段，不是排查结论。继续。
面试官：Maven 和 Gradle 你怎么选？在一个包含 Spring Boot、MyBatis、Flyway、Junit 5 的协同办公项目里，构建流程怎么设计？
燕双非：Maven 更稳，大家都熟；Gradle 更快一点。我们一般就是打包、跑测试、再做数据库脚本校验，Flyway 负责版本管理……
面试官：回答到点了。至少知道构建要覆盖测试与数据库迁移，而不是只会“mvn package”。
第二轮：业务架构与中间件
面试官：假设你在做企业协同 SaaS，有“审批流、消息提醒、文件协作”三个子系统。Spring Boot 怎么拆服务？Spring Cloud、OpenFeign、Resilience4j 你会怎么组合？
燕双非：可以拆成审批服务、通知服务、文件服务。服务之间用 OpenFeign 调用，接口慢的话加 Resilience4j 做熔断和限流，Spring Cloud 负责注册发现和配置管理……
面试官：思路是对的。那如果审批发起后要推送消息到 Kafka，通知服务消费失败怎么办？
燕双非：失败就重试呗，Kafka 不是挺能扛的吗。要是还不行，就记到数据库里，之后人工补偿……
面试官：方向可以，但你需要把“幂等、重试、死信、补偿”讲清楚。别只会一句“人工补偿”。
面试官：文件协作里，用户经常上传 Excel、合同、图片。你会怎么做缓存和文件元数据管理？Redis、Caffeine、MyBatis/JPA 你怎么搭？
燕双非：热点文件信息放 Redis，页面列表放 Caffeine 做本地缓存，文件元数据入库。MyBatis 适合复杂 SQL，JPA 适合简单 CRUD……
面试官：不错，至少知道缓存分层和 ORM 的适用边界。
第三轮：AI 服务化与稳定性治理
面试官：现在公司要做智能客服，要求接入 Spring AI、RAG、向量数据库、工具调用。你怎么设计“企业文档问答”链路？
燕双非：先把文档切片，做向量化，存到 Milvus 或 Redis 里。用户提问后先做语义检索，再把检索结果拼到提示词里，让模型回答。必要时再走工具调用查工单、查审批状态……
面试官：这次回答得比较完整。那你怎么降低 AI 幻觉？如果模型瞎编了审批规则，怎么兜底？
燕双非：呃……可以限制它只能回答检索到的内容；高风险问题走规则引擎和人工确认；还可以加引用来源和置信度判断……
面试官：对。企业场景里，AI 不是“想象力比赛”，而是“可控性比赛”。
面试官：最后一个问题：你如果负责整个系统的可观测性，会怎么接 Prometheus、Grafana、Micrometer、Jaeger/Zipkin、ELK？
燕双非：Micrometer 统一埋点，Prometheus 拉指标，Grafana 看面板；日志进 ELK，链路追踪用 Jaeger 或 Zipkin。这样出问题能看指标、看日志、看链路……
面试官：行，至少这部分没太离谱。今天就先到这儿，你回去等通知吧。
问题详解与知识点总结
1. Java 11/17 常用特性：在企业项目中，Java 11/17 的升级价值不仅是语法糖，更重要的是长期支持版本、性能优化、安全增强和生态兼容。常见特性包括 var、Optional、Stream 改进、文本块、record、switch 表达式、sealed class 等。业务上，SaaS 系统通常需要更稳定的运行环境和更好的可维护性，升级 JDK 能减少历史包袱。
2. JVM 排查 Full GC：重点看堆内存分配、对象存活率、晋升失败、元空间、GC 日志、线程栈和是否存在内存泄漏。常见排查路径是：先观察 GC 日志和监控指标，再用 jstat、jmap、MAT、Arthas 等工具分析对象分布，最后回到代码和流量模型。不要把“重启”当成分析结论。
3. Maven 与 Gradle 构建设计：Maven 适合规范统一、团队协作强、生命周期明确的场景；Gradle 更适合复杂构建和增量编译。企业协同项目中，构建流程通常包括：代码检查、单元测试、集成测试、数据库迁移验证、制品打包、镜像构建、发布到 CI/CD。Flyway 适合数据库版本演进，避免多人协作时脚本失控。
4. Spring Boot + Spring Cloud + OpenFeign + Resilience4j：协同办公系统可按领域拆分为审批、通知、文件、用户、权限等服务。OpenFeign 负责声明式调用，Resilience4j 负责熔断、限流、重试、隔离，Spring Cloud 负责服务发现、配置管理和网关等能力。设计时要关注超时设置、降级策略、链路追踪和接口幂等性。
5. Kafka 消息可靠性：审批发起后推送消息到 Kafka，消费者失败时不能只靠“重试一下”。应结合消息幂等、重试次数、延迟重试、死信队列、补偿任务与人工兜底。生产端要关注消息 key、分区策略与顺序性；消费端要处理重复消费与事务一致性问题。
6. Redis + Caffeine 分层缓存：Redis 适合分布式共享缓存，Caffeine 适合本地热点缓存。企业协作系统中，文件元数据、权限配置、模板数据可做缓存，但要考虑一致性、失效策略和缓存穿透/击穿/雪崩。MyBatis 适合复杂 SQL 和报表查询，JPA 适合简单实体管理和快速开发，选择的关键是团队效率与业务复杂度。
7. Spring AI + RAG + 向量数据库：智能客服或企业文档问答一般采用“文档加载 → 切片 → 向量化 → 向量数据库存储 → 语义检索 → 拼接上下文 → 大模型生成”的链路。可使用 Milvus、Chroma、Redis 向量能力等存储 embedding；Embedding 模型可来自 OpenAI 或 Ollama。本质是通过检索增强生成减少幻觉，提高企业知识问答的可控性。
8. 工具调用与 Agentic RAG：当用户问到“查审批状态、查工单、发起流程”时，单纯生成文本不够，需要工具调用标准化，把外部系统能力包装成可执行工具。Agentic RAG 强调检索与行动结合，适合复杂工作流和智能客服系统。关键是权限控制、审计、工具返回结果校验，以及避免模型误调用。
9. 降低 AI 幻觉：企业场景必须控制模型“胡说八道”。可采用强约束提示词、仅基于检索内容回答、引用来源、事实核验、规则引擎兜底、高风险问题转人工、输出格式校验等方式。对于审批、合同、财务等敏感场景，AI 应作为辅助而非最终裁决者。
10. 可观测性体系：Micrometer 统一采集指标，Prometheus 负责存储与告警，Grafana 展示面板，ELK 用于日志检索与分析，Jaeger/Zipkin 用于链路追踪。一个完整的 SaaS 平台要做到“指标看趋势、日志看细节、链路看调用、告警看异常”，这样才能快速定位问题。
感谢阅读，希望这篇面试实录能够帮助大家更好地理解 Java 面试中的技术栈组合、业务落地思路与系统设计方法，也希望能真正帮助到正在准备大厂面试的你。
