Java大厂面试高频实战：Spring Boot自动配置到微服务治理

前几天帮一个做了两年 CRUD 的朋友做模拟面试，简历上写着“熟练使用 Spring Boot、Spring Cloud 微服务”。我随口问了一句：你的服务启动之后，Spring Boot 到底是怎么把 DataSource 自动创建出来的？他沉默了几秒，说：“我就配了个 application.yml，也没写 Bean……然后它就能用了。”后面基本上很难聊下去了。

这个场面我见过太多次。“会用”和“理解原理”之间的差距，在面试官眼里就是一条分水岭。尤其是现在 Java 后端岗位的面试，已经不满足于“你背过多少面试题”，而是会拿一个真实的业务场景去验证你的技术边界：Spring Boot 自动配置的触发条件是什么？服务暴露给第三方监控时该开哪些端点？Redis Stream 做消息队列时怎么拉消息、怎么保证不丢？微服务拆完之后，链路断了你用什么兜底？

这篇文章用我自己带人、面试和复盘的经验，把“互联网大厂 Java 面试”里最常见的高频场景串一遍。从 Spring Boot 的底层原理，到 Actuator、Redis Stream、Springfox 兼容性这类中间件细节，再聊到微服务治理中的服务发现、熔断、幂等、分布式事务，最后补上 JVM 内存问题、Tomcat 部署和环境配置这些实战经验。目标读者很明确：准备社招或校招的 Java 后端，自学了一年半载想系统查漏补缺的同学，以及刚转岗 Spring Cloud 方向、想搞懂每个组件背后取舍的初级工程师。

这篇文章不会帮你“押题”，但会告诉你每个问题背后，面试官真正想听什么。

1. 别急着背八股，先搞清楚大厂到底在考什么

1.1 从简历到面试，不同级别的考察重心完全不同

很多候选人准备面试有一个误区，上来就刷题，背 JVM、集合、并发、Spring 源码，什么都想要，结果什么都只是“知道个结论”。实际上大厂面试很看级别，不同职级考察的方向差异巨大，面试官对你的期待不是你背得多，而是你的技术认知是否匹配这个职级应有的位置。

我按常见的大厂 P5/P6/P7 一类的分法，总结了一下考点分布：

比如同样问“Spring Boot 和 Spring 是什么关系”，初级候选人可以说“Spring Boot 简化了 Spring 配置”，这个答案基本只能算及格。到了中级以上，至少要能说出 Spring Boot 基于 Spring 框架，通过自动配置和 starter 机制减少了显式配置，但它并没有改变 Spring 的 IoC 和 AOP 内核。再往后，面试官会追问“既然没改变内核，Spring Boot 启动时 IoC 容器的刷新流程做了什么”，这就涉及到 Spring 容器的生命周期了。

所以我建议准备面试前先给自己定个位：你现在求职的是什么职级，面试官大概率会问到什么深度，不要用背初级题目的方式去准备高级岗位，也不要在答基础题时忽然把源码细节倒出来，给人感觉很奇怪。

1.2 项目深挖要能一直往下追问

项目追问是大厂面试里最没法临时抱佛脚的部分。面试官会选择一个你在简历上写的项目，然后一层一层往下挖，挖到你自己都没想过的地方，看你的技术边界到底在哪。

我举个例子，很多同学简历里会出现“基于 Spring Boot 的高校实验室预约管理系统设计与实现”这种项目。这种项目本身偏业务，但它照样能挖出很多硬核问题。面试官一般会这样问：

“实验室预约，核心矛盾是什么？”答案是资源有限，多个学生同时预约同一间实验室，存在并发冲突。
“那你怎么解决并发冲突？”有人会说用数据库唯一约束，有人会说预约前先查一下，没有人再插入。
“那如果两个请求同时查到没有人，同时插入呢？”这时候就得说数据库行锁、唯一索引、乐观锁版本号，或者 Redis 分布式锁。
“预约成功后需要发通知，如果系统压力大怎么办？”进一步引到消息队列削峰，比如 Redis Stream 做异步通知。
“那消息丢了怎么办？消费者挂了怎么办？”再往下就是消费确认、重试、死信处理。

