大厂Java面试考察新趋势：技术栈广度与业务场景拆解实战

金三银四又到了，群里讨论Java面试的频率明显高了起来。前两天有位读者把一份面试复盘发给我，内容很典型：技术栈写了一大串，八股文背得滚瓜烂熟，但面试官往业务场景上一追问，整个节奏就乱了。他问我，大厂Java面试到底在考什么？技术栈究竟要怎么展示才不吃亏？这个问题其实值得展开聊聊——尤其这两年AI应用、流式输出、Agent开发这些概念进入面试题之后，Java求职者的考察维度已经悄悄变了。这篇文章就结合我这些年面试别人和被别人面试的经验，把技术栈和业务场景这两条线串起来讲透。

1. 大厂Java面试的底层逻辑：技术栈广度只是门票，场景拆解才是分水岭

1.1 面试官为什么越来越不爱听八股文

先说一个明显的变化。五年前面Java岗位，面试官问“HashMap的原理是什么”“ConcurrentHashMap的分段锁是怎么回事”，你能把源码关键行背出来，基本就能拿加分。但这两年再这么面，面试官很快就转去问“你项目里哪个地方真的用到了这些机制”。八股文没有失去价值，它变成了一种默认的入场券——相当于问你“你确实是干Java的”，而真正的淘汰点已经转移到了业务场景的拆解能力上。

我身边不少朋友在参与校招面试，聊下来发现一个共识：候选人简历上写着“熟悉Redis、熟悉MQ、熟悉微服务”，面试官一般会随便挑一个点确认一下基础是否属实，这只能算摸底。真正拉开差距的，是接下来那句“你线上遇到过什么问题、当时怎么定位的、为什么选这种方案而不是另一种”。这背后考察的不是记忆，而是三个能力：对技术边界是否清楚、对业务约束是否敏感、对取舍是否果断。

所以准备大厂Java面试，不要再用“背完所有知识点”的思路去堆。更合理的方式是，把每一条技术栈都放到一个具体场景里去准备。技术栈是动词不是名词——它要能在某个业务问题上“动起来”，面试官才会觉得你是真用过，而不是刷过。

1.2 一道业务场景题的标准作答路径

我见过太多候选人在面试官抛出场景题后的第一反应是“这个我没做过”。实际上，大厂面试官并不指望你做过一模一样的业务，他要看的是你的拆分思路。举个例子，面试官问“订单提交接口高峰期经常超时，你怎么处理”，一个合格的作答路径应该是这样的。

第一步，先定边界。接口超时是发生在数据库、Redis、外部调用还是CPU密集计算？不同的瓶颈对应的解法完全不一样。第二步，再谈策略。数据库慢就查索引、慢SQL、连接池配置；外部调用慢就引入超时、熔断、异步化；如果是热点数据竞争，就考虑缓存、队列削峰。第三步，主动说出取舍。比如缓存和数据库的一致性怎么保证，削峰之后订单状态如何闭环。这三步走下来，即使你没有实际优化过这个接口，面试官也能看到你的思路是完整的。

这里我特别想强调一个细节：不要一上来就丢结论。有人一听到超时就说“加缓存”“上MQ”，这其实是把解决方案当成了思考过程。更好的开头是“我需要先确认瓶颈在哪一层”，这句话听起来在反问，但恰恰是业务负责人和资深开发最常说的。大厂面试本质上是模拟协作，你愿意先搜集信息再给方案，比直接拍一个看似正确的答案要加分得多。

2. AI交互逻辑封装与SSE流式输出：近两年Java面试的新增高频考点

2.1 SSE为什么是大模型实时渲染的首选通道

这两年只要做过一点AI应用，面试被问到“基于什么技术栈封装AI交互逻辑”的概率极高。大模型问答的实时渲染，背后核心就是SSE流式输出。SSE全称Server-Sent Events，很多人第一次听会以为它是WebSocket的替代品，其实两者的定位完全不同。WebSocket是双向全双工，适合聊天、游戏这类客户端和服务端频繁互相推送的场景；SSE是单向的，服务端往客户端推，客户端用EventSource或者fetch的ReadableStream读就行。

为什么大模型回答普遍用SSE而不是WebSocket？原因很朴素：一问一答的模式下，客户端只需发一次请求，剩下的全是服务端持续往外吐数据，SSE基于普通HTTP就能跑，天然支持断线重连，服务端实现也简单——响应头加上Content-Type: text/event-stream，按data:格式逐条输出，最后空一行结束一个事件。相比WebSocket要升级协议、要维护长连接状态，SSE在这种场景下成本低太多了。

