Java 求职面试实战Spring Cloud Kafka Redis Spring Security AI/RAG 的大厂三轮交锋场景互联网大厂 Java 求职者面试人物严肃面试官、搞笑的水货程序员燕双非第一轮基础能力与核心语言面试官先聊基础。Java 11 和 Java 17 你更倾向选哪一个做线上服务为什么燕双非嗯……Java 17 吧感觉版本更新应该更强一点像新手机总比旧手机顺手。还有 LTS稳定一点。面试官回答方向对了。那你说说 JDK 17 相比 JDK 8除了语法新特性线上收益主要体现在哪燕双非我觉得主要是性能、垃圾回收、还有一些更现代的并发支持吧。比如更好的 G1、ZGC 之类服务高峰时延迟会更稳。面试官不错至少知道线上关注点不是“语法炫不炫”而是吞吐、延迟和维护成本。面试官那你解释一下 JVM 中对象从创建到回收的大致过程。燕双非先在堆里分配年轻代优先能活下来就进老年代GC 会定期扫描引用链断了就回收。大概就是“活着升级没用淘汰”。面试官总结得还行。那你补一句为什么线上偶发 Full GC 会让接口抖动燕双非因为停顿会把请求线程卡住像高峰期收银台突然重启后面全排队。面试官这个比喻很形象。面试官再问个常见问题Maven 依赖冲突你怎么排查燕双非先看 dependency:tree找到版本冲突再用 dependencyManagement 锁版本实在不行排除传递依赖。面试官这题可以思路清晰。第二轮业务系统设计与中间件面试官假设你在做一个电商秒杀系统活动开始后流量突然暴涨你怎么保护库存服务燕双非先在前面挡一层比如网关限流、静态化、验证码、排队然后库存扣减做异步化别让请求直接打到数据库。面试官很好先削峰再落库。那 Redis 在这里除了缓存商品详情还能做什么燕双非可以做库存预扣、分布式锁、热点商品标记、限流计数还有消息去重吧。面试官不错。那你说说 Redis 分布式锁的坑。燕双非嗯……锁过期时间不够会误释放解锁要校验 owner高并发下还得考虑续期、原子性最好别拿锁当万能药。面试官回答得比较像做过线上的人。面试官如果订单创建后要异步通知库存、优惠券、物流你会选 Kafka 还是 RabbitMQ燕双非大流量、可扩展、顺序消费这些我会偏 Kafka如果是复杂路由、低延迟任务分发RabbitMQ 也不错。秒杀场景我可能更偏 Kafka。面试官可以。那消息重复消费怎么处理燕双非业务幂等最常见是用唯一业务号加去重表或者 Redis setnx 记录处理状态。面试官很好幂等是分布式系统的必修课。面试官你用过 Spring Cloud 吗讲讲服务治理里熔断、限流、重试怎么配合。燕双非嗯先限流防止流量把服务打爆重试要谨慎不能把故障放大熔断是在下游持续失败时快速失败给系统喘口气。Resilience4j 里这些能力可以组合使用。面试官说得不错注意重试一定要带退避和上限。第三轮安全、AI 与云原生落地面试官现在很多业务都在接入 AI。假设你要做一个企业文档问答系统要求支持“自然语言语义搜索 智能客服 复杂工作流”你怎么设计燕双非我会先把文档切分、清洗、向量化存到向量数据库里用户提问时先做语义检索再把检索结果喂给大模型生成答案。还可以加聊天会话内存和工具调用做成 Agentic RAG。面试官不错已经接近实战了。那你怎么降低 AI 幻觉燕双非加强检索约束提示词里要求“仅基于检索内容回答”再加引用片段和置信度控制关键场景可以让模型先检索后回答不让它瞎编。面试官对工程上就是“让模型少自由发挥多有证据”。面试官如果这个系统要对接企业单点登录和权限控制你会怎么做燕双非Spring Security 配 OAuth2 / JWT 做认证接口按角色和权限控制如果和统一身份系统集成可以接 Keycloak。敏感数据还要加审计日志。面试官可以。那你知道 WebSocket 在这个系统里能做什么吗燕双非做实时问答流式输出、进度通知、或者客服会话推送用户体验会好很多。面试官最后一个问题如果这个服务要部署到 Kubernetes你会重点关注哪些指标燕双非CPU、内存、Pod 重启次数、请求延迟、错误率、GC 指标还有 Prometheus 和 Grafana 监控。要是链路排查我会看 Jaeger 或 Zipkin。面试官整体还行但有些地方还需要继续打磨。这样吧你先回去等通知。问题详解1. Java 11/17 线上选型在互联网大厂的 Java 服务中版本选型通常要综合考虑 LTS、性能、生态兼容性和团队维护成本。Java 17 作为较新的 LTS 版本适合新项目或逐步升级中的核心系统。相比 Java 8通常能获得更好的 GC 表现、更现代的语法和更长生命周期支持。实际落地时还要结合中间件兼容性、第三方库版本和线上压测结果。2. JVM 与 Full GC 抖动JVM 管理对象生命周期Young GC 处理新生对象Old GC/Full GC 则处理老年代或整堆回收。Full GC 的停顿时间通常更长会阻塞业务线程导致接口 RT 突增、超时和排队。线上治理通常要关注对象分配速率、晋升压力、堆大小、GC 日志和压力场景下的延迟分布。3. Maven 依赖冲突排查排查依赖冲突通常从mvn dependency:tree入手确认同一坐标是否被多个版本传递引入。解决方式包括在dependencyManagement中统一版本、显式排除冲突依赖、升级基础 BOM、必要时拆分模块。大厂项目中统一依赖管理非常重要否则会出现运行时方法缺失、类冲突和序列化异常。4. 秒杀系统削峰与库存保护秒杀系统的核心难点是高并发和资源争抢。常见方案包括网关限流、验证码、静态页面、请求排队、库存预扣、异步下单、消息队列削峰、数据库最终一致性。库存服务不能直接承受所有请求否则极易被打爆。Redis 可用于预扣库存、热点缓存和分布式协调但最终落库仍要保证一致性。5. Redis 分布式锁Redis 锁常用于控制临界区但必须正确处理过期、释放和续期问题。常见最佳实践是使用唯一标识作为锁值解锁时校验 owner避免误删设置合理过期时间并结合续期对高价值业务使用更稳妥的方案例如 ZooKeeper 或数据库乐观锁。Redis 锁适合“轻量协调”不适合替代完整事务。6. Kafka 与 RabbitMQ 选型Kafka 更适合高吞吐、可水平扩展、日志流式处理和事件驱动架构RabbitMQ 在复杂路由、灵活投递和低延迟任务分发方面表现不错。秒杀、埋点、订单事件流更偏 Kafka业务规则复杂、需要精准路由的场景可考虑 RabbitMQ。选型本质上要看吞吐、延迟、顺序、运维复杂度和团队熟悉度。7. 消息幂等与重复消费分布式系统里消息重复是常态不是异常。幂等处理通常依赖业务唯一键、去重表、状态机、Redis 标记或数据库唯一索引。关键原则是消费者可以重复收到消息但业务结果只能生效一次。对于订单、库存、支付这类场景幂等设计必须前置而不是出问题后再补救。8. Spring Cloud 的限流、重试、熔断限流用于保护系统入口防止请求洪峰把服务拖垮重试用于临时性故障恢复但必须控制次数和退避策略否则会放大故障熔断用于在下游持续异常时快速失败给系统恢复时间。Resilience4j 提供了轻量而灵活的实现。大厂系统常把这三者组合起来形成完整的容灾链路。9. AI 企业文档问答与 RAG企业文档问答系统一般采用 RAG先对文档做加载、切分、清洗、Embedding再存入向量数据库用户提问时进行语义检索取回相关片段交给大模型生成答案。这样可以减少模型“凭空想象”显著降低 AI 幻觉。若加入工具调用、会话记忆和工作流编排就能升级成 Agentic RAG适合智能客服、知识助手和复杂审批场景。10. 降低 AI 幻觉的方法常见方法包括限制回答范围、加入引用证据、设置系统提示词、增强检索召回、设置置信度阈值、对关键场景做人工兜底。工程上本质是减少模型自由发挥空间让回答尽可能“有依据、可追溯”。11. Spring Security、OAuth2、JWT、KeycloakSpring Security 负责认证授权框架JWT 适合无状态令牌OAuth2 适合第三方授权或统一认证接入Keycloak 可作为身份中心。企业系统中常见做法是统一登录后签发 JWT后端服务通过 Spring Security 校验 Token 并基于角色、权限或资源范围做鉴权。12. WebSocket 在实时系统中的作用WebSocket 适合双向实时通信例如问答流式输出、客服在线会话、订单状态实时通知、协同编辑和直播互动。相比轮询它更节省资源用户体验也更好。在 AI 场景中流式输出尤其常见。13. Kubernetes 监控指标容器化部署后需要关注 Pod 健康、资源利用率、重启次数、请求延迟、错误率和 JVM 指标。Prometheus 负责采集指标Grafana 负责可视化Jaeger/Zipkin 负责链路追踪。只有把应用、基础设施和调用链串起来才能快速定位线上问题。感谢阅读希望这篇文章能帮助你更好地准备 Java 面试也欢迎你继续深入练习和总结祝大家都能拿到满意的 offer