你会发现，任何一个普通的业务项目，只要用一个业务问题当作线索，可以把并发、缓存、锁、消息队列、最终一致性全串起来。面试官真正考察的不是你会不会用 Redis、会不会用 RabbitMQ，而是你有没有一套完整的分析问题的方法。

所以要准备项目深挖时，不要只背自己用了哪些技术，而是准备好一条问题链：我的系统最核心的风险是什么？如果流量涨十倍，哪里最先扛不住？当时为什么选这个方案而不是另一个？换一种方案会带来什么问题？这套问题想明白了，哪怕项目很普通，也能体现你的设计意识。

2. Spring Boot：面试从“会配置”到“懂原理”的必经之路

2.1 自动配置到底是怎么“替你干活”的

Spring Boot 最核心的卖点就是“自动配置”，面试考查频率极高。要回答好这个问题，不能只说“它帮我配置好了 Bean”，而要讲清整个链路。

我把链路拆成四个环节：

1. 引入依赖。比如你引入了 spring-boot-starter-web，这个 starter 内部依赖了 spring-boot-autoconfigure，自动配置的核心代码都在里面。
2. 读取自动配置清单。Spring Boot 启动时，@EnableAutoConfiguration 注解会触发 AutoConfigurationImportSelector 去加载自动配置类列表。在老版本里，这个列表写在 META-INF/spring.factories；Spring Boot 2.7 开始推荐写到 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件中。
3. 条件注解判断。每个自动配置类上面有一堆 @ConditionalOnClass、@ConditionalOnMissingBean、@ConditionalOnProperty。比如 DataSourceAutoConfiguration 上会有 @ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class })，意思是当你引入了 JDBC 相关依赖、classpath 里有 DataSource 时，才执行这个自动配置。
4. 导入具体配置并注册 Bean。如果条件都满足，就生成一个 DataSource 相关的 Bean。如果你自己写了 DataSource，因为有 @ConditionalOnMissingBean，Spring Boot 会自动让位，不覆盖你的配置。

打个比方，自动配置就像一条餐厅流水线，食材（依赖 jar）备齐了，对应岗位的厨师（自动配置类）才会上工；如果店里已经有一个更熟悉本地口味的厨师（用户自定义 Bean），总部派来的厨师就会自动退让，避免抢锅。

实际开发中我会建议大家写一次自定义 starter，比背十遍原理都有效。新建一个模块，在 src/main/resources/META-INF/spring/ 下面创建 AutoConfiguration.imports 文件，内容写你自己的自动配置类全限定名，然后在自动配置类上通过条件注解去装配。做完一边，你对 starter 机制的理解就扎实了。

至于 starter 命名，也要注意。官方的 starter 是 spring-boot-starter-data-redis，这种名字表示它是 Spring Boot 官方的；第三方通常写成 my-log-spring-boot-starter 或 my-spring-boot-starter，目的是避免和官方命名空间冲突，也让使用者一眼看出这个 starter 想要集成谁。

2.2 SpringApplication 启动流程与生命周期事件

面试中还会问“Spring Boot 启动过程里发生了什么”，这题能看出你是只会 SpringApplication.run 还是真研究过源码。

不用把每个细节都背出来，但至少要把主线说清楚：

Spring Boot 启动时先做了两件事：确定应用类型，是普通项目还是 Web 项目；加载各个自动配置类需要的初始化器和监听器。然后创建并准备 Spring 的应用上下文（ApplicationContext），把主类解析成配置源。接下来是 Environment 的准备，把 application.yml 里的配置项读出来；接着刷新上下文，这是 Spring 框架的核心——创建 BeanFactory、执行 BeanFactoryPostProcessor、注册 BeanPostProcessor、实例化单例 Bean、触发事件发布等。如果是 Web 项目，刷新结束后会启动内嵌的 Tomcat 或 Netty。最后，启动完成后执行实现了 ApplicationRunner 和 CommandLineRunner 的回调方法。

我特别喜欢追问候选人：ApplicationRunner 和 CommandLineRunner 有什么区别，什么时候用？很多人只知道“启动后等数据”；然后我再问：ApplicationRunner 的 run 方法和 Spring 的事件机制有什么区别？如果启动后要异步处理某个任务，用哪种更合适？

