互联网大厂 Java 面试实录Spring Cloud Kafka Redis AI 业务场景深挖场景某互联网大厂进行 Java 后端面试业务方向为本地生活服务 AIGC 智能客服面试官严肃专业候选人燕双非主打一个“会一点但不多”。第一轮基础能力与系统认知面试官先说下你在 Java 8、11、17 里更常用哪一个为什么我们做新项目时会更关注 JVM 与版本特性燕双非嗯……Java 8 最熟Lambda、Stream 用得比较多。11 我也见过17 主要是朋友在聊我自己项目里还没怎么上。JVM 呢主要就是 GC 和内存调优吧听说很重要。面试官回答得还算基础扎实至少知道版本演进和 JVM 是后端性能的底座。那你说说 Maven 和 Gradle 你怎么选燕双非Maven 比较稳大家都在用依赖管理很规范。Gradle 我知道它更灵活构建快一点但我平时还是 Maven 多。面试官嗯选择思路没问题。那我们做本地生活服务订单、商家、优惠券多个服务之间通信你会优先考虑 Spring MVC 还是 Spring WebFlux燕双非如果是传统同步接口我会先用 Spring MVC。WebFlux 我知道是响应式适合高并发和流式处理但我没在项目里大规模用过。面试官至少方向是对的。那你简单讲下 Swagger/OpenAPI 在这个项目里有什么价值燕双非主要是接口文档和联调方便前后端对齐字段、状态码会更快。第二轮业务链路与中间件选型面试官现在场景升级一下用户下单后商家接单、优惠券核销、通知推送都要异步处理。你会怎么设计消息链路Kafka、RabbitMQ、JMS 你怎么考虑燕双非下单主链路还是同步保证结果后面的通知、积分、埋点这些用消息队列异步。Kafka 更适合吞吐高的场景RabbitMQ 我印象里路由更灵活JMS 算是老一点的规范。面试官不错知道按业务特征选型。那如果消息重复投递了你怎么保证幂等燕双非我会……在数据库里加个唯一键或者消费时先查一下有没有处理过面试官这就比空谈强一些。那订单状态和库存扣减都依赖数据库你会怎么管理事务边界MyBatis、JPA、Spring Data JDBC 你会怎么理解燕双非MyBatis 比较适合复杂 SQLJPA 比较省事适合标准 CRUD。Spring Data JDBC 我接触少一点好像更轻量。事务边界一般放在服务层保证一个业务动作的一致性。面试官回答开始像样了。那连接池 HikariCP 和 C3P0你怎么选燕双非HikariCP 性能一般更好现在项目里用得多C3P0 我只在老项目里见过。面试官好。再往下优惠券过期、订单超时、活动开始结束这种定时任务你会怎么做Flyway 或 Liquibase 又在什么时候介入燕双非定时任务可以用 Spring 的调度或者配合消息延迟队列。Flyway、Liquibase 主要是数据库版本管理表结构变更可追踪避免上线时手工改库。第三轮高并发、稳定性与 AI 业务扩展面试官现在我们加一个 AI 智能客服模块用户问“我为什么没收到退款”“这个券为什么不能用”系统要接入 Spring AI、RAG、向量数据库。你怎么理解这条链路燕双非嗯……先把企业文档、退款规则、活动规则这些做文档加载再切分成向量放到 Milvus 或 Redis 里。用户提问后做语义检索把相关片段拼到提示词里再让大模型回答。这样能减少胡说八道。面试官很好已经接近业务落地了。那如果客服系统要接工具调用比如查订单、查券、查物流你会怎么设计 Agentic RAG 和工具执行框架燕双非我理解是模型先判断要不要调用工具再通过标准化接口去调用订单服务、券服务、物流服务。Agent 负责规划工具负责执行RAG 负责补知识。这样模型不直接瞎编接口结果。面试官思路不错。那高并发下缓存怎么做Redis、Caffeine、Spring Cache 你会怎么配合燕双非热点数据先本地缓存 Caffeine再用 Redis 做分布式缓存。Spring Cache 统一抽象缓存注解方便切换实现。比如商家信息、活动配置这种读多写少的可以缓存。面试官最后一个问题服务间调用出问题了你怎么保证系统可用性Resilience4j、OpenFeign、Prometheus、Jaeger 这些怎么用燕双非OpenFeign 做声明式调用Resilience4j 加超时、重试、熔断、限流。Prometheus 采集指标Grafana 看板监控Jaeger 做链路追踪出问题能快速定位。面试官行今天先到这里。你回去等通知吧。问题详解与业务落地分析1. Java 8/11/17 与 JVM在大厂项目中选择 Java 版本不仅是语法问题更涉及长期支持、性能优化和生态兼容。Java 8 适合遗留项目11 和 17 更适合新项目JVM 则承载 GC、类加载、内存模型、线程调度等关键能力决定了高并发服务的稳定性。2. Maven 与 GradleMaven 依赖模型标准、团队协作成本低适合大多数企业项目Gradle 更灵活适合复杂构建和多模块加速。互联网大厂里通常会根据团队规范统一选型避免构建体系碎片化。3. Spring MVC 与 Spring WebFlux本地生活服务里大部分接口还是以同步 CRUD 为主Spring MVC 足够稳定WebFlux 更适合长连接、流式数据、高并发 I/O 密集型场景例如实时消息推送或流式日志处理。4. Swagger/OpenAPI接口文档不仅是“文档”更是协作协议。它能帮助前后端统一请求参数、响应结构、错误码与鉴权方式减少联调成本尤其适合多服务协同的业务线。5. 消息队列选型订单下单成功后的通知、积分、埋点适合异步化。Kafka 更擅长高吞吐和日志型处理RabbitMQ 更擅长复杂路由与精细化投递控制JMS 是标准规范通常出现在兼容旧系统的场景。6. 消息幂等在支付、订单、库存场景消息重复消费是常态而不是异常。常见做法包括业务唯一键、防重表、状态机校验、Redis 去重标记等核心原则是“允许重复投递但只处理一次有效结果”。7. 事务边界与 ORM 选择订单、库存、券核销必须围绕业务事务设计通常在服务层统一控制。MyBatis 适合复杂 SQL 与强可控场景JPA 适合标准化 CRUDSpring Data JDBC 更轻量但生态和复杂映射能力相对简单。8. HikariCP 与数据库迁移HikariCP 因轻量、性能优、默认配置合理已成为主流连接池。Flyway/Liquibase 则解决数据库版本演进问题确保表结构变更可追踪、可回滚、可审计避免“手工改库”带来的事故。9. AI 智能客服中的 RAG对于退款规则、优惠券规则、商家协议等企业知识直接让大模型回答容易产生幻觉。RAG 的核心是“先检索再生成”先把文档切片、向量化、存入向量数据库再按用户问题做语义检索把相关知识拼接到提示词中从而提升准确率。10. Agent 与工具调用当客服需要查订单、查物流、查券状态时大模型不能直接瞎猜必须通过工具调用访问真实服务。Agent 负责意图识别与任务规划工具执行框架负责标准化接入后端 API形成“模型决策 系统执行”的闭环。11. 缓存体系设计Caffeine 适合本地热点缓存延迟低、性能高Redis 适合分布式缓存、会话存储、分布式锁、排行榜等场景Spring Cache 则提供统一抽象便于在业务层通过注解快速接入缓存能力。12. 稳定性治理OpenFeign 提供声明式远程调用Resilience4j 用于熔断、限流、超时、重试和舱壁隔离Prometheus Grafana 做指标监控Jaeger 做分布式链路追踪。它们共同支撑大厂系统的高可用与可观测性。感谢阅读希望这篇互联网大厂 Java 面试实录能帮助大家更好地理解常见技术栈在真实业务中的落地方式也希望对你的面试准备有所帮助。