互联网大厂 Java 面试实录Spring Boot Kafka Redis Spring AI 的一次“翻车”与翻盘场景某互联网大厂 Java 后端岗位面试业务方向为电商场景 AIGC 智能客服。面试官严肃专业候选人是外号“燕双非”的水货程序员嘴上很会细节一问就开始飘。整场面试分三轮推进问题由浅入深围绕真实业务场景展开。第一轮电商下单链路与基础工程能力面试官你先说说如果你负责一个电商下单接口技术栈准备用Spring Boot MyBatis Redis MySQL你会怎么设计燕双非这个简单啊先写 Controller接收参数然后 Service 里查库存、扣库存、写订单最后返回成功。Redis 用来做缓存能快一点。MyBatis 就负责 SQL特别稳。面试官那你说说为什么库存要先查再扣直接数据库 update 不行吗燕双非呃……也不是不行但先查一下心里有底嘛。缓存里也可以先看一下减少数据库压力。然后如果库存不够就直接返回。面试官那如果并发下单很多两个请求同时读到库存都够怎么办燕双非这个……可以加锁吧Java 里 synchronized 一下或者 Redis 里弄个分布式锁大家排队比较文明。面试官好至少你知道并发冲突。那订单号你怎么生成保证高并发下不重复燕双非订单号嘛时间戳加随机数基本不会重复。要是还不够就再加个机器号。面试官思路还行后面可以继续展开雪花算法和号段模式。第二轮消息异步化、缓存一致性与可观测性面试官现在业务增长了下单后要同步发短信、发券、触发风控还要写 AIGC 客服侧边推荐你会怎么做燕双非这个就不能全都同步做了太慢。我会先把主链路下单成功然后把后续事情丢到Kafka里异步处理。短信、发券、客服推荐各消费各的。面试官为什么选 Kafka不选数据库轮询燕双非Kafka 吞吐高嘛适合这种解耦的场景。数据库轮询太笨重延迟也不太好控制。面试官那异步消息怎么保证不丢、不重燕双非不丢的话……生产者确认、消息持久化、消费者手动提交。至于不重可以做幂等比如订单号做唯一键重复消费就忽略。面试官不错。那库存缓存怎么和数据库保持一致燕双非一般是先写库再删缓存或者延迟双删。反正核心是别让脏数据一直留在 Redis 里。面试官如果缓存失效引发瞬时流量打到数据库你怎么抗燕双非可以做热点 Key 预热、互斥重建、限流、降级还可以加本地缓存比如Caffeine。面试官那你怎么知道系统快不快、哪里慢燕双非埋点啊日志啊监控啊。用Micrometer打指标接Prometheus Grafana看图链路追踪可以上Jaeger/Zipkin。慢的话就抓ELK日志排查。面试官这轮比刚才靠谱至少知道观测体系。第三轮AIGC 智能客服、RAG 与 JVM 深水区面试官现在我们要做一个电商智能客服能回答订单、物流、退换货还能基于企业文档做知识问答。你怎么设计燕双非这个就是Spring AIRAG啊。用户提问后先做语义检索把相关文档从向量数据库里捞出来比如Milvus或者 Redis 向量能力然后把检索结果和用户问题一起拼进 Prompt发给大模型。面试官那你为什么不直接把所有文档都塞给模型燕双非因为上下文窗口不够而且会贵还容易把模型喂晕。RAG 就是把相关内容挑出来减少幻觉。面试官如果客服要调用查订单、查物流、改地址这些外部能力你怎么组织燕双非可以做工具调用标准化让模型先判断要不要调用工具。比如订单查询是一个工具物流查询是一个工具改地址是另一个工具。模型只负责决策真正执行还是后端服务。面试官那 Agent 和普通问答有什么区别燕双非Agent 更像会自己规划步骤的“实习生”能拆任务、调工具、看结果、再决定下一步。普通问答就是一次性回答没那么会动脑子。面试官如果模型答非所问甚至编造订单状态你怎么处理燕双非这个就是 AI 幻觉嘛。要做权限隔离、检索增强、工具结果优先、答案置信度控制。关键业务信息不要让模型自由发挥得让它“有据可查”。面试官最后一个问题JVM 里频繁创建短生命周期对象比如消息拼装、Prompt 组装会有什么问题燕双非会增加 GC 压力尤其是 Young GC。要尽量复用对象、减少字符串拼接、用 StringBuilder另外还要关注堆大小、GC 参数和对象晋升。面试官行今天先到这。你回去等通知吧。问题详解从电商交易到 AIGC 智能客服1. 电商下单接口如何设计核心目标是高并发下的正确性与性能。通常采用 Spring Boot 作为入口MyBatis 负责精确 SQL 操作Redis 负责热点数据缓存数据库负责最终一致性落地。下单链路应尽量短参数校验、库存校验、创建订单、发送异步消息。在并发场景中必须重点考虑库存超卖。常见做法包括数据库乐观锁、Redis 预扣减、分布式锁、消息串行化等。实际生产里通常结合使用主链路快速返回异步进行后续动作。2. 为什么要引入 Kafka 异步化在订单完成后短信、积分、风控、推荐等动作彼此解耦适合通过消息队列实现削峰填谷。Kafka 适合高吞吐、可扩展的事件流场景。关键是保证消息不丢、可重试、可幂等。常见组合是生产者确认 Broker 持久化 消费者手动提交 offset 业务幂等表或唯一索引。3. 缓存一致性如何保证最常见的是先写数据库再删除缓存。因为更新数据库成功后缓存保留旧值会导致读到脏数据。为了降低并发下的极端问题可以使用延迟双删、消息通知删缓存、热点 Key 预热、本地缓存如 Caffeine等策略。核心原则是缓存服务于性能但不能破坏业务正确性。4. 如何进行系统监控与排障现代 Java 系统必须具备可观测性。Micrometer 负责统一指标采集Prometheus 拉取指标Grafana 展示趋势图Jaeger/Zipkin 负责分布式链路追踪ELK 负责日志检索与问题定位。对面试来说重点不是背工具名而是要讲清楚指标看趋势、日志看细节、链路看瓶颈。5. 为什么智能客服适合 RAG纯大模型问答容易出现幻觉尤其在订单、退款、物流这类强业务约束场景中不能让模型“自由发挥”。RAG 的思路是先检索企业文档、FAQ、制度、知识库再把相关内容作为上下文喂给模型。这样既能降低幻觉又能让答案可追溯。如果要进一步落地企业文档问答通常需要文档加载、切分、向量化、语义检索、重排、Prompt 拼装、答案引用来源等流程。向量数据库可以选择 Milvus、Chroma 或 Redis 向量能力。6. Agent 与工具调用如何理解Agent 可以理解为“会规划的模型应用”。它不只是回答问题而是能根据目标调用多个工具逐步完成任务。例如用户说“帮我查下订单并修改地址”Agent 可能先查订单再校验是否可改再调用改地址接口。工具调用标准化的关键在于模型只做决策业务执行由后端系统完成。7. 如何降低 AI 幻觉带来的风险常见手段包括限制模型自由编造、强制引用检索结果、工具结果优先、答案置信度阈值、敏感操作必须二次确认、权限隔离、审计日志等。对于金融、电商、医疗等场景AI 只能作为“辅助决策层”不能取代事实源系统。8. JVM 为什么会成为面试重点因为线上问题很多最终都会落到 JVM。大量短生命周期对象会带来 Young GC 压力字符串拼接会增加临时对象复杂的对象图还可能导致晋升和 Full GC 风险。面试中如果能自然聊到堆、栈、GC、对象分配、逃逸分析、参数调优说明你不只是会写业务代码还理解运行时原理。总结这场面试从电商下单、消息异步化、缓存一致性一路深入到 AIGC 智能客服、RAG、Agent 和 JVM。真正好的 Java 工程师不只是会用 Spring Boot 写接口还要能把业务、性能、稳定性、可观测性和新技术结合起来讲清楚“为什么这么做”。感谢阅读希望这篇文章能帮助你更好地准备互联网大厂 Java 面试少踩坑多上岸 互联网大厂 Java 面试实录：Spring Boot + Kafka + Redis + Spring AI 的一次“翻车”与翻盘
互联网大厂 Java 面试实录Spring Boot Kafka Redis Spring AI 的一次“翻车”与翻盘场景某互联网大厂 Java 后端岗位面试业务方向为电商场景 AIGC 智能客服。面试官严肃专业候选人是外号“燕双非”的水货程序员嘴上很会细节一问就开始飘。整场面试分三轮推进问题由浅入深围绕真实业务场景展开。第一轮电商下单链路与基础工程能力面试官你先说说如果你负责一个电商下单接口技术栈准备用Spring Boot MyBatis Redis MySQL你会怎么设计燕双非这个简单啊先写 Controller接收参数然后 Service 里查库存、扣库存、写订单最后返回成功。Redis 用来做缓存能快一点。MyBatis 就负责 SQL特别稳。面试官那你说说为什么库存要先查再扣直接数据库 update 不行吗燕双非呃……也不是不行但先查一下心里有底嘛。缓存里也可以先看一下减少数据库压力。然后如果库存不够就直接返回。面试官那如果并发下单很多两个请求同时读到库存都够怎么办燕双非这个……可以加锁吧Java 里 synchronized 一下或者 Redis 里弄个分布式锁大家排队比较文明。面试官好至少你知道并发冲突。那订单号你怎么生成保证高并发下不重复燕双非订单号嘛时间戳加随机数基本不会重复。要是还不够就再加个机器号。面试官思路还行后面可以继续展开雪花算法和号段模式。第二轮消息异步化、缓存一致性与可观测性面试官现在业务增长了下单后要同步发短信、发券、触发风控还要写 AIGC 客服侧边推荐你会怎么做燕双非这个就不能全都同步做了太慢。我会先把主链路下单成功然后把后续事情丢到Kafka里异步处理。短信、发券、客服推荐各消费各的。面试官为什么选 Kafka不选数据库轮询燕双非Kafka 吞吐高嘛适合这种解耦的场景。数据库轮询太笨重延迟也不太好控制。面试官那异步消息怎么保证不丢、不重燕双非不丢的话……生产者确认、消息持久化、消费者手动提交。至于不重可以做幂等比如订单号做唯一键重复消费就忽略。面试官不错。那库存缓存怎么和数据库保持一致燕双非一般是先写库再删缓存或者延迟双删。反正核心是别让脏数据一直留在 Redis 里。面试官如果缓存失效引发瞬时流量打到数据库你怎么抗燕双非可以做热点 Key 预热、互斥重建、限流、降级还可以加本地缓存比如Caffeine。面试官那你怎么知道系统快不快、哪里慢燕双非埋点啊日志啊监控啊。用Micrometer打指标接Prometheus Grafana看图链路追踪可以上Jaeger/Zipkin。慢的话就抓ELK日志排查。面试官这轮比刚才靠谱至少知道观测体系。第三轮AIGC 智能客服、RAG 与 JVM 深水区面试官现在我们要做一个电商智能客服能回答订单、物流、退换货还能基于企业文档做知识问答。你怎么设计燕双非这个就是Spring AIRAG啊。用户提问后先做语义检索把相关文档从向量数据库里捞出来比如Milvus或者 Redis 向量能力然后把检索结果和用户问题一起拼进 Prompt发给大模型。面试官那你为什么不直接把所有文档都塞给模型燕双非因为上下文窗口不够而且会贵还容易把模型喂晕。RAG 就是把相关内容挑出来减少幻觉。面试官如果客服要调用查订单、查物流、改地址这些外部能力你怎么组织燕双非可以做工具调用标准化让模型先判断要不要调用工具。比如订单查询是一个工具物流查询是一个工具改地址是另一个工具。模型只负责决策真正执行还是后端服务。面试官那 Agent 和普通问答有什么区别燕双非Agent 更像会自己规划步骤的“实习生”能拆任务、调工具、看结果、再决定下一步。普通问答就是一次性回答没那么会动脑子。面试官如果模型答非所问甚至编造订单状态你怎么处理燕双非这个就是 AI 幻觉嘛。要做权限隔离、检索增强、工具结果优先、答案置信度控制。关键业务信息不要让模型自由发挥得让它“有据可查”。面试官最后一个问题JVM 里频繁创建短生命周期对象比如消息拼装、Prompt 组装会有什么问题燕双非会增加 GC 压力尤其是 Young GC。要尽量复用对象、减少字符串拼接、用 StringBuilder另外还要关注堆大小、GC 参数和对象晋升。面试官行今天先到这。你回去等通知吧。问题详解从电商交易到 AIGC 智能客服1. 电商下单接口如何设计核心目标是高并发下的正确性与性能。通常采用 Spring Boot 作为入口MyBatis 负责精确 SQL 操作Redis 负责热点数据缓存数据库负责最终一致性落地。下单链路应尽量短参数校验、库存校验、创建订单、发送异步消息。在并发场景中必须重点考虑库存超卖。常见做法包括数据库乐观锁、Redis 预扣减、分布式锁、消息串行化等。实际生产里通常结合使用主链路快速返回异步进行后续动作。2. 为什么要引入 Kafka 异步化在订单完成后短信、积分、风控、推荐等动作彼此解耦适合通过消息队列实现削峰填谷。Kafka 适合高吞吐、可扩展的事件流场景。关键是保证消息不丢、可重试、可幂等。常见组合是生产者确认 Broker 持久化 消费者手动提交 offset 业务幂等表或唯一索引。3. 缓存一致性如何保证最常见的是先写数据库再删除缓存。因为更新数据库成功后缓存保留旧值会导致读到脏数据。为了降低并发下的极端问题可以使用延迟双删、消息通知删缓存、热点 Key 预热、本地缓存如 Caffeine等策略。核心原则是缓存服务于性能但不能破坏业务正确性。4. 如何进行系统监控与排障现代 Java 系统必须具备可观测性。Micrometer 负责统一指标采集Prometheus 拉取指标Grafana 展示趋势图Jaeger/Zipkin 负责分布式链路追踪ELK 负责日志检索与问题定位。对面试来说重点不是背工具名而是要讲清楚指标看趋势、日志看细节、链路看瓶颈。5. 为什么智能客服适合 RAG纯大模型问答容易出现幻觉尤其在订单、退款、物流这类强业务约束场景中不能让模型“自由发挥”。RAG 的思路是先检索企业文档、FAQ、制度、知识库再把相关内容作为上下文喂给模型。这样既能降低幻觉又能让答案可追溯。如果要进一步落地企业文档问答通常需要文档加载、切分、向量化、语义检索、重排、Prompt 拼装、答案引用来源等流程。向量数据库可以选择 Milvus、Chroma 或 Redis 向量能力。6. Agent 与工具调用如何理解Agent 可以理解为“会规划的模型应用”。它不只是回答问题而是能根据目标调用多个工具逐步完成任务。例如用户说“帮我查下订单并修改地址”Agent 可能先查订单再校验是否可改再调用改地址接口。工具调用标准化的关键在于模型只做决策业务执行由后端系统完成。7. 如何降低 AI 幻觉带来的风险常见手段包括限制模型自由编造、强制引用检索结果、工具结果优先、答案置信度阈值、敏感操作必须二次确认、权限隔离、审计日志等。对于金融、电商、医疗等场景AI 只能作为“辅助决策层”不能取代事实源系统。8. JVM 为什么会成为面试重点因为线上问题很多最终都会落到 JVM。大量短生命周期对象会带来 Young GC 压力字符串拼接会增加临时对象复杂的对象图还可能导致晋升和 Full GC 风险。面试中如果能自然聊到堆、栈、GC、对象分配、逃逸分析、参数调优说明你不只是会写业务代码还理解运行时原理。总结这场面试从电商下单、消息异步化、缓存一致性一路深入到 AIGC 智能客服、RAG、Agent 和 JVM。真正好的 Java 工程师不只是会用 Spring Boot 写接口还要能把业务、性能、稳定性、可观测性和新技术结合起来讲清楚“为什么这么做”。感谢阅读希望这篇文章能帮助你更好地准备互联网大厂 Java 面试少踩坑多上岸