我的建议是，这类场景里如果要做“启动预加载”，用 Runner 很直观；但如果你希望其他模块也能感知“应用启动完成”并做处理，更好的是通过 Spring 的事件机制发布一个自定义事件，再让多个监听器各自响应。Runner 是“它自己跑一个任务”，事件是“别人也能订阅”，语义完全不同。

2.3 Spring Boot 版本差异与兼容性坑

大厂项目一般不追求最新版本，但面试官会问：“你们项目用的什么版本？升级过吗？升级时踩过什么坑？”这个问题其实在考察候选人有没有版本意识。

我整理了一份高频版本变化的速查：

说到影响，最典型的例子就是 Springfox 3.0.0 与 Spring Boot 2.6+ 的冲突，这个问题在面试中经常被当成场景题抛出来，我后面会单独用一节来拆解。

另外还要注意，Spring Boot 2.x 默认 Java 8 或 11，3.x 则必须 17 以上。如果你面试时说“我们项目还在 Spring Boot 2.3”，那正好可以借此展示你做过什么升级方案、怎么兼容老依赖，这比报一个版本号要有价值得多。

3. Actuator、Micrometer 与可观测性：运维不再是加分项

3.1 Actuator 端点：健康检查到底暴露哪些信息

Spring Boot Actuator 是 Spring Boot 自带的生产级监控组件。以前可能被认为是“加几个依赖、看个 actuator 页面”的事，但现在大厂面试里，它已经成了高频考点，而且经常和实际运维场景结合。

Actuator 提供了很多端点，我列一下最常被问的：

很多人这里会犯一个错误：为了省事，把 management.endpoints.web.exposure.include=* 直接敞开。真正生产环境绝对不要这么干，会导致信息泄露。比较稳妥的做法是暴露 health,info,metrics,prometheus 这几个端点，其他端点关掉或强制走内部网络。

健康检查的自定义也很值得聊。如果你接入了 Redis、MySQL、消息队列，Spring Boot 默认的 health 只会检查框架能感知到的组件，但你的业务指标不一定在里面。这时候可以自己实现 HealthContributor，把核心接口的探测加进去，比如检查某张配置表能否正常查询。

3.2 Micrometer 与监控指标体系的适配

Micrometer 和 Spring Boot Actuator 经常一起出现。Micrometer 做的事情，简单说就是给 Java 应用提供了一套统一的指标门面 API，类似 SLF4J 在日志领域的抽象层。

为什么要引入这种抽象？因为不同公司用的监控系统不一样，有 Prometheus、有 Datadog、有阿里云监控、有 InfluxDB。如果代码里直接依赖某一个监控系统的客户端，换监控系统就得改业务代码。Micrometer 把 Counter、Timer、Gauge、DistributionSummary 这些计量类型规范化，后端接哪个 registry 就只依赖对应的注册器。

在 Spring Boot 项目里接入 Prometheus，步骤非常固定：先引入 io.micrometer:micrometer-registry-prometheus，然后在配置里暴露 /actuator/prometheus 端点。之后 Prometheus 就可以定时拉取这个端点的指标。

面试官常问一个细节：Counter、Timer、Gauge 有什么区别？我的理解要落到使用场景上。Counter 只增不减，适合统计请求总数、错误总数，像家里的电表，只会越走越大；Timer 测量耗时和调用次数，适合接口 RT、数据库查询耗时这类场景；Gauge 则可以上升也可以下降，适合当前线程数、队列积压量、JVM 堆使用量这类实时快照。

用对指标类型比“把数字打出来”重要得多。我之前见过一个同事统计接口耗时用的是 Gauge，结果每次抓取只在那一瞬间看到一个数值，完全无法统计 P99 耗时，因为没有记录分布。换用 Timer 之后，才能推算出多种百分比延迟，这才是监控真正需要的。用 Micrometer 的重点不是“会加依赖”，而是要知道每个指标背后代表的语义。

3.3 从 Actuator 指标到线上问题定位的思路

再往深一点，面试官会问：“假如线上服务 CPU 突然飙高，你怎么排？”。很多人第一反应是看日志，其实监控体系给你的线索比日志更快。

正确的排查思路是这样的：

1. 先看服务监控大盘，确认不是机器整体问题。
2. 使用 Actuator 的 /actuator/metrics/system.cpu.usage、jvm.memory.used 看当前进程占用。
3. 如果 CPU 高但内存正常，多半是线程在做大量计算或者频繁 GC。用 threaddump 端点抓线程快照，或者直接 jstack pid 看线程栈，定位到具体代码位置。
4. 如果是 GC 频繁导致 CPU 飙高，再结合堆内存指标判断是否分配过大、是否存在内存泄漏。