2.2 用SseEmitter封装大模型交互的核心实现

Java后端做SSE，Spring MVC里最常用的类是SseEmitter，用法不复杂，但有几个坑我在实际项目里都踩过。先看一段核心代码。

@RestController public class ChatController { private final CopyOnWriteArrayList<SseEmitter> emitters = new CopyOnWriteArrayList<>(); @PostMapping("/chat/completions") public SseEmitter chat(@RequestBody ChatRequest request) { SseEmitter emitter = new SseEmitter(180_000L); emitter.onCompletion(() -> emitters.remove(emitter)); emitter.onTimeout(() -> emitters.remove(emitter)); emitters.add(emitter); CompletableFuture.runAsync(() -> { try { // 调用大模型SDK，拿到流式结果 llmClient.streamChat(request.getMessages()) .forEach(chunk -> { try { emitter.send(SseEmitter.event() .name("message") .data(chunk)); } catch (IOException e) { throw new UncheckedIOException(e); } }); emitter.send(SseEmitter.event().name("done").data("")); emitter.complete(); } catch (Exception e) { emitter.completeWithError(e); } }); return emitter; } }

这段代码有四个细节值得注意。第一，SseEmitter的构造参数是超时时间，大模型生成几千字可能要一两分钟，超时时间设太短，回答才生成一半连接就被服务端断了，体验非常糟糕，我一般设180秒起步。第二，onCompletion和onTimeout里必须清理emitter，不清理会发生连接泄漏，时间一长应用就出问题。第三，流的终止要明确，complete()之后客户端才能收到正常结束信号。第四，大模型SDK返回的流式对象本身要拉取完，不能边拉边忘，中间有异常要completeWithError，否则客户端会一直挂起直到超时。

2.3 abort取消与连接兜底：最容易暴露水平的细节

客户端那边也有对应的坑。浏览器原生的EventSource只支持GET请求，而大模型接口通常需要POST请求带大段消息体，所以实际项目里一般用fetch配合ReadableStream来解析SSE。这时候“abort”就变成一个高频考点——用户问了一半不想等了，点了个停止生成按钮，这时候发生了什么？

前端要做的很简单：创建AbortController，把signal传给fetch，点击停止时调用controller.abort()。

const controller = new AbortController(); const response = await fetch('/chat/completions', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ messages: currentMessages }), signal: controller.signal }); const reader = response.body.getReader(); while (true) { const { done, value } = await reader.read(); if (done) break; // 解析SSE帧，逐段追加到页面 }

而后端如何感知客户端abort？这里我要重点说：客户端断开后，服务端的onCompletion会被触发，但如果你在业务线程里还继续调大模型接口，资源就白白浪费了。面试中能答到这一步，说明你真正处理过断连。我的建议是，大模型调用这一层要设计成可中断的——SDK调用时传入一个CancellationToken，abort之后主动取消上游流；同时把emitter回调里做资源释放的部分写健壮，保证断连后服务端不会再往一个不存在的连接上写数据。能讲清这条链路，面试官基本会认可你的实战经验。

2.4 Java生态里Agent开发的技术栈选择

“Agent开发需要哪些技术栈”是最近被问爆的问题。很多人一听Agent就默认是Python的领域，但其实Java侧能做的事也很多。Agent的本质，是让大模型会使用工具、能自主规划并执行任务。落到Java技术栈上，核心有两个方向：一是直接用Spring AI这类框架，它把Model、Prompt、ChatMemory这些概念都封装好了，接OpenAI或国内模型都有一套成熟的API；二是LangChain4j，它在Java里的定位类似于Python的LangChain，对开发者来说上手难度不大，和Spring Boot整合也很顺。

在真正的Agent服务里，除了模型调用，还缺不了几个周边组件：向量数据库用来做知识检索，常见选型是Milvus、Chroma或者直接用数据库的vector类型；Embedding服务负责把文本向量化；函数调用（Function Calling）让模型能触发Java方法去查询订单、写工单。面试时如果你能说出来“Agent不是一个人脸聊天框，它的核心是让大模型能编排工具”，这就比单纯报框架名高出许多。

3. 数据一致性、行级权限与报表导出：数据库方向的面试深挖

3.1 数据一致性：面试官要的不只是“加事务”

“Java怎么保证数据一致性”几乎是必问题，但很多人的回答停留在“加@Transactional”上。这个回答不是错，而是不够——面试官真正希望听到的是：你在什么业务场景下遇到了不一致，选了什么方案，为什么是这个方案。我把常见的几种做法整理成下面这张表。

我个人最推崇的做法是优先把一致性尽可能收拢到本地事务里——能一个服务解决的事，就不要拆成跨服务。只有在业务边界真的需要拆开时，才引入可靠消息。比如下单场景，订单创建在自己的库，库存扣减在库存服务，正确做法不是用强一致的分布式事务去锁住两边，而是订单落库后发一条半事务消息，库存服务消费成功后提交消息，失败则重试，配合对账任务兜底。

3.2 行级权限的Java落地：注解、拦截器与SQL改写

行级权限是报表系统、财务系统、银行驻场开发里几乎绕不开的需求。简单说就是：同一张统计表，部门经理只能看到本部门数据，省级管理员能看到全省数据。Java这边落地行级权限的常见方案有三种。

第一种，最原始但最直观：业务代码里每个查询手动拼where dept_id in (...)。好处是逻辑透明，坏处是容易漏，十个查询漏一个就出生产事故。第二种，MyBatis拦截器统一改写SQL。通过拦截Executor.query方法，动态分析MappedStatement，取出当前用户上下文里的数据权限范围，把where条件自动拼进去。好处是改一处，全项目生效；坏处是改SQL本身有风险，改写前要仔细分析SQL结构。第三种，数据权限注解加SpEL表达式，把权限规则写在注解里，通过AOP在DAO调用前解析并注入参数。这种方式灵活，但规则复杂时容易把注解写飞。

我做过一个项目，用的就是MyBatis拦截器方案，核心思想是：拦截查询，取到当前用户的机构层级，然后区分三种情况——查全部、查本机构、查本部门，动态拼条件。这里有几个细节必须处理好：拦截的MappedStatement要判断是不是SELECT，否则不能改；SQL里如果有子查询或者JOIN，拼接条件时要注意表别名归属；拦截器只处理白名单里的Mapper，其他人想关掉这个权限控制也有一条默认策略。做完之后，新来的同事写Mapper都不用关心权限过滤，这一层被完全透明掉了，审计起来也方便。

3.3 报表导出与POI的图表问题

经常有人问“java poi word能生成图表吗”，我先给个明确结论：纯POI操作Word文档，本身不直接生成图表数据，你用XWPFChart能创建的图表类型也有限，而且和Excel里的图表能力差很多。实际项目里做Word带图表，更常见的做法是两种：一种是先手工做一份Word模板，把图表位置留成占位图片，后端用模板引擎渲染文字内容，再把动态生成的图表图片替换进去；另一种是数据量不大的场景，直接用JasperReports这类报表引擎，它天然带图表渲染能力。至于Excel，POI的XSSFChart能做基础的柱状图、折线图、饼图，但也只适合轻量场景，复杂图表不如导出原始数据到Excel后交给前端ECharts去画。

如果是大数据量报表导出，问题就来到另一个层面：几十万行数据直接写Excel，内存会爆。解决办法是改用SXSSFWorkbook，它基于滑动窗口机制，只保留最近N行在内存里，其余行直接刷到磁盘临时文件。用了它之后，我用POI导出过几十万行的报表，内存很稳定。面试中聊到报表这块，能把“数据量大时该选SXSSF而不是XSSF，还要配合分批查询写文件，最后做流式下载”这条链路说顺，就比只报一个POI名字立体很多。

4. AQS、动态代理与并发模型：并发编程怎么答才不像背书

4.1 AQS的完整链路：从state到CLH唤醒

aqs java这个关键词在搜索榜上居高不下，面试官爱问AQS，本质上是想知道你对并发底层有没有敬畏。AQS的完整工作链路，用一句话概括就是：用volatile的state变量记录锁状态，抢不到锁的线程封装成Node排进一个双向队列，前驱释放锁后通过LockSupport唤醒后继。这个机制设计的精髓在于模板方法模式——AQS的骨架定死了，谁能抢锁、抢不到怎么办、唤醒谁，都预先定义好，子类只需要实现tryAcquire、tryRelease、tryAcquireShared这几个方法。

面试官如果让你对比ReentrantLock的公平锁和非公平锁，答案不在背上，而在差异点上：非公平锁在获取锁时先直接CAS抢一次，抢不到才走队列排队，所以新来的线程可能插队，导致队列里等待的线程晚一步拿到锁；公平锁则是“先来先服务”，队列里谁排头谁拿。这两种策略没有绝对的优劣，非公平锁的吞吐量通常更高，公平锁更不容易饿死线程。答到这里，面试官就认为你是真理解，而不是只用“公平锁就是按顺序排队”一句话应付。

4.2 InvocationHandler与代理思维

java invocationhandler()是另一个高频考点。JDK动态代理的入口是Proxy.newProxyInstance，它要求目标对象必须有接口，运行时生成一个实现同样接口的代理类，所有方法调用都会进入InvocationHandler.invoke方法。Java面试里问这个，往往是为了考Spring AOP和MyBatis的底层机制。

我自己面试时经常用MyBatis来投射这个问题：Mapper为什么只定义接口就能执行SQL？因为MyBatis在启动时通过MapperProxy这个InvocationHandler为每个Mapper接口生成代理，当调用userMapper.selectById(1)时，实际进到了invoke方法里，它根据当前方法名找到对应的MappedStatement，再交给SqlSession去执行SQL。理解了这条链路，你就明白了为什么Mapper接口不能有重载同名方法、为什么方法签名要和XML里的id对应上。

4.3 并发场景的容器选择：从HashMap到ConcurrentHashMap

Java容器这块，面试喜欢从HashMap一路问下去。HashMap在JDK 8之后的改进点很清晰：数组加链表，链表长度超过8且数组长度大于64时转红黑树，目的是把最坏情况的查询从O(n)降到O(log n)。HashMap在多线程并发写时可能丢数据，甚至形成环导致死循环——虽然JDK 8之后头插改尾插，环的问题不太出现了，但并发写的线程安全性依然没有保证。于是就有了ConcurrentHashMap的分段演进：JDK 7是分段锁，多个Segment之间有独立的锁；JDK 8之后改用CAS加synchronized锁住链表头节点，锁的粒度更细。答并发容器时，把自己的思路放在“为什么锁要越分越细”这条主线上，会让整个陈述有逻辑，而不是知识点一个接一个往外蹦。

5. Java基础层容易被翻车的细节：switch空数据、编译告警与深拷贝

5.1 switch传null直接NPE

很多看起来基础的东西，实战里真能翻车。比如switch(null)，看起来没什么问题，运行时直接抛NullPointerException——switch语句的表达式求值后，如果值是null，再到case里去匹配，这个匹配过程需要调用hashCode或者equals，null根本走不了这步。所以处理可空字段的switch之前，一定要先判空。JDK 21的switch模式匹配可以显式写case null，但在很多公司的项目还没升级到JDK 21，兼容写法依然是先判空再进switch。这种细节面试时不会单独问，但写代码的习惯里能看出来，面试官看你的代码风格干净不干净，往往就看这种地方。

5.2 源发行版17需要目标发行版17这类告警怎么治本

“java: 警告: 源发行版 17 需要目标发行版 17”这个编译告警，后台开发大概率都见过。它的产生原因是Maven或IDE里source和target的值不一致：source指定了17，但target没有同步指定，于是编译时产生了这个警告。这个警告看着人畜无害，但实际生产项目里我遇到过更严重的情况——source设成17，target设成8，代码用着新的语法，编译出来的字节码版本却是8，部署到旧JDK环境的机器上直接报UnsupportedClassVersionError。治本的办法是用<release>17</release>，这个参数会同时约束source、target和JDK API签名，从根上避免“目标版本低但API用新”的问题。

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <release>17</release> </configuration> </plugin>

如果你在用IDEA，还要检查两个地方：Project Structure里的SDK版本，以及Settings -> Build Tools -> Maven -> Importing里的JDK for importer。这两个不一致的话，Maven命令行的编译设置和IDE内置编译经常会各跑各的。

5.3 StringBuilder、深拷贝与跨领域联动

StringBuilder这个点看似基础，其实能扩展出不少内容。字符串拼接在循环里不要用“+”号，每拼一次就会创建新的String对象，循环几百上千次就会产生大量垃圾对象。用StringBuilder是常规答案，但高级一点的回答是：Java 9之后字符串拼接已经在编译期优化成invokedynamic，常量折叠会做，循环里依然会生成新对象，所以“循环外可用+，循环内建议用StringBuilder”这个区分，本质上是对对象分配数量和GC压力的理解。StringBuilder线程不安全，多线程拼字符串要用StringBuffer，这句话背出来容易，能解释清楚为什么StringBuffer更安全是因为它的方法加了synchronized，才算过。

对象深拷贝也是一道常考题。浅拷贝只复制引用，两个对象共享内部数组，改一个另一个也会变；深拷贝要连内部的引用对象一起复制。Java里实现深拷贝的常用方式有四种：重写clone方法但需要自己处理所有引用类型、通过Serializable序列化再反序列化、通过JSON序列化（比如Gson/Fastjson）复制、手动get/set写的构造方法。我实际项目里最常用的是构造方法方式，因为JSON方式虽然写起来少，但性能损耗大，偶尔还会因为某些字段类型无法序列化而翻车；用构造方法虽然多写几行，但类型安全和性能都可控，而且将来字段增加时IDE会直接提醒你哪里没改完。

有时候Java面试还会蹦出一些跨领域的协同问题，比如有人会聊到“java与stm32f”这种物联网场景。这种话题不一定出现在Java技术栈的常规面上，但如果你简历里写过IoT项目，面试官会问的其实是：服务端怎么接收设备上报的数据、用什么协议、怎么处理海量连接。Netty在这类场景几乎是标配，核心是它的Reactor线程模型和ByteBuf的内存管理。如果你没有接触过硬件开发的业务，完全不必勉强拓展；有的话，把Java服务端和硬件设备的数据链路讲清楚，反而是一个很好的差异化谈资。

6. 技术栈叙事与学习路线：把简历变成面试官追问的地图

6.1 简历里的Java技术栈怎么写

简历的技术栈部分，我见过最可惜的写法是“精通Java、熟练Spring、熟悉Redis、了解Kafka”这种程度词清单。招聘方关心的是匹配度，不是词汇量的丰富度。更有效的写法，是用“技术栈+场景+手段”的方式呈现：比如“基于Spring Boot搭建订单中台，通过Redis分布式锁解决多实例下优惠券领取的并发问题，用RocketMQ事务消息保证下单与扣库存的最终一致性”。这样写，每一个技术点背后都挂着一个真实场景，面试官追问时也有抓手。要注意，简历上写的每一条都要能扛住连续三个追问；扛不住的宁可别写，写了等于给面试官递刀。

6.2 兼顾面试与落地能力的Java学习路线

关于Java学习路线，网上的图已经很多了，我的建议是不要照单全收，按“能用、够深、分层”三个标准来定。基础层是Java SE的核心：集合、并发、JVM、IO，这些决定你的下限。框架层是Spring Boot、Spring Cloud、MyBatis的源码阅读能力，重点不在背Bean生命周期，而在理解自动装配和AOP如何改变你的编程方式。中间件层是Redis、MQ、MySQL的实战场景与底层机制，比如Redis的过期策略、MQ的消费幂等、MySQL的索引失效条件。再加一层就是这两年最热的AI应用集成和流式交互。学习顺序上，我建议项目驱动为主，八股文为辅：先用Spring Boot把增删改查跑通，再逐个引入Redis、MQ、分库分表，每引一个就踩一遍它特有的坑，踩坑之后的总结才是面试中最有价值的素材。

6.3 面试复盘的正确姿势

最后说说复盘。面试完别急着刷下一家，先花半小时把整场流程默写下来，哪道题没答上、哪个追问卡住了、面试官对哪个答案明显感兴趣，全记下来。我个人的习惯是准备一个“错题本”，每道题记录三层：表层问题是什么、关联的知识点有哪些、如果下一次被问到，怎么组织答案才能讲出场景感。比如“SSE超时时间设多少”这个问题，记录的答案不只是一个数值，而是“长文本生成场景需要180秒，心跳要单独处理，客户端abort后服务端如何释放”这样一组完整信息。三轮面试之后，对比错题本的变化，你会发现自己在答“为什么选这个方案”这类问题时，明显会比第一轮从容很多。

技术栈不会因为你背得多就变深，真正的深度来自于你在真实业务里做出过的每一个取舍。就像SSE流式输出的连接管理，AQS的排队唤醒，行级权限的SQL改写，这些都是同一件事的不同侧面：理解约束，然后在约束下做最合理的选择。下次面试若被问到“你这个项目里最复杂的点是什么”，不妨试试把当年踩坑、排查、选型的完整过程讲出来——那才是面试官最想听到的东西。