半泽和莉娜1. 谢飞机走进面试间：这场闹剧从一句“我熟”开始
事情是这样的，一位朋友所在的部门要招Java开发，简历筛选时看到一份特别有意思的简历——工作年限写的是“两年半”，项目经验栏写“熟悉Spring Boot、了解微服务”，技能特长是“熟练使用Ctrl+C和Ctrl+V”。更有意思的是，这位应聘者叫谢飞机。人事把简历转过来时，部门主管看了半天，说了句“让他来试试吧，万一是个被埋没的人才呢”。
面试当天，谢飞机穿着格子衫，背着一个看起来装了三年笔记本的双肩包，精神抖擞地坐进了面试间。面试官是部门里干了八年Java的老王，一开口就是典型的“压力面”开场：“谢飞机是吧，先做个自我介绍吧。”
谢飞机清了清嗓子：“我叫谢飞机，毕业两年半，主要做Java后端开发。用过的框架主要有Spring Boot、Spring Cloud，写过微服务，也处理过高并发。面试官你看我简历上的照片，是我本人，没有美颜。”
老王点了点头，心想还行，至少不怯场。但接下来发生的事，逐渐脱离了正常面试的轨道。
这场面试从Spring Boot的自动装配机制问到Redis Stream消息队列，从服务拆分原则问到分布式事务，中间穿插着各种啼笑皆非的回答，但也不乏一些让人眼前一亮的操作。我后来把整场面试的录音和笔记整理了一遍，发现这其实是一个非常典型的Java面试样本——既有“八股文”式的标准问题，也有实战中的关键细节，还有不少面试官自己都容易忽略的坑。
这篇文章我就以这场面试为主线，把里面涉及的重要知识点和实际工程中的对应场景都拆开聊一聊。搞笑的对话只是一个引子，真正有价值的是背后的技术逻辑。不管你是正准备Java面试，还是已经在写Spring Boot项目，都可以对照着查漏补缺。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 第一轮交锋：Spring Boot自动装配，谢飞机差点把“Starter”说成“Start”
老王先从基础题切入：“你说你熟悉Spring Boot，那我问你，Spring Boot的自动装配是怎么实现的？为什么我们引入一个starter依赖，就能直接用对应的功能？”
谢飞机沉默了两秒，表情像是CPU在高速运转，然后说：“自动装配嘛，就是Spring Boot帮我们把Bean都创建好，我们直接用就行了。至于原理……就是……自动装配……嗯……它自动了。”
老王脸上写满了“果然如此”的表情。但谢飞机接下来的一句话，让老王有点意外：“面试官，我虽然说不清原理，但我调过很多启动报错，比如NoSuchBeanDefinitionException，这个我太熟了，因为我们的项目里经常有人把starter引错了版本。”
这句话救了他。老王顺着说：“那好，我们不背书，就聊实际。你说你处理过启动报错，那你说说Spring Boot自动装配的核心注解是什么？它底层是怎么扫描到那些配置类的？”
谢飞机这次认真想了想，给出了一个勉强及格但亮点在后面的回答：“核心是@EnableAutoConfiguration，底层通过@Import(AutoConfigurationImportSelector.class)，这个类会去读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件，把里面列出的所有自动配置类注册进来。然后每个自动配置类上会有@ConditionalOnClass、@ConditionalOnMissingBean这些条件注解，只有满足条件才生效。”
老王眼睛一亮。这里其实是Spring Boot自动装配的精髓，多数面试者只会说“自动装配就是自动配置Bean”，但能说清AutoConfigurationImportSelector读取配置文件的路径、条件注解如何做过滤的，至少说明他是真读过源码或者踩过坑。
我在这里也多说一句，很多人在面试时喜欢背“自动装配就是Spring Boot自动帮我们配置好”，但面试官真正想听的其实是下面这几层东西：
- 入口：启动类上的
@SpringBootApplication，它组合了@SpringBootConfiguration、@EnableAutoConfiguration和@ComponentScan。 - 加载机制：
@EnableAutoConfiguration通过@Import(AutoConfigurationImportSelector.class)，在启动时把自动配置类的全限定名一次性加载进来。Spring Boot 2.7之后，配置类的索引文件从spring.factories迁移到了AutoConfiguration.imports。 - 条件化装配：每个自动配置类都标注了
@ConditionalOnClass（类路径存在某个类才生效）、@ConditionalOnMissingBean（容器中没有某个Bean才生效）、@ConditionalOnProperty（配置项匹配才生效）等条件注解。这就是为什么你引入spring-boot-starter-data-redis之后，RedisTemplate就自动能用，而不需要手动写配置类。
谢飞机能说出这一层，已经超过了相当一部分候选人。老王决定再往下追问一步：“那如果我想自己写一个starter，需要哪几步？你设计过吗？”
这正是面试官常用来区分“只会用”和“能扩展”的经典问题。谢飞机这次倒是没怯场，直接说了一个他自己做过的内部工具starter，虽然中间有不少疏漏，但思路是对的。这个细节我放在了后面专门聊，因为自己封装starter这件事，看起来是加分项，实际上里面有一堆坑，稍不注意就是给自己挖坑。
3. Redis Stream这道题，面试官自己差点翻车
3.1 从“拉取队列消息”聊到消费组
老王换了赛道：“你简历上写着用过Redis做消息队列，那我们聊聊Redis Stream。假设有个订单系统，订单创建后需要发一条消息给积分服务，客户端这边要怎么拉取队列消息？”
谢飞机愣了：“啊？Redis还有消息队列？我一直用的RabbitMQ。”
“你们项目里不是写了Redis Stream吗？”老王翻出简历。“哦那个啊，那是我看网上的教程说Redis 5.0之后有Stream，就写上了。但是面试官，我刚才说没用过，现在能不能现学现卖一下？”
老王差点把茶杯捏碎。但本着“看看这小子怎么瞎编”的心态，他还是说：“你试试。”
谢飞机于是开启了边猜边答模式：“那我猜，Redis Stream是Redis 5.0引入的，数据结构类似一个消息日志，支持消费者组。拉消息的话……应该是用XREAD命令？如果要实现多个消费者分摊处理，需要用XREADGROUP配合消费组。”然后他顿了顿，补了一句，“Redis的官方文档里好像说XREADGROUP的>符号表示只读取从未被投递给其他消费者的新消息，这个我记得很清楚。”
这一刻，老王意识到，谢飞机虽然简历掺水，但他是真看过一些东西的。至少这一句“>表示从待处理消息列表里取新消息”，很多自称用过Redis Stream的人都说不清楚。
顺着这个话题，老王开始正经考察Redis Stream的工程细节。他把问题拆成了三层，每一层都有明确的考点。
3.2 第一层：XADD——消息怎么进队列
谢飞机说：“消息要先进队列嘛，用XADD，格式是XADD stream_key * field value，*让Redis自动生成消息ID，这个ID是单调递增的时间戳加序号。”
这里有一个细节值得展开说：XADD的消息ID格式是毫秒时间戳-序号，同一个毫秒内多条消息靠序号区分。这个设计保证了消息ID的全局有序性和分布式环境下的唯一性。正是因为ID是时间戳驱动的，所以消费者可以按ID范围读取历史消息，这对“回放”和“补偿”场景特别有用。
谢飞机对这一层的理解还算到位，老王点了点头。
3.3 第二层：XREADGROUP——消费组怎么工作
老王继续问：“那如果现在有100条消息，我要让三个消费者分摊处理，怎么搞？”
谢飞机：“这就用到消费组了。XGROUP CREATE mystream mygroup 0创建消费组，然后消费者用XREADGROUP GROUP mygroup consumer1 COUNT 10 STREAMS mystream >拉消息。>表示只领取新的、从未被投递的消息。处理完之后还需要手动确认，用XACK，把消息ID从消费者的待处理列表里移除。”
这里出现了第一个真正的陷阱——老王问了一个很多人没搞懂的问题：“消费组里的pending entries list到底是什么？如果消费者拿到消息后还没来得及XACK就挂了，会发生什么？”
谢飞机想了想：“待处理列表会保留这条消息。如果没有XACK，这条消息会一直挂在消费者的pending列表里。如果消费者挂了，需要另一个消费者通过XAUTOCLAIM去接管超时的消息。”
老王这次真的很意外。“你知道XAUTOCLAIM？这是Redis 6.2才出的命令，你从哪看的？”
谢飞机嘴上说“网上看的”，其实心里刚刚赌对了——因为他在某个技术社群里看过一篇文章，讲的正是Redis Stream的消费组机制和消息堆积排查，里面正好提到了XAUTOCLAIM在Redis 6.2之后替代了老旧的XCLAIM，支持批量扫描和自动归属。他把这篇笔记背了个大概，没相当真的被问到了。
我在这里插一嘴，实际项目里用Redis Stream，最容易踩的坑就是消费了但不确认。很多人把消息读出来，业务代码执行完了，却忘了调XACK，导致消息永远留在pending列表里。时间一长，pending列表堆积成千上万条消息，再用XAUTOCLAIM或者XPENDING排查时，你会发现根本分不清哪些是真正没处理完的、哪些是已经处理完但忘了确认的。这也是Redis Stream和RabbitMQ最大的差异——Redis Stream把“投递”和“确认”完全拆开了，消息投递出去了，你确认不确认它不管，但未确认的会一直占着位置。
3.4 第三层：消息积压和ACK缺失，到底怎么排查
老王追问：“如果现在消费者的处理速度跟不上生产速度，消息在Stream里积压了，你怎么发现？怎么处理？”
谢飞机这次倒是不慌了：“可以用XLEN看Stream里的消息总量，再用XPENDING看各消费者的待处理消息数量，对比一下就能发现到底是谁的消费速度不行。如果消息持续增长，说明消费者那边有瓶颈，要么优化处理逻辑，要么加消费者实例。但要注意，同一个消费组里增加消费者实例才能真正并行分担，如果直接开多个消费组，那就变成每个组都收到全量消息了。”
这段话非常关键。实际工程项目里，Redis Stream比RabbitMQ简单直接得多，没有交换机、没有路由键，就是“一个队列、一组消费者”的模型。很多人从RabbitMQ转过来，会下意识地以为开多个消费组就能分担压力，结果每个组都收到全量消息，造成重复消费。正确的做法永远是同一个消费组内增加消费者。
老王对这套回答总体满意，但他心里知道，谢飞机对Redis Stream的认知还停留在“背诵”层面，真要他处理一次线上积压，大概率还是会手忙脚乱。不过作为一场面试，能答到这个程度，已经比他预期好了太多。
3.5 实际项目里的推荐落地方案
如果读者正在用Redis Stream做消息队列，我建议至少把下面这几个参数和命令吃透，这是我在生产环境里验证过的组合：
- 消息ID使用默认生成，不要自己指定，除非你有跨端做消息序号的业务需求。
- 消费组创建时，
0表示从头读历史消息，$表示只读新消息。生产环境首次创建消费组，如果业务上允许旧数据不处理，用$更省事。 - 消费完成后立即
XACK，最好放在业务成功的分支里，而不是放在finally块里。因为finally块里XACK会导致业务失败但消息被确认，消息直接丢了。 - 消费端的超时重试，建议用
XAUTOCLAIM写一个定时任务，扫描pending列表里超过N分钟的消息，重新投递到消费者线程池。 - 监控上除了
XLEN，还要盯XPENDING的列表长度，一旦某个消费者的pending数量持续上涨，说明它已经处理不过来了。
4. 从Spring Boot到微服务：谢飞机的架构图，画成了“蜘蛛网”
4.1 一张架构图引发的讨论
面试推进到一半，老王在电脑上打开一个文档：“谢飞机，我听说你们上一家公司的系统是微服务架构，你现在在白板上画一下你们的服务拆分和调用关系。”
谢飞机走到白板前，拿起笔，先画了一个大大的网关，然后画了订单、用户、商品、支付、库存五个服务，服务之间用箭头连起来。乍一看还挺像回事。然后他画了服务之间的调用关系，五分钟后，白板上出现了一张密集到无法直视的“蜘蛛网”——所有服务之间都有调用箭头，订单调用户、调库存、调支付、调商品，支付又调订单、调用户，库存调商品、调订单。
老王看了一会儿，缓缓问了一句：“你这个……是微服务还是分布式单体？”
谢飞机愣住了：“分布式单体？什么意思？”
“意思是，你把一个单体拆成了五个服务，但服务之间的调用关系跟单体内部的调用关系一摸一样，只是把方法调用换成了HTTP调用。这样做，没有带来任何微服务的好处，反而增加了网络开销和分布式事务的复杂度。”
这其实是一个非常普遍的问题。很多项目号称微服务，实际上只是把原来的一个工程拆成了几个模块，然后互相用Feign调用。真正的微服务架构，核心在于围绕业务能力进行服务划分，并且每个服务尽可能独立演进、独立部署、独立扩展。而在谢飞机的这张图里，服务之间强耦合、调用链冗长，任何一个服务挂掉，整条链路上的请求都会失败。
4.2 服务拆分的正确姿势：先看业务边界，再看调用频率
老王给谢飞机讲了一个非常朴素的办法，也是我这些年做架构评审时经常用的思路：
- 先找业务边界：每个服务应该对应一个清晰的业务能力，比如订单、库存、支付，它们各自有独立的业务语义和数据存储。如果两个功能频繁互相访问彼此的数据库表，说明它们本来就不该拆开。
- 再看数据域：微服务拆分的一个硬性约束是数据隔离。订单服务和库存服务不能用同一张订单表、同一张库存表。如果拆了服务但共用数据库，那这个拆分是伪拆分。
- 最后看独立部署的价值：拆分之后，这个服务是否能独立扩容？是否能独立发版？如果答案是否定的，拆分就没有实际收益。
谢飞机的“蜘蛛网”之所以有问题，是因为他的服务之间用同步HTTP调用串出了一条很长的链路，而且很多调用是强依赖。比如用户下单时，订单服务先远程调用户服务获取用户信息，再调库存服务扣减库存，再调支付服务创建支付单，最后调商品服务查询商品详情。这个链路里只要库存服务慢了一秒，整个下单请求就慢了一秒。如果库存服务挂了，下单功能直接不可用。
老王追问了一句：“如果库存服务挂了，你的订单服务应该怎么办？”
谢飞机：“那就……挂了呗。”
老王笑得特别无奈。这其实牵出了微服务里最重要的一个设计原则——服务降级和容错。正确的做法是：订单服务调用库存服务时，必须设计超时时间和降级策略。比如库存扣减失败并不会让下单流程彻底失败，而是先把订单创建为“待确认库存”的状态，后续通过异步流程或者消息队列去补偿扣减库存。如果同步扣库存是硬性要求，那么至少要给Feign调用配置合理的超时时间，并配合@SentinelResource或者Resilience4j做熔断降级。
4.3 若依微服务版本为什么让人又爱又恨
聊到服务拆分，老王顺口问了一句：“你接触过若依微服务版本吗？我最近看不少简历写‘基于若依微服务版本的二次开发’。”
谢飞机的眼睛亮了：“这个我知道！若依微服务版本是基于Spring Cloud Alibaba的一套脚手架，里面集成了Nacos做注册中心和配置中心，还有Gateway网关、Sentinel熔断、Seata分布式事务这些组件。很多人拿它做毕设或者公司内部系统的底座。”
老王追问：“那你启动过没有？”
谢飞机：“启动过，折腾了两天才跑起来。”
这里谢飞机倒是说了一句大实话。若依微服务版本确实好用，它把Spring Cloud Alibaba生态里的常见组件都集成了，代码结构清晰，前端也有配套的Vue页面，拿来见世面、学架构是完全够的。但它的启动门槛不低：
- 需要本地装MySQL、Redis、Nacos，还要初始化一堆数据库脚本。
- Nacos里要配置好各个服务的数据源和公共配置，很多依赖
bootstrap.yml读取配置，一个配置项写错，服务一启动就报错。 - 服务有几十个，如果不分批启动，本地电脑扛不住，我第一次跑的时候，开了一堆服务，电脑风扇直接起飞。
不过话说回来，若依微服务版本最大的价值不是直接用于生产，而是一个完整的微服务教学样本。你能从里面看到网关怎么路由、鉴权怎么设计、服务间怎么调用、配置怎么管理。如果你还没看过微服务架构长什么样，拿它跑一遍，比看一百篇架构图文章都有用。相关热词里一直有“若依微服务版本如何启动”，我现在写文时也再次想到了：其实网上已经有很多详细的图文教程，先把Nacos跑起来再启动网关和服务，是最不容易出错的路径。
从面试的角度来说，能说清“若依微服务版本的目录结构和核心组件”已经是一个加分项。但面试官真正想听到的不是“我会用若依”，而是“我知道若依里每个组件解决了什么问题”。如果把答案换成“Nacos负责服务注册发现和配置管理，Gateway负责统一入口路由，Sentinel负责流量控制和熔断降级，Seata负责分布式事务”，这个回答的含金量就完全不一样了。
5. 八股文名场面：冒泡排序、Java Bean丢失字段和Lambda的连环追问
5.1 面试官最爱的基础题，谢飞机全赶上了
老王看了看表，觉得前面聊得差不多了，开始进入“基础题扫雷”环节。这个环节是Java面试的保留项目，也是谢飞机整场面试里最跌宕起伏的部分。
老王先问：“冒泡排序，写一下。”
谢飞机拿起笔，在白板上刷刷写出了一段代码：
java复制public static void bubbleSort(int[] arr) {
int n = arr.length;
for (int i = 0; i < n - 1; i++) {
for (int j = 0; j < n - 1 - i; j++) {
if (arr[j] > arr[j + 1]) {
int temp = arr[j];
arr[j] = arr[j + 1];
arr[j + 1] = temp;
}
}
}
}
老王看了一眼：“这是最基础的写法，但性能怎么优化？”
谢飞机想了想：“可以加一个标志位，如果某一轮没有任何交换，说明数组已经有序，直接跳出循环。”然后他补了一个优化版本：
java复制public static void bubbleSortOptimized(int[] arr) {
int n = arr.length;
for (int i = 0; i < n - 1; i++) {
boolean swapped = false;
for (int j = 0; j < n - 1 - i; j++) {
if (arr[j] > arr[j + 1]) {
int temp = arr[j];
arr[j] = arr[j + 1];
arr[j + 1] = temp;
swapped = true;
}
}
if (!swapped) break;
}
}
这个回答在面试里算中规中矩。真正拉开差距的下一步，老王问的是：“那你知道冒泡排序的稳定性和时间复杂度吗？”
谢飞机：“稳定，因为相同元素不会交换位置。时间复杂度最好O(n)，平均和最坏O(n^2)。空间复杂度O(1)。”
到这里，基础题过关。老王点了点头，然后抛出了一个很多Java开发都会踩的坑：“我现在有个Java Bean，字段名是userName，但是有个字段名是大写字母开头的，比如URL，用Jackson序列化成JSON之后，字段名会变成什么？”
谢飞机一下就笑了：“面试官，这个我太熟了！Java Bean规范里，如果一个属性的名字以大写字母开头，那么它的getter方法名是getURL()，而JavaBeans的Introspector会把getURL解析为属性名URL，但实际上Java里有个老坑——如果字段名是大写字母开头，属性名的推断可能会变成小写。具体来说，如果字段名第二个字母也是大写，属性名会保留原样；如果第二个字母是小写，属性名会被强制变成小写开头。所以URL会变成url，导致JSON序列化之后字段名对不上。”
这一段回答让老王很满意，因为这是真正的实战痛点，网上能说清楚的人不多。我在这里详细展开一下，因为这个坑在Spring Boot项目里真的很常见：
- JavaBeans的
Introspector.decapitalize()方法决定了属性名的生成规则：如果类名或属性名的前两个字母都是大写，则保持原样；否则首字母小写。所以URL会被解析成URL，但userName会被解析成userName。 - 但Spring Boot默认用的Jackson，在某些版本里对
URL这种字段的处理并不完全遵循JavaBeans规则，而是优先使用字段名。如果你在实体类里写的是private String URL;并生成了getURL()和setURL()，Jackson序列化时可能输出URL，也可能输出url，取决于你是否开启了MapperFeature.USE_STD_BEAN_NAMING。 - 解决这个问题的方案很直接：要么给字段加
@JsonProperty("URL")显式指定序列化名称，要么避免字段名使用全部大写。我在代码评审时见过很多次，字段名叫ID、URL、IP，结果前端对接时收到的JSON字段名跟后端定义的对不上，排查了半天才发现是序列化命名规则的问题。
5.2 Lambda与函数式编程：谢飞机的“程序员式狡辩”
老王继续：“好，那Lambda表达式了解吧？用Lambda实现一个Runnable，怎么写？”
谢飞机：“Runnable r = () -> System.out.println("hello"); 这个太简单了。”
老王：“那Lambda表达式实际上是一个什么东西？它跟匿名内部类有什么区别？”
谢飞机思考了一下：“Lambda表达式对应的是函数式接口的实例，它不是一个类的匿名实现，而是JVM通过invokedynamic指令在运行时动态生成的。跟匿名内部类相比，Lambda不会生成额外的匿名类文件，性能更好。而且Lambda表达式中使用的外部变量必须是effectively final的，也就是虽然没有显式声明final，但在整个作用域中没有被重新赋值。”
这里谢飞机答得比很多工作了三五年的人都好。老王随后加了一题：“list.stream().map(...).filter(...).collect(Collectors.toList())，中间每个操作各返回什么？”
谢飞机：“map和filter返回的都是Stream对象，是一个中间操作，不会真正执行。collect是终端操作，触发整个流水线的执行。整个链路是惰性求值的，只有遇到终端操作才会真正遍历数据。”
老王点了点头：“最后一个问题，stream的并行流了解吗？什么情况下不要用并行流？”
谢飞机：“并行流用的是ForkJoinPool的公共线程池。如果任务本身非常轻量，比如就是一个简单计算，那么线程拆分的开销可能比任务本身的执行时间还大，性能反而更差。另外，如果有共享可变状态，并行流会导致线程安全问题。还有一个很多人忽略的点——并行流的公共线程池是全局共享的，如果在Web应用里滥用并行流，可能会把公共线程池里的线程占满，影响其他使用并行流的业务。”
这段话非常有信息量。谢飞机自己可能都不知道，他说的最后一点，是很多并发问题排查中最常见的原因之一：ForkJoinPool.commonPool()的并行度默认是CPU核心数-1，如果你的多个业务接口都用了parallelStream，它们实际上是在争抢同一个线程池。某个接口的大量数据导致线程池资源耗尽，其他接口的并行流就会排队等待，表现为整机业务延迟上升。排查这种问题通常需要在ForkJoinPool.commonPool()的监控上下功夫，或者干脆把并行流换成自定义线程池。
5.3 Java学习路线的经典问题：环境变量和版本号
面试到这里，老王想起了网上常讨论的一个场景，决定问一个“送分题”：“如果新员工入职，要在新电脑上配置Java开发环境，你说说要配哪些环境变量？”
谢飞机：“JAVA_HOME、PATH、CLASSPATH。JAVA_HOME指向JDK安装目录，PATH要加上%JAVA_HOME%\bin，这样命令行里才能直接用java和javac。CLASSPATH现在一般不用手动设置了，因为Java 9之后引入了模块化，很多场景下不配置也能跑。”
老王追问：“如果编译时提示源发行版 17 需要目标发行版 17，这是什么问题？”
谢飞机：“这题我会。这是Maven或IDE里的编译器版本跟当前JDK版本不匹配导致的。项目配置的是17的release，但实际编译时用的JDK或编译器设置低于17，或者IDE里的Java版本没对准。在IDEA里就是Project Structure的SDK配置跟pom.xml里的maven.compiler.source/target不一致，在Maven构建时则是JAVA_HOME指向的JDK版本不对。”
这种报错在开发中几乎天天见，但很多人第一反应是去改pom文件，结果改了还是报错。实际上，报错信息已经写得很清楚了：源发行版和目标发行版分别是编译源码时使用的Java版本和生成字节码的Java版本。如果pom里写的是17，但当前JDK是8，编译器根本不认识17，就会报这个错。遇到这种问题，先敲一个java -version确认当前默认JDK，再看IDE的Project SDK，最后看pom的编译参数，按这个顺序排查最快。
6. 面试后半场：谢飞机暴露的真实工程经验和系统设计短板
6.1 微信服务号、监控告警和中间件部署的“项目流”提问
老王看了看表，还有十分钟。他决定问一些开放性问题，考察谢飞机的工程思维。
“我看你简历上写了一个上门烹饪预约服务的项目。基于Spring Boot的，对吧？你负责哪块？”老王问。
谢飞机：“我负责的是预约下单模块和后台管理。预约下单里，用户选厨师、选时间段、提交预约订单，后台管理里可以查看订单列表、接单、完成订单。”
“订单提交之后，怎么保证用户和厨师看到的数据是一致的？如果有两个用户同时预约同一个厨师同一个时段，你怎么防止超卖？”
谢飞机：“这个我想过，可以用数据库的唯一索引或乐观锁。比如在booking表里加一个(chef_id, time_slot)的唯一约束，这样同一时间段同一个厨师只能有一条有效预约。或者用Redis的分布式锁，在创建订单前先锁住厨师的时间段，处理完了再释放。”
这本该是一个很亮眼的回答，但谢飞机紧接着补了一句：“不过我当时的项目没做这个，因为需求文档里没写并发，我就直接做了普通插入。”
老王哭笑不得：“你知道为什么我会问这个问题吗？因为核心业务逻辑中的并发问题，本来就应该由开发自己发现，而不是等产品经理提需求。你做预约系统，天然就是高并发下单场景，这是业务属性决定的。”
谢飞机低头摸了摸鼻子：“面试官，你说得对。这个我当时确实没想清楚。但如果你给我一次重来的机会，我肯定是用Redis预减库存加数据库最终校验的方式来做。”
这里其实是谢飞机整场面试中第二精彩的瞬间。第一是他居然能答出XAUTOCLAIM，第二就是他在被指出短板之后能很快提出一个相对合理的改进方案。“Redis预扣减 + 数据库兜底校验”虽然也有坑，但至少说明他知道高并发场景下怎么做限流和防超卖。
我之前在实际项目中处理过类似场景，简单说一下这个方案的完整链路：
- 用户发起预约请求，先经过网关和Sentinel限流。
- 订单服务收到请求，在Redis里执行一个Lua脚本，检查
chef:{id}:slot:{time}这个key的剩余可预约数量，如果大于0则扣减并返回成功，否则直接返回“该时段已被约满”。 - Redis扣减成功后，异步写数据库创建订单。
- 如果数据库插入失败（比如唯一索引冲突），需要反向补偿，把Redis里的数量加回来。
- 定时任务扫描超时未支付的订单，回补库存。
这套方案的核心是将“预占资源”放在Redis里，用它的原子操作挡住绝大多数并发请求，数据库只做最终落库。但要注意，如果Redis扣减成功但数据库写入失败，必须要有补偿机制，否则Redis里的库存和数据库里的真实订单会对不上。这也是“Redis预扣减”方案很难做好的地方。
6.2 Activiti工作流和自定义查询的“微服务套餐”
老王继续翻简历：“你写着用过Activiti？”谢飞机：“用过，毕业设计的时候用的，做了一个请假审批流程。”
“在微服务架构里，如果要集成Activiti做审批流，需要注意什么？”
谢飞机想了想：“Activiti自带一套数据库表，直接依赖关系型数据库。在微服务架构里，建议把Activiti部署为一个独立的流程引擎服务，其他服务通过Feign或消息队列调用，不要让所有服务直接依赖同一套Activiti表。另外Activiti的部署模式要从单机模式调整为集群模式，因为原生部署不是为高并发设计的。”
这里他又说到了比较关键的点。Activiti在微服务场景下的集成方案，主流有两种：一种是独立部署一个工作流服务，封装流程定义、流程实例、任务办理等API；另一种是通过消息队列把流程事件广播出去，让其他服务异步解耦。前者适合审批流跟业务强相关的场景，后者适合流程触发后不需要同步结果的场景。
我见过不少人在微服务里直接集成Activiti，然后所有服务共享同一个Activiti数据库，刚开始没数据量时一切正常，等到流程实例一多，Activiti的ACT_RU_TASK表越来越臃肿，查询代办任务越来越慢，然后开始各种骂Activiti不好用。实际上不是Activiti不好用，而是部署架构从一开始就错了。
6.3 Spring Boot 2.6+和Springfox 3.0.0的兼容性坑
聊完Activiti，老王出了一个很考经验的题目：“如果项目里用的是Spring Boot 2.6+，然后引入Springfox 3.0.0做Swagger文档，启动时会报PathPatternMatcher相关错误，或者空指针异常，你遇到过吗？怎么解决？”
谢飞机：“遇到过！”谢飞机说。实际上他在来面试之前刚在CSDN上刷到过这个问题的解决笔记，运气好撞上了。
“Spring Boot 2.6之后，Spring MVC的路径匹配策略从AntPathMatcher改成了PathPatternParser，Springfox 3.0.0有一些逻辑基于旧的匹配器，所以启动时会报错。解决办法要么在application.properties里加spring.mvc.pathmatch.matching-strategy=ant_path_matcher，要么升级到Springdoc。”
这个答案很标准，但老王更想听的是背后的思路：“为什么Spring Boot要改匹配策略？”
谢飞机：“因为PathPatternParser性能更好，语法也更强，是Spring官方推荐的替代方案。但问题在于，很多旧的第三方库没有跟上Spring Boot的升级节奏，Springfox就是典型例子，它停更太早了，导致跟新版本Spring Boot的兼容性一直有问题。”
这里插一句，升级Spring Boot版本时，Swagger文档组件是最容易踩坑的地方。Springfox 3.0.0版本停留在2020年，之后几乎没有大版本更新，而Spring Boot 2.6+、2.7+的改动非常多。所以我一般在新的Spring Boot项目里直接推荐springdoc-openapi，它对OpenAPI 3标准的支持更完整，而且能持续跟上Spring Boot的更新节奏。
6.4 “Spring Boot项目怎么在命令行运行”这种送分题，为什么会成为热搜词
面试接近尾声，老王问了一个很朴素的问题：“你们平时开发时，怎么在命令行启动Spring Boot项目？”
谢飞机：“mvn spring-boot:run，或者先mvn package打成jar包，然后java -jar xxx.jar --spring.profiles.active=dev。”
老王：“那怎么打包时候跳过测试？”“mvn package -DskipTests。”
老王：“生产环境用什么方式部署？”“用nohup java -jar xxx.jar > app.log 2>&1 &，然后配一个监控脚本，服务挂了自动拉起。”
这段问答看着平平无奇，但你别小看它。事实上，“Spring Boot项目开发环境命令行运行项目”能成为热搜词，恰恰说明很多人在打包、启动、部署这些基础的运维操作上是薄弱的。很多同学用IDEA点一次Run就能跑起来，但离开IDE之后对java -jar的参数、日志输出、环境切换一片空白。面试官问这种题不是为了考你背书，而是考察你有没有真正把一个项目从开发环境推到过生产环境。
7. 面试结束之后：谢飞机拿到了Offer，不是因为搞笑
老王的面试记录表上，技术评分栏里写着：基础不错，有工程经验，但对并发和分布式架构的理解仍停留在概念层，需要培养。他合上电脑，对谢飞机说了最后一个问题：“最后一个问题，如果入职之后，团队让你维护一个老项目，接手第一天你会做什么？”
谢飞机：“先把项目的README看一遍，了解技术栈和启动方式。然后看数据库表结构和核心业务流程，跑一遍完整的业务链路。再然后看线上日志和监控面板，了解系统当前有没有异常。最后把常见的坑记录下来，遇到问题先搜日志，再搜代码，不要上来就问同事。”
老王最后说了一句话：“行吧，回去等通知。”
后来，部门还是给谢飞机发了Offer。原因也很简单：这个候选人虽然简历注水，但在一轮半小时的面试里，他展现出了几点真实的优势——面对压力时能快速调动知识储备、遇到不会的问题会坦诚承认而不是硬编、在被指出错误后能提出改进方向。这些素质，在某些时候比多背几条八股文更重要。
但如果你以为这篇面试记录只是为了讲故事，那你就错了。整场面试里涉及的知识点，随便拎出来一个都是Java面试中面试官最爱考察的内容：
- Spring Boot自动装配的底层机制和条件注解
- Redis Stream消费组的
XREADGROUP、XACK、XAUTOCLAIM和pending列表 - 微服务拆分的业务边界和调用链设计
- Java Bean序列化时大写字母字段名的命名坑
- Lambda表达式的本质和并行流的线程池问题
- 高并发预约场景下的防超卖设计
- Activiti在微服务架构中的部署模式
- Spring Boot版本升级与Swagger组件的兼容性
这些内容在网上可以找到零散的资料，但很少有一个场景能把它们串在一起讲透。这也正是我想写这篇文章的初衷——与其一份份地刷面试题，不如跟着一场真实的面试走一遍，看看面试官真正关心的是哪些问题，以及这些问题背后对应的实际工程场景。
我复盘谢飞机这场面试后，最大的感触是：面试不是考你记住了多少，而是考你在面对不确定的问题时，能不能有逻辑、有框架地组织自己的知识。谢飞机有些问题答得很拉胯，但他在答Redis Stream和并行流时展现出的那种“虽然我不确定，但我知道可以从哪些角度去分析”的思维方式，恰恰是他能拿到Offer的关键。
最后再分享一个我自己的小习惯：每次面试候选人之后，我都会把面试中的关键问题整理成一篇笔记，然后对照着看自己在实际项目中是否真的处理过类似场景。这个习惯帮我发现了很多知识盲区，也帮我验证了很多看似正确的认知。如果你也是Java开发，试着用谢飞机这场面试里的问题做一次自测，每一题你都能不看资料答出来吗？能答出来的，多半是真懂了；答不出来的，也许是你和我都需要回去补课的地方。