这套链路几乎是标准流程，但在 Spring Boot 面试里，很少有人会从“Actuator/metrics”这个入口去回答。其实这才是可观测性组件真正的价值：它不是用来炫技的，是为了让你在事故发生的第一时间能做出判断。

4. 中间件与第三方集成的场景题

4.1 Redis Stream 如何拉取队列消息：核心不是命令，是消费模型

现在很多项目喜欢用 Redis 做消息队列，面试题里也经常出现“Spring Boot + Redis Stream 如何拉取队列消息”。如果你想答好，不能只背命令拼写，要能说清楚消费模型。

Redis Stream 是 Redis 5.0 引入的数据类型。它解决的是以前用 List 做队列时的痛点。用 LPUSH + BRPOP 虽然简单，但做不到“多个消费者组各自独立消费同一条消息”，也没有原生的 ACK 确认机制。Redis Stream 提供了消费者组（Consumer Group），每个组维护自己的消费位点，同一条消息发给多个不同的业务组时，各组的进度互不影响，组内消息只发给一个消费者，避免重复处理。

我来写一个简洁的 Spring Boot 场景：一个订单服务在 Redis 里有一个 order:stream，库存服务和通知服务各自建一个消费者组，消费这条订单消息。

在 Spring Boot 里，用 RedisTemplate 可以手动执行 XREADGROUP 之类的方法，但生产上更常见的做法是使用 StreamMessageListenerContainer 做持续监听：

java复制RedisConnectionFactory factory = redisTemplate.getConnectionFactory();
StreamMessageListenerContainer<String, ObjectRecord<String, String>> container =
    StreamMessageListenerContainer.create(factory,
        StreamMessageListenerContainerOptions.builder()
            .pollTimeout(Duration.ofSeconds(2))
            .targetType(String.class)
            .build());

container.receive(Consumer.from("order-group", "consumer-1"),
    StreamOffset.create("order:stream", ReadOffset.lastConsumed()),
    message -> {
        String msgId = message.getId().getValue();
        String body = message.getValue();
        try {
            // 业务处理
            processOrderEvent(body);
            // 处理成功后确认消息
            redisTemplate.opsForStream().acknowledge("order:stream", "order-group", msgId);
        } catch (Exception e) {
            // 记录失败，后续用手动补偿或转入延迟重试
        }
    });

container.start();

这里最关键的一点是：消费者成功处理之后才执行 acknowledge，这样下游处理失败后消息还保存在 PEL（Pending Entries List）里，可以重新消费或人工补偿，不会直接丢失。

用 Redis 做消息队列肯定要聊局限。Redis 的持久化机制决定了它在极端情况下可能丢数据，消息积压时内存压力大，也不支持像 Kafka 那样的分区级顺序保证和长时间回溯。所以我的建议是：如果只是业务解耦、异步通知、量不大、能容忍小概率丢失，用 Redis Stream 完全可以；但核心链路像订单支付、财务流水、对账这一类需要高可靠的消息，老老实实上 RocketMQ 或 Kafka。面试官想听的不是“Redis 不能做 MQ”，而是你能说出这个取舍的边界。

4.2 Springfox 3.0.0 与 Spring Boot 2.6+：一个漂亮的技术判断题

搜索热词里经常看到“Springfox 3.0.0 与 Spring Boot 2.6+”，这是一个很真实的兼容性问题。场景是这样的：原来用 Spring Boot 2.5 + Springfox 3.0.0，Swagger 页面还好好的，一升级到 Spring Boot 2.6，启动直接报错，或者 /swagger-ui/index.html 打开 404，控制台出现一段很长的 Failed to start bean 'documentationPluginsBootstrapper' 异常。

原因是 Spring Boot 2.6 开始，把 Spring MVC 的默认路径匹配策略从原来的 AntPathMatcher 改成了 PathPatternParser。Springfox 3.0.0 底层很多实现还在用旧的 AntPathMatcher 的匹配规则，两者不兼容，于是一堆 Bean 在初始化时直接崩溃。

