上周有个准备跳大厂的学弟找我做模拟面试上来就抛了个问题“Java基础、Spring Boot、微服务这些我都背了好几轮为什么一到现场还是被问到卡壳”我反问他“那你说说一个请求从网关进来到服务把大模型的回答通过SSE流式渲染到浏览器页面中间到底发生了什么”他愣住了。这才是现在互联网大厂Java求职面试的真实缩影——面试官不再满足于你背得出“Spring Boot是什么”“微服务有哪些组件”而是要求你能把Java基础、Spring Boot、微服务、数据一致性、AI技术栈这几个模块串成一条完整链路去思考问题。这篇文章就围绕这条链路来拆。我会把面试里最容易被追问的Java难点、Spring Boot核心机制、微服务架构落地以及AI交互逻辑封装、SSE流式输出、abort中断这些近两年越来越高频的新考点一项项讲清楚最后附上我实际面试、带人、做项目过程中踩过的坑和排查思路。不管你是准备校招还是社招都建议按这个框架过一遍比盲目刷八股文有用得多。1. 打牢地基Java基础与并发机制的面试必考点1.1 JVM内存与类加载机制动态链接的真相很多人把“Java基础”理解成背语法、背集合、背面向对象但在大厂面试里基础题往往是披着语法外衣的JVM题。面试官特别喜欢问这样一个问题“new出来的对象放在堆里那类信息、静态变量、常量池放哪儿反射凭什么能拿到一个类的方法”这个问题的核心考的是运行时常量池和方法区在HotSpot里通常对应元空间。Java源文件编译成class字节码后类信息、字段描述、方法描述、常量池都会加载到元空间。对象实例在堆上但对象头里有一个指向类元数据的指针这个指针才是运行时能确认“这个对象属于哪个类”的关键。所以Java本质上是动态链接的——JVM在运行期通过符号引用解析出实际的方法地址而不是像C/C那样在编译期就做静态链接。这个点你在面试里主动说出来会显得基本功很扎实。类加载的双亲委派模型也是高频题。面试官会追问“为什么JVM要设计成父类加载器优先而不是子类优先”核心答案是为了避免核心类库被篡改。你自己写一个java.lang.String正常情况下根本不会被加载因为引导类加载器会优先加载JDK自带的String。但这里有一个延伸考点Tomcat为什么打破双亲委派因为Web容器需要隔离不同应用的类库版本所以采用本地优先加载。这种“知道标准模型又能说出打破模型的真实场景”的回答很容易和只会背概念的人拉开差距。在JVM调优和内存排查这块面试往往结合线上问题一起问。比如“服务CPU飙升你怎么排查”“频繁Full GC是什么原因”。我给出的回答思路是先通过jstack拿线程栈看有没有死循环或者锁竞争再用jstat -gcutil观察各个代的GC次数和时间确认是不是对象分配速率过高或者内存泄漏配合jmap导出堆dump用MAT分析大对象和引用链。这个思路本身比记住一堆JVM参数更有价值因为面试官想看你是否有完整的故障定位方法论。还有一个容易被问倒的点Java对象在内存中的布局。对象头包含Mark Word和类型指针Mark Word里存了哈希码、GC分代年龄、锁状态标志。讲到锁状态时顺带引出偏向锁、轻量级锁、重量级锁的升级过程这就是从JVM基础自然过渡到并发题目的最佳路径。你会发现面试官其实很少按部就班问“什么是AQS”更多是从一个对象的状态开始一步一步把话题引向并发控制。1.2 并发编程从AQS到锁实战别只知道八股并发是Java面试的深水区其中AQSAbstractQueuedSynchronizer几乎是大厂必问。但如果你只是背出“AQS是一个同步框架通过state和CLH队列实现锁”——这个回答太干拿不到高分。更好的表达方式是结合你实际用过的锁来讲。以ReentrantLock为例它内部就是基于AQS实现的。AQS维护了一个volatile的int类型state表示同步状态。加锁时通过CAS去抢state抢不到就把当前线程封装成Node节点挂到CLH双向队列尾部然后LockSupport.park()阻塞自己。释放锁时修改state唤醒队首线程。这里可以对比synchronizedJDK 1.6之后synchronized也做了大量优化有偏向锁、轻量级锁、锁膨胀的升级路径而且它是JVM层面的关键字异常时由监视器指令自动释放锁。而ReentrantLock更灵活支持公平锁、可中断、超时获取、多个Condition条件队列。实际项目中我通常优先用synchronized因为它简单不容易出错只有在需要可中断或超时控制、多个条件队列时才换ReentrantLock。volatile也是一个高频考点。它的核心是保证可见性和有序性但不保证原子性。很多人会混淆volatile和synchronized的职责。面试官如果问“双检锁单例为什么要加volatile”你要能回答出“防止uniqueInstance new Singleton()这一步发生指令重排导致另一个线程拿到未初始化的半成品对象”。这里最好再补一句new对象不是原子操作分为分配内存、初始化对象、设置引用三步JVM可能把第二步和第三步重排所以需要一个内存屏障来禁止重排。线程池相关题目强调实际经验。我给个几乎不会过时的回答模板核心线程数怎么定要看任务类型。CPU密集型任务通常设置为CPU核数1IO密集型任务可以适当调大比如设置了CPU核数两倍甚至更多因为线程在等待IO时CPU可以切换处理其他任务。但现代服务往往是混合型任务更稳妥的办法是压测验证。队列长度也不是越大越好如果队列太长任务积压会带来延迟和内存压力。拒绝策略默认是AbortPolicy直接抛异常但业务上我更喜欢CallerRunsPolicy让提交任务的线程自己执行起到天然降速作用。最后一定记得说出“线程池参数不能拍脑袋定而是根据QPS、响应时间、任务耗时推算再靠压测修正”这句话这能帮你在众多背题者中脱颖而出。1.3 数据一致性从单机事务到分布式解释Java程序员普遍容易在数据一致性上栽跟头尤其是分布式系统经验不多的求职者。面试官经常拿一个最简单的场景切进去“你的微服务订单接口调用库存服务扣减库存网络超时了怎么保证两边数据一致”正确思路是先把问题的边界画清楚。单机环境靠数据库事务的ACID特性具体到隔离级别就要理解MVCC机制。比如MySQL默认的REPEATABLE READ隔离级别下READ VIEW和回滚段配合让普通查询不阻塞写操作。这就是为什么InnoDB同时支持高并发和事务能力的原因。分布式环境下CAP定理和BASE理论是底层判断依据。如果系统要求强一致性可以考虑两阶段提交2PC或者Seata AT模式。Seata AT模式的思路很巧妙它通过全局事务管理器协调分支事务在业务执行前生成“镜像数据”存到undo_log表事务提交前检查数据冲突一旦发现冲突就回滚并恢复镜像数据。但AT模式也有代价需要额外的资源锁定和回滚日志高并发场景下性能会打折扣。如果系统能接受最终一致性我通常会选择基于本地消息表或者MQ事务消息的方案。比如订单创建成功之后写一条“扣减库存”的消息到本地表和订单事务在同一个数据库事务里提交再由一个可靠的消息投递组件把这条消息发送给RocketMQ或Kafka库存服务消费后执行扣减。这种“事务消息幂等消费”的组合是业界最常用的分布式事务替代方案。面试时你先问清楚对方是强一致还是最终一致再选择不同的方案比上来就背Seata高级得多。2. Spring Boot核心机制与实战细节2.1 自动配置与Starter第一个Spring Boot程序背后发生了什么很多初学者从“第一个Spring Boot程序”开始照着一篇教程把spring-boot-starter-web加上写一个RestController然后main方法一跑服务就起来了。但你问他“这个starter到底帮你做了什么”多半答不上来。这就是面试官最爱的切入点。SpringBootApplication是一个组合注解包含SpringBootConfiguration、EnableAutoConfiguration和ComponentScan。其中最关键的是EnableAutoConfiguration它会通过Spring工厂加载机制读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件这个文件里列出了所有自动配置类的全限定名。Spring Boot的自动配置类都会配合一系列条件注解比如ConditionalOnClass判断classpath下有没有指定类ConditionalOnMissingBean判断容器里有没有用户自定义的Bean。所以Spring Boot的“自动配置”本质是“条件化配置”——你要的配置如果是默认的就不用手写一旦你写了自定义Bean框架的自动配置就会自动退让。明白这个关系之后面试里被问到“怎么实现一个自己的Starter”就不会慌写一个XxxAutoConfiguration类加上条件注解在META-INF/spring下配置好导入文件一个Yml配置包含开关属性就完成了一个标准的starter。很多人还分不清Spring、Spring Boot、Spring Cloud这几个词。用一个最容易理解的类比Spring是一个全面的编程和配置模型家族它本身解决的是对象管理问题Spring Boot是对Spring的再封装解决了配置繁琐、依赖冲突、启动部署麻烦的问题像一个傻瓜相机Spring Cloud则是一套分布式系统工具箱服务注册发现、负载均衡、配置中心、网关都从这里面来。面试时如果被问“这三者什么区别”按这个层次去表达基本不会出大问题。2.2 Bean注入与生命周期管理的关键经验Spring核心是IoC和AOP面试必考Bean的生命周期。一个Bean从定义到销毁经历了实例化、属性填充、初始化、使用、销毁几个阶段。在初始化前后Spring会调用BeanPostProcessor的postProcessBeforeInitialization和postProcessAfterInitialization方法AOP代理就是在这时候通过“后置处理器”织入的。所以你可以这么回答Spring的AOP本质是代理对象这个代理不是写死在代码里的而是在Bean初始化阶段通过AbstractAutoProxyCreator动态生成的。注入方式的选择也是大厂面试的隐形考点。构造器注入、Setter注入、字段注入三选一最佳实践是强制依赖用构造器注入可选依赖用Setter。构造器注入的好处是能保证依赖不可变并且容器启动时就能发现循环依赖避免运行时才炸。字段注入虽然写起来最省事但无法在单元测试里直接new一个不依赖Spring的对象而且比较容易违反单一职责。这里要特别说一下循环依赖Spring通过三级缓存解决单例Bean的循环依赖一级缓存放成品二级缓存放早期暴露的引用三级缓存放对象工厂。关键的是构造器注入的循环依赖是解决不了的因为对象还没实例化出来缓存里找不到半成品引用。实际项目里我还遇到过Configuration类被CGLIB代理导致的一些怪问题。比如你把一个普通方法放在配置类里却发现每次调用返回的都不是同一个对象。原因就是Spring把配置类变成了CGLIB子类方法调用会被拦截确保单例Bean的语义。如果你用Bean方法内部去调用另一个Bean方法得到的始终是容器里那个单例。这个细节面试答出来会显得你对Spring机制真的理解到了底层而不是停留在写代码的层面。2.3 缓存与日志Caffeine和Logback现场实战缓存问题几乎每个团队都会遇到。Spring Boot里整合Caffeine非常简洁引入caffeine依赖后通过CacheManager定义一个CaffeineCacheManager再用Cacheable标注方法就行。我实际推荐先写一个Caffeine配置类设置最大容量、过期策略和统计信息收集Configuration public class CacheConfig { Bean public CacheManager cacheManager() { CaffeineCacheManager cacheManager new CaffeineCacheManager(userCache, orderCache); cacheManager.setCaffeine(Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(Duration.ofMinutes(5)) .recordStats()); return cacheManager; } }Caffeine之所以快是因为它内部采用了类似ConcurrentHashMap的数据结构同时结合了Window-TinyLFU淘汰算法能根据访问频率做细粒度冷热数据分离。面试官追问“本地缓存和Redis缓存该如何选择”时我的回答是本地缓存快但数据不共享适合存不常变动的字典数据Redis适合多实例共享的数据。一个成熟系统通常是两级缓存先查本地再查Redis两级都没有才走数据库。缓存经典三大问题——穿透、击穿、雪崩——是面试题库的常客。穿透是查了一个不存在的key请求全部打到数据库解决办法是缓存空值或者用布隆过滤器挡一层。击穿是某个热点key失效时大量请求同时打到数据库解决办法是互斥锁重建缓存。雪崩是大批量key同时过期或Redis宕机导致数据库被压垮解决办法是过期时间加随机值、Redis集群部署、本地缓存兜底。这几个问题我建议你不仅会背还能结合你们的实际监控数据去说比如“我们当时双十一大促前检查缓存过期策略发现一批活动商品key刚好同一刻过期于是把过期时间分散到5到10分钟区间”这种真实场景比定义更有说服力。日志这块容易被忽略但大厂很看重实战能力。Spring Boot默认用的是Logback你要会在application.yml里配置日志级别、文件输出、滚动策略。我习惯再把日志格式改成带traceId的输出配合MDC在入口过滤器里塞一个全局请求ID。这样排查问题时可以按一个请求的完整链路把所有日志捞出来这在微服务环境尤其重要。面试官如果问“日志打太多影响性能怎么办”异步日志、日志采样、按级别拆分文件都是可以考虑的方向优先提异步日志的丢失风险判断会显得你有真实的性能权衡思考。2.4 Spring Boot 3中的Spring Security配置迁移接触过老项目的同学应该都见过WebSecurityConfigurerAdapter。但到了Spring Boot 2.7后这个类被标记废弃Spring Security 5.7之后官方推荐用SecurityFilterChain的Bean声明方式。Spring Boot 3更是全面转向Jakarta EE规范集成方式也以Lambda DSL为主。很多人在这个版本升级上栽过跟头面试里也经常被问“你会不会做Security配置迁移”。老配置通常长这样继承WebSecurityConfigurerAdapter重写configure(HttpSecurity http)然后放开某些路径、关闭CSRF、配置表单登录。新配置则是写一个Bean方法返回SecurityFilterChain并按“先放行再认证”的顺序配置授权规则Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf(csrf - csrf.disable()) .authorizeHttpRequests(auth - auth .requestMatchers(/api/auth/**, /sse/**).permitAll() .anyRequest().authenticated()) .sessionManagement(session - session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .addFilterBefore(jwtAuthFilter, UsernamePasswordAuthenticationFilter.class); return http.build(); }注意三层关键第一新写法里每个配置项都变成了链式Lambda的形式每一段都返回自身继续配置这也是官方推动函数式风格的结果第二JWT认证场景下要设置STATELESS会话策略并注册自定义过滤器去解析Token第三CORS配置不要和Security授权规则搞混跨域放行要在Security的CORS配置里做CorsConfigurationSource的注册否则前端请求会被挡在过滤器链之外。Spring Security的过滤器链执行顺序有一定讲究加过滤器时一般在UsernamePasswordAuthenticationFilter之前做认证逻辑因为顺序错误会导致请求还没走到认证过滤器就被后续的授权规则拦截。我见过不少人在迁移时疯狂爆500错误或403最后排查半天发现是路径匹配方法写错了。新版本里antMatchers已经被requestMatchers替代参数既可以传String模式也可以传RequestMatcher对象。这种“新老API差异”的细节在面试里提到会非常加分。3. 微服务架构拆解逻辑与面试真题剖析3.1 微服务为什么要拆它不是银弹微服务是架构演进的结果不是一件可以“直接引入”的工具。面试官最爱问“你们为什么要把单体拆成微服务”。一个比较有水平的回答是单体应用在团队规模小、业务简单时交付效率最高但当团队扩展到几十人、业务模块之间的耦合越来越严重时每次发布都要全量回归单点故障范围大这时候才需要考虑按业务边界拆分。拆分最重要的依据不是技术而是组织。康威定律说“系统架构等同于组织沟通结构”你让两个团队共同维护一个用户服务它们迟早会忍受不了。更常用的做法是参考DDD的限界上下文把订单、商品、库存、支付这些业务能力划分成独立的域。以商城系统举例订单服务和库存服务必须分开因为它们的业务变化频率和团队归属完全不同。但拆分完不是结束你还要想清楚它们之间的数据一致性、故障隔离、监控运维怎么协作。这里有一个高频追问“拆分之后有哪些坑”。你可以大胆踩坑后再分享跨服务调用链路变长任何一个服务抖动都会放大延迟数据一致性更难保证部署数量和资源消耗急剧增加日志和监控需要统一平台联调成本变高尤其在Java和Go这种跨语言团队之间。把这些问题抛出来才是面试官想看到的真实架构思考而不是“微服务就是好”的片面答案。3.2 服务通信与联调OpenFeign、gRPC与WebSocket微服务之间的通信方式主要有两类同步RPC和异步消息。OpenFeign属于同步HTTP调用使用起来很简单声明一个接口、配上注解就能像调本地方法一样调远程服务。但不要轻视Feign的细节超时时间要单独配置因为Ribbon默认超时很短日志级别要设置成FULL才能在联调时看到请求和响应接口调用失败时要配合降级类返回兜底数据。联调跨语言团队时gRPC往往比HTTP更合适。gRPC基于HTTP/2支持长连接、多路复用默认使用Protobuf二进制序列化性能高出JSON不少。Java与Go服务通过protobuf定义好.proto文件后两端各自生成代码接口契约清晰且不易偏题。面试官如果问“什么时候用Feign什么时候用gRPC”最佳回答是团队内部、对性能敏感的场景优先gRPC比如实时推送、视频处理服务之间的调用对外部系统、浏览器端、移动端HTTP/JSON依然是最通用的选择。WebSocket在Spring Boot里集成也很常见主要用于实时双向通信比如聊天、在线协作、消息推送。yml配置主要涉及STOMP端点注册和Broker配置spring: websocket: broker: relay: enabled: false不过更规范的方式是通过Java配置类EnableWebSocketMessageBroker注册/ws端点并配置/topic和/queue前缀。面试被问到“SSE和WebSocket怎么选”时你可以从语义上区分WebSocket是全双工双向通信SSE是单向服务端推送如果只是服务端把数据推给客户端SSE够用且实现简单需要客户端持续向服务端发消息的场景比如在线聊天室再考虑WebSocket。3.3 微服务架构图与开源项目的落地参考“画一张微服务架构图”是高频面试题。一个比较完整的架构图至少包含几个层次的组件最外层是API网关比如Spring Cloud Gateway往下是业务服务层再往基础设施层看注册中心用Nacos或Consul配置中心统管各环境配置熔断降级组件用Sentinel或Resilience4j链路追踪用Micrometer Tracing或Sleuth消息队列用RocketMQ或Kafka缓存用Redis集群。面试时画图不用追求组件数量多重点是能说清每个组件解决什么问题、它们之间的流量路径是怎样的。如果你想动手参考一个现成的开源微服务项目若依微服务版本RuoYi-Cloud是个不错的起点。它有网关、系统服务、认证服务、监控服务用了Nacos、Sentinel、Spring Security、Redis这些主流组件。看这类项目时不要只盯着代码你重点要关注的是数据权限如何设计、Token如何校验、服务间调用如何鉴权、异常如何统一处理、分布式事务和幂等怎么做。把这些模块串成自己的理解面试时才能讲出“这个项目的架构是为什么这样设计”而不只是“我照着一个开源项目改造过”。3.4 分布式事务Seata之外还有哪些解法分布式事务不是只有Seata一个答案。正常面试节奏我会先说Seata的几种模式AT模式无侵入适合大多数场景TCC模式需要你实现Try、Confirm、Cancel三组接口灵活但编码复杂Saga模式强调正向下发和逆向补偿适合长流程事务。然后我一定会说“Seata不是银弹”尤其高并发场景下AT模式全局锁容易成为瓶颈TCC需要抗住接口幂等和空回滚问题。更常用、更简便的是“本地消息表消息队列”的方案。订单服务和库存服务不需要实时强一致只要保证最终库存扣减成功即可。订单写入后在同一数据库事务里写入一条待发送消息定时任务扫表投递MQ库存服务消费后做幂等更新。这种方案的优点是简单、可控缺点是需要额外维护一张消息表和一套投递程序。如果追求更轻量还可以考虑“事务消息”用RocketMQ直接支持事务消息的发送和回查本地事务提交后消息才可见。面试讲到“你怎么保证数据一致性”时能够先区分业务对实时性和一致性的容忍度再给出对应的方案组合就已经达到高级岗位的回答标准了。4. AI技术栈Java服务如何接入大模型能力4.1 技术栈选型Spring AI还是自研封装最近两年大模型应用突飞猛进Java后端必然要面对“如何把大模型能力封装到自己的服务里”。面试官问这个问题的时候一是想看你对新技术的敏感度二是在考察你设计一个可复用模块的架构能力。一个比较粗暴但有效的最简方案是直接用HttpClient调用大模型API把Prompt、温度、最大Token等参数封装成工具类。但项目一复杂这种方案就不够看多个模型供应商切换、API Key管理、Token消耗统计、错误重试、流式输出处理全都要自己实现。用Spring AI可以省去很多重复劳动它提供了ChatClient接口、Prompt模板、输出解析、模型切换能力底层还封装了流式调用。类似地LangChain4j也值得了解它把Prompt模板、记忆管理、工具调用这些能力集成到了Java生态。实际项目中“AI交互逻辑”应该是一个独立的模块而不要散落在业务代码里。我一般会把它做成一个AiGateway接口屏蔽底层模型差异。上层业务只需要传入用户消息、上下文和业务类型返回一个统一的响应对象或流式事件流。内部的模型路由可以根据业务场景选择不同模型比如客服问答走意图识别模型内容生成走长文模型同时记录每个请求的Token消耗用于成本核算。模块一旦抽好了后续换模型、加模型都只是在网关实现里加一段配置的事业务层完全不用动。餐饮SaaS接AI就是一个典型的案例客户想通过自然语言查询报表或者让AI根据销售数据生成经营建议。如果用最土的方式写代码业务逻辑会迅速肿胀但如果你设计一个“意图识别–插件调用–流式渲染”的管道后续加新能力只需要扩展插件而不用改主链路这个设计思路本身就很适合在面试里作为亮点讲出来。4.2 SSE流式输出大模型回答实时渲染的关键大模型响应动辄几百上千字如果等全部生成完再返回用户会对着一个转圈白屏等十几秒。现在主流方案是SSEServer-Sent Events服务端把Token分批推送给前端浏览器像打字机一样逐字渲染。Java后端实现SSE常用两种方式Spring MVC的SseEmitter和Spring WebFlux的FluxServerSentEvent。业内很多AI应用走的是WebFlux方式因为大模型输出本质是异步流式数据和Reactive模型天然匹配。一个典型的实现如下GetMapping(value /api/chat/stream, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxServerSentEventString streamChat(RequestParam String message) { return chatService.streamReply(message) .map(token - ServerSentEvent.builder(token) .event(message) .build()); }前端通过EventSource接口接收即可但注意EventSource默认只能GET请求。如果你需要POST且要带请求体建议用fetch加ReadableStream去读取响应流每次拿到一个数据块就解析并渲染到页面。SSE和普通的HTTP接口不同连接是长驻的所以服务端要处理超时和断连问题。SseEmitter默认超时是30秒如果大模型生成时间较长需要显式设置更长的超时时间或者把它放到一个线程池里管理。心跳机制也值得设计定期发送注释行保持连接活跃避免中间代理掐断空闲连接。断连后前端要能自动重连并判断是否需要重新发起请求。4.3 abort中断前端中断时后端如何优雅收尾流式输出里最容易踩坑的是“用户中途点了停止”。如果前端主动关闭连接后端还傻乎乎地一直把Token发给一个已经不存在的连接不仅浪费算力还会导致服务端的线程和内存资源被长时间占用。这里的核心是abort机制正确落地。前端可以用AbortController发起fetch请求停止时调用abort()方法。这会触发浏览器断开底层TCP连接服务端在写入SseEmitter时会抛出IOException。所以后端一定要监听onCompletion和onTimeout回调在回调里及时释放线程池、关闭相关资源。如果你用的是FluxServerSentEvent配合doOnCancel做资源释放就能优雅终止生成。注意“终止生成”不只是后端不发了如果大模型服务还在继续生成最好把“用户中途停止”的信号同步给模型服务让上游也停止生成才能真正省钱省资源。同时要把“客户端断开”和“网络异常断开”区分开。前者主动取消后端可以立刻收尾后者属于被动断开服务端往往只能通过心跳超时检测。我的做法是维护一个连接管理器定期检查SSE连接的心跳状态超过阈值就执行强制回收。这一套逻辑完全可以做成通用组件多个业务场景复用。如果你能把这个过程完整讲清楚面试官会认为你确实做过生产级AI功能而不仅仅是跑通了一个demo。5. 面试实战高频追问与避坑记录5.1 高频追问Top5及答题思路结合我自己面试和被面的经历有几个问题是反复出现的值得先把回答“固化”下来。第一个问题“你项目里最难点是什么”别回答“我都做得挺顺的”。你可以选定一个技术难度适中的场景例如“我负责的AI报表模块需要把大模型的流式输出实时渲染到网页同时要支持用户随时中断请求”然后按“背景–设计–实现–结果”把整个链路讲出来尤其要强调你是怎么解决abort后的资源回收问题的。第二个问题“微服务之间调用超时怎么处理”回答三个层面设置合理的超时时间和重试次数用Sentinel或Resilience4j做熔断降级让故障服务快速失败而不是拖垮调用方兜底策略返回默认值或缓存数据并对调用结果做兜底记录。最好再提一句“要区分超时和失败超时可能导致请求已经成功处理这时候重试必须配合幂等设计”。第三个问题“你怎么保证数据一致性”不要一上来就上Seata而是先给结论“如果是最终一致性场景并发量高我用本地消息表MQ如果场景必须强一致再考虑Seata AT”。面试官会顺着问“为什么不用TCC”这时候你再展开TCC的编码复杂度和空回滚问题证明你真的做过取舍。第四个问题“线程池参数怎么定”上面已经给过模板这里强调一点别只说理论数值要用你自己的业务做过估算。比如订单下单接口QPS是200接口平均耗时50毫秒单个处理线程在高峰期约能处理20个请求每秒那线程数至少10个再留一定缓冲并配合压测结果调整这就是有数据支撑的回答。第五个问题“SSE和WebSocket怎么选”SSE适合服务端单向推送协议更轻、自动重连更容易WebSocket适合全双工场景但客户端逻辑和连接管理成本更高。再加一句实际经验大模型流式输出优先SSE因为你的需求是“服务器一直往浏览器推”而不是“浏览器和服务器互聊”。5.2 联手实战排查微服务和AI场景的典型故障面试后的技术面也会以简历项目为引子让你说说排障经验。我可以分享几个真实案例。某次线上商城服务出现偶发超时排查链路后发现是一个定时任务批量刷缓存触发了Redis热key的缓存击穿请求大量穿透到数据库。修复方案是把过期时间打散并加了本地Caffeine缓存兜底效果非常明显。这是我前面讲的缓存击穿方案的真实验证。还有一次微服务间调用失败不是代码问题而是Nacos注册的服务IP是内网地址跨机房访问不通。最后在服务配置里强制指定注册IP并调整网络策略解决。这类低级问题在大厂面试里也常被拿来当作场景题你可以自信地说“我遇到过”。AI场景的坑也不少。一开始我做的SSE接口没有设置心跳前端每隔一段时间就会自动重连一次用户体验很差。后来前端欢迎页面启动了一个重连机制但只要服务端持续发数据连接就不会断。于是我在服务端加了一个定时任务每15秒发一个注释行立刻解决了问题。还有个常见的坑是abort后没有通知模型服务用户中断后成本依然在计费。后来在网关里统一把取消信号转发给底层模型调用才把这个窟窿堵上。5.3 准备建议与个人体会最后聊点准备上的实操经验。我觉得最有效的复习方式是“把项目里的每一个技术决策都反向问自己三遍为什么”。比如你们用了Caffeine你就问自己为什么不用Redis用了Feign为什么不用RestTemplate用了SSE为什么不用轮询把这些“为什么”答清楚了面试时候就不怕追问。另外强烈建议所有准备Java后端面试的人亲手去写一个小项目把Spring Boot、WebSocket、SSE、大模型调用、abort中断、Redis缓存这几件事串起来。哪怕只是一个AI问答助手页面你也会实实在在体会到连接管理、线程池资源释放、Token解析这些书上写不到的问题。面试时你能讲出“我当时处理了一个什么问题后来怎么定位的”比你背一百道八股都有说服力。大厂面试越来越看重“链路思维”。不再问单一知识点而是问一个请求从浏览器到大模型再到渲染的全过程。我自己的体会是把Java基础、Spring Boot、微服务、AI技术几条线串起来理解遇到未知问题能迅速在脑海里画出一张调用链路图再顺着链路去排查和设计这种能力才是技术面试里真正稀缺的。准备面试的过程辛苦但当你把这条链路彻底弄懂之后你会发现面试题其实就那么几种变形。记住面试是技术债的回报你现在偷的每一项懒都会在面试官追问时变成挡在你面前的坑。