遇到这个问题的第一反应往往是改配置：

properties复制spring.mvc.pathmatch.matching-strategy=ant_path_matcher

这个配置确实能把它“救活”，属于典型的快速止损方案。但我一般建议项目里不要长期停留在这个状态，因为 PathPatternParser 在性能上更优，Spring Boot 后续演进都会默认使用新策略，你为了一个 Swagger 库强行让整个 Web 层退回旧模式，有点得不偿失。

更好的做法是考虑迁移到 springdoc-openapi。它天然支持 Spring Boot 2.6+ / 3.x，底层走的是 OpenAPI 3 规范，而且大量注解比如 @RestController 都不用改，关键是把原来的 @Api、@ApiOperation 换成 @Tag、@Operation，工作量和收益基本成正比。

面试时如果被问到这个场景，标准回答思路是：先讲清楚原因是路径匹配策略变化，再给出两种解法并分析优缺点，最后说清楚你如何判断该选哪个方案。

4.3 第三方平台与消息推送集成：Firebase 场景背后的工程思维

网络热词里有“Firebase 与 Spring Boot 集成消息通知”，这其实是一个把后端工程能力和第三方平台整合起来的常见面试场景。移动端接入 FCM 推送之后，服务端需要知道每个用户的设备注册 token。一般做法是：App 启动时向 FCM 注册，拿到 FCM token，然后调后端接口把 token 与用户绑定；后端在需要推送时调用 Firebase Admin SDK，把消息发给对应的 token。

Spring Boot 集成 Firebase Admin SDK 的做法大致如下：

1. 引入 firebase-admin 依赖。
2. 在项目里读取从 Firebase 控制台下载的服务账号 JSON 文件，通过 FirebaseOptions 初始化 FirebaseApp。
3. 封装一个推送服务，构建 Message，设置 token、通知标题、正文和自定义 data。
4. 调用 FirebaseMessaging.getInstance().sendAsync(message) 发送。

实际做的时候，业务同学容易忽略几个点。服务账号文件是敏感凭据，不能提交到 Git，也不能放在 classpath 根目录随意被人下载，应该放到配置中心或者由环境变量注入路径。FCM 对无效 token 会返回特定错误码，例如 invalid-registration-token 或 mismatched-sender-id，后端需要把过期 token 从用户表里清理掉，而不是每次推送都拿到错误重试造成浪费。

更底层的工程思考是：推送是外部依赖，外呼第三方接口永远可能慢或者故障，所以发送请求要有超时控制、失败重试，并且尽量异步化，不要阻塞主流程。如果应用规模大一些，还可以把消息先发到自己的队列里，再由 worker 异步调 FCM，把第三方故障对主链路的影响降到最低。

面试官如果顺着这个项目聊下去，往往会跳到另一个问题：“第三方接口除了慢，还会返回什么错误？你怎么设计补偿机制？”答案不能只是“catch 异常然后打印日志”。可以聊指数退避重试、定时任务扫表补偿、报警和死信队列，这才是有实战经验的人的回答。

4.4 Spring Boot 里的 JSON 处理：Jackson 的高频小坑

Spring Boot 默认使用 Jackson 做 JSON 序列化。看起来很简单，实际上里面积累了不少面试细节。比如后端返回的 Long 类型主键，到前端 JavaScript 里精度丢失。为什么？因为 JavaScript 的 Number 安全范围是 2^53 - 1，Java 的 Long 超过这个范围就会被四舍五入。解决方式一般是在字段上用 @JsonSerialize(using = ToStringSerializer.class)，更全局的方法是给 ObjectMapper 注册一个 Long 类型序列化器，把 Long 统一序列化为字符串。

另一个经典问题是 LocalDateTime 序列化。Java 8 时间类型如果没配依赖和格式，默认输出的格式是一串带 T 的 ISO 字符串，前端不一定需要这种格式。建议在配置里统一设置：

properties复制spring.jackson.date-format=yyyy-MM-dd HH:mm:ss
spring.jackson.time-zone=GMT+8

注意 spring.jackson.date-format 对 java.util.Date 有效，对 Java 8 时间类型不一定生效。更稳妥的是定义一个 Jackson2ObjectMapperBuilderCustomizer，给 ObjectMapper 注册 JavaTimeModule 和自定义的序列化器/反序列化器。

还有循环引用问题。如果实体类里 A 引用了 B，B 又引用了 A，直接序列化会抛异常。很多人用注解去标记忽略字段，比如 @JsonIgnore、@JsonIgnoreProperties，但真正的建议是：接口返回不要直接吐 JPA 实体，而是用 VO/DTO 做裁剪。一来避免循环引用，二来避免把不该暴露的字段（密码、手机号）直接丢到前端。

面试时如果问“Spring Boot 项目里 JSON 处理有哪些坑”，能够把这些细节都答出来，至少说明你在真实项目里被坑过，而不是只写过 CRUD。

5. 微服务架构：面试官想听的从来不是组件名

5.1 服务拆分：先想清楚“为什么”再谈技术选型

微服务面试里最常出现的一句话是：“你们为什么拆微服务？”如果答案只是“因为大厂都用”，那面试基本就废了。

做微服务架构要有一个底层认识：微服务的本质是把一个大团队、大代码库拆成可以独立开发、独立部署、独立扩展的小单元。它解决的核心问题有两类：一类是组织问题，多人团队在一个代码仓库提交、互相等待，导致发布效率低；另一类是容量问题，不同模块的流量特征差异大，比如商品浏览和订单支付流量差别很大，拆开后可以针对热点服务单独扩容。

因此，面试这么答会更好：先抛出单体应用遇到的三个具体瓶颈，比如发布互相阻塞、数据库连接被慢查询占满、团队边界不清晰；再说“我们判断这些问题无法在单体架构下继续优化”，于是按业务边界把系统拆成了用户、商品、订单、支付等微服务；最后补一句，拆服务是有代价的，增加了网络开销、数据一致性成本和运维复杂度，所以我们当时也保留了部分不必要拆的服务。

“不拆”的反例也很值得准备。如果你面试时大方承认某个模块没必要用微服务，这反而是加分项。现在面试官很怕遇见那种“不管三七二十一，全系统上 Nacos + Gateway + XXL-Job”的简历党。能说出“我们这里拆了反而亏”的候选人，通常才真做过架构取舍。

5.2 服务发现、配置中心和网关，背后都是“地址管理”

微服务架构里接入层的组件可以用一个主线串起来：解决“服务的调用方怎么找到服务提供方”的问题。

在单体时代，服务地址是写死的；在微服务时代，实例数量随弹性伸缩动态变化，IP 经常变，所以出现了注册中心。服务启动时把自身 IP + 端口注册上去，并定期发送心跳；调用方从注册中心拿可用实例列表，本地做负载均衡。选型上，Eureka 偏 AP，ZooKeeper 偏 CP，Nacos 则两者都支持。面试被问到“你们注册中心怎么选”时，可以结合业务是否需要强一致来判断。

配置中心解决的则是配置文件的地址管理。为什么配置不能继续放在每个服务自己的 application.yml 里？因为几十个服务要修改一个公共配置，得逐个改逐个发布，效率太低。引入配置中心后，配置统一存放，修改后能推送刷新。要注意的一点是，不是所有配置都适合进配置中心。数据库密码、开关类配置适合；而有些常量如果一年都不变，留在本地代码里可能更直观，免得配置中心网络抖动还影响启动。

网关解决的问题是流量入口的统一控制。Spring Cloud Gateway 是目前的主流方案，它负责路由转发、统一鉴权、限流、灰度发布。但很多公司会把网关当业务入口拼命加逻辑，这是大坑。网关应该尽量做通用的横切逻辑，比如 HTTP 头处理、登录 token 校验、路由转发，不要把每个业务的聚合逻辑都写进去，否则很容易变成一个“微服务里的巨型单体”。

5.3 容错三件套：超时、重试、熔断怎么组合才对

面到服务调用时，面试官总会抛出这么一个问题：“你的服务调第三方接口，接口一直慢，怎么办？”

初级答案：判 timeout，超时就返回失败。
中级答案：设置合理的读写超时，增加超时后的重试，重试前加上间隔。

但面试官如果继续追问“重试 N 次还是失败呢”，就得引入熔断了。熔断相当于家庭里的空气开关：电流持续过大，不是反复去尝试“合闸”，而是直接断开电路，保护整个线路。在微服务里，熔断器打开后，后续请求不再真正去调用下游，而是快速失败，给下游喘息恢复的时间。

再看降级——降级是在下游故障时，提供一个临时方案。比如推荐服务挂了，商品详情页的“为你推荐”模块可以显示缓存的旧数据，或者干脆不显示，不影响主流程。限流和降级常被混在一起说，区别是：限流是在系统入口处控制进入的流量，不让系统被压垮；降级是系统能力已经不足时，主动牺牲非核心功能，保住核心功能。

我把这几个概念放到一起对比一下：

真正有说服力的回答，是把这几个手段放进同一个场景中。比如：下单接口调用库存服务，库存服务偶发超时，我可以把单次超时时间设为 300ms，允许重试 1 次；连续 10 次失败就触发熔断，熔断 10 秒；熔断期间走本地缓存库存，允许扣减预估值，后续异步对账修正。这才是“组合使用容错方案”的能力。

5.4 分布式事务、幂等设计与链路追踪

分布式事务是微服务里比较让人头疼的问题。需要先理解：单体时代，一次操作可以包在本地事务里，ACID 没问题；微服务把表拆分到不同的服务，甚至不同的数据库，本地事务管不到别人家的事务，所以遇到“下单 + 扣库存 + 加积分”这种跨服务写操作，就要处理分布式事务。

面试中不应该把 Seata 或者 Saga 的细节狂背一气，而要先问一句：我真的需要强一致吗？大部分业务场景是可以妥协的，比如下单后扣库存，不要求两个服务同时提交，可以做成最终一致。可靠消息最终一致是工程上最常见也相对简单的方案：本地事务里先发一条消息到 MQ，消费者消费时执行扣库存；如果消费失败，MQ 会重试，同时记录日志做补偿。

还有些场景要求更高，比如账号系统转账，那就要考虑 TCC 或 Saga。TCC 的核心是 Try/Confirm/Cancel 三阶段，把资源预留和最终提交分离开来，复杂度和成本都比较高。Saga 则是一串本地事务，任何一个失败就倒序执行补偿动作。回答这类问题时，关键是给出取舍依据：一致性要求越高，方案越复杂，成本越高，所以先确认业务到底能不能接受短时间的中间状态。

服务调用还需要幂等。比如支付回调、订单创建这类操作，网络重发、消费者重复消费都可能导致同一请求被执行多次。一个实用的幂等设计是：每次请求带一个全局唯一 requestId，后端在处理前先查幂等表，如果已存在就直接返回之前的结果，同时幂等表里的唯一索引兜底并发场景。

最后是链路追踪。在微服务里，一次请求会经过网关、订单、支付、库存好几个服务，如果每个日志没有 ID，出问题后根本查不到一条完整的调用路径。所以业界标准是在请求入口生成 traceId，跨服务时通过 HTTP 头传递，再通过 spanId 记录每一跳的耗时。如果面试聊到这里，再补一句“我会把 traceId 放到 SLF4J 的 MDC 里，这样普通业务日志也能自动带上”，面试官就会知道你真的是在线上排查问题，而不是只看过文章。

6. Java 基础、算法与“八股文”的合理打开方式

6.1 八股文不是不能背，而是要能当成线索去追问

现在网上的“Java 面试八股文”“java 面试大全”特别多，很多人把它当题库来背，背到最后能说出结论，但没法给出理由。八股文本身没有错，它的价值是让你快速知道一个知识点在考试范围里存在；关键是背完之后，要针对每一个概念继续追问两层甚至三层。

举个例子，八股里常有一句“ApplicationContext 是 BeanFactory 的子接口，是 Spring 的 IoC 容器核心”。第二层问：那 IoC 容器默认的真正实现类是什么？很多项目里 Debug 会看到 DefaultListableBeanFactory，它才是真正干活的 BeanFactory。第三层问：ApplicationContext 相比 DefaultListableBeanFactory 扩展了什么？答案是在 BeanFactory 基础上增加了事件发布、资源加载、国际化、自动注册 BeanPostProcessor 等能力。如果能答到这个层次，面试官会认为你真是读过源码或者带着疑问去排过错。

一个比较实用的准备方法叫作“题库反推”：从面试题出发，把每个题目当成一个入口，去回答“这个技术解决什么问题、底层机制是什么、我在项目里怎么用、不用它会有什么后果”。每道题这样串四层，差不多就能覆盖面试真题中七成以上场景。

6.2 Java 基础高频细节：运算符、Lambda、集合中容易被忽视的逻辑

有些面试官会从一些很小的基础点切入，比如“i += 1 和 i = i + 1 有区别吗”“i++ 和 ++i 分别是怎么运算的”。这类题目看似简单，实际在考察你是否理解 Java 类型系统。

i += 1 会进行隐式强制转换，例如 short s = 1; s += 1; 可以编译；但 s = s + 1; 编译会报错，因为 s + 1 是 int 类型，赋给 short 需要强转。运算符优先级的题目也是同理，面试官不是在考四则运算，而是想看你能不能识别出代码里的危险性。实际工作中要避免靠人肉记忆优先级，复杂的条件里多打一对括号，比什么都稳。

Lambda 和 Stream 在新版本八股里是常客。Lambda 的本质是函数式接口的实例，它依赖 @FunctionalInterface 接口，比如 Runnable、Comparator、自定义的业务接口。很多人搞不懂为什么 Lambda 里不能修改外部局部变量，其实原理是局部变量存在于栈帧，线程安全无法保证，Java 设计时要求捕获的变量必须是 effectively final，所以你会看到匿名内部类和 Lambda 都有这种限制。

Stream 的高频考点是“中间操作和终止操作的区别”。filter、map、sorted 这类是中间操作，它们不会立即执行，只有当遇到 collect、forEach、count 等终止操作时才会真正遍历数据。这个特性带来了惰性求值的好处：可以链式组合，只处理必要的数据。不过也要小心，不要在终止操作里做耗时操作，比如在 forEach 里查数据库、发远程请求，会很容易把性能搞崩。

6.3 别只会背冒泡排序，要能说出它和实际场景的关系

“冒泡排序 Java”一直是搜索热词，原因主要是校招笔面试常让手写。但真正经验丰富的面试官，不会只看你能不能把冒泡排序默写出来，而是看你有没有优化意识。

基础版冒泡排序代码我就不贴了，太常见了。它的问题是外部 N 轮循环必须跑满，哪怕在第三轮就已经有序。优化点非常经典：在每一轮里记录是否有元素交换，如果没有发生交换，说明数组已经有序，直接终止，可以把最好情况复杂度优化到 O(n)。

再往深了问，面试官会问“你知道还有哪些排序吗？为什么工程里不直接手写排序而调用 Collections.sort 或 Arrays.sort？”说到这个我认为是重点。Java 的 Arrays.sort 对不同场景使用不同算法，比如基本类型用 Dual-Pivot Quicksort，对象类型用 TimSort。TimSort 结合了归并排序和插入排序，对部分有序的数据非常友好。一个合格的候选人能把这些细节讲清楚，而不是停留在“排序算法有几种、复杂度是多少”。

6.4 学习路线和项目自检：从能跑通到能上线还差几步

经常有人问我“Java 学习路线到底怎么走”。我一般给的建议路线是：Java SE 基础（语法、集合、IO、并发、JVM） → 数据库和 JDBC → Web 基础和 HTTP 协议 → Servlet 到 Spring/Spring Boot → 中间件（Redis、MQ、ES） → 微服务和容器化 → 源码和调优。

比学习路线更重要的，是对自己项目做“上线前自检”。如果你在简历里写了某个 Spring Boot 项目，建议按下面这个清单逐项过一遍：

• 能不能画出这个系统完整的架构图，包括 Nginx、网关、服务、数据库、缓存、消息队列都在哪些位置？
• 项目里有没有慢 SQL？有没有为查询字段建索引？
• 日志你是用 System.out.println 打的，还是用了统一格式、统一日志框架？
• 接口有没有考虑幂等性？比如支付回调、转账类接口，重复请求时会发生什么？
• 有没有防越权和防 SQL 注入的措施？
• 服务挂掉之后，监控能发现吗？报警谁会收到？
• 如果流量涨十倍，代码里的哪些薄弱点会先爆？

这八条每一条都展开讲过一轮之后，你再去面试，项目的追问链条会完整很多。因为面试官想看到的并不是“项目功能有多炫”，而是你有没有把代码当成一个要长期运行的系统来负责。

7. 线上故障与部署排查的经验实录