互联网大厂 Java 面试实录：Spring Boot、JVM、MyBatis、Redis、Kafka、Spring Cloud 场景化三轮追问

一、故事背景

某互联网大厂正在招聘一名 Java 后端开发工程师，业务方向是一个 AIGC 内容社区 + 电商带货平台。

这个平台的核心业务是：

• 用户可以发布图文、短视频、AI生成内容
• 内容可以被推荐、点赞、评论、收藏
• 热门内容会挂载商品链接进行带货
• 下单后会进入支付、库存、物流等流程
• 平台还需要支持大促活动、高并发、风控和监控告警

今天来面试的人，叫——谢飞机。

他自我介绍说：

“面试官您好，我精通 Java，熟悉 JVM，了解 Spring 全家桶，擅长解决各种线上疑难杂症。项目经验丰富，从内容社区到支付中台，从微服务到云原生，我都有深度参与。”

面试官抬头看了他一眼，缓缓说道：

“好，那我们开始。希望你说的深度参与，不是深度围观。”

谢飞机嘿嘿一笑：

“您放心，我属于那种出了问题第一时间在群里回复‘收到’的人。”

---

二、第一轮面试：AIGC 内容社区核心链路

场景：公司做的是一个 内容社区 + AIGC 创作平台。用户可以上传内容，也可以调用 AI 生成文案和图片。要求系统稳定、响应快，并支持高并发热点内容访问。

问题1：如果让你用 Spring Boot 设计一个内容发布接口，你会怎么做分层设计？

面试官： “先来个基础题。假设你负责内容发布模块，基于 Spring Boot + MyBatis + MySQL，你会怎么做接口分层设计？”

谢飞机： “这个很简单，就是 Controller 接请求，Service 处理业务，Mapper 操作数据库。然后就差不多了。”

面试官： “继续。比如参数校验、事务、异常、幂等、日志这些放哪？”

谢飞机： “呃……校验一般放前端，后端也可以象征性校验一下。事务嘛，加个 @Transactional 就很稳。日志的话……System.out 我平时也打得挺顺手。”

面试官： “至少主干答到了，基础还行。那我帮你补充一下，我们继续。”

---

问题2：内容发布后，首页推荐流量很大，Redis 缓存怎么设计？

面试官： “内容发出去以后，首页推荐流会非常热。你怎么用 Redis 设计缓存？要考虑缓存穿透、击穿、雪崩。”

谢飞机： “Redis 当然要上。一般就是查数据库前先查 Redis，没有就查库再回写缓存。穿透的话……可以多查几次？击穿的话……那就说明流量太大了。雪崩的话，可以让运维顶一下。”

面试官： “你这个回答很有生活气息，但不太有技术气息。”

谢飞机： “老师，我其实想说布隆过滤器来着，只是想铺垫一下情绪。”

面试官： “行，还知道布隆过滤器，不错。那继续往下。”

---

问题3：AIGC 生成内容是异步任务，你会如何设计？

面试官： “用户提交一个‘生成爆款文案’请求，可能几十秒才能完成。你怎么设计？同步阻塞肯定不行。”

谢飞机： “这个我知道，异步。前端先转圈，然后后端慢慢生成。技术上可以开个线程，或者 new 一个线程池。再高级一点……上消息队列，比如 Kafka、RabbitMQ 都行。”

面试官： “嗯，这次答得还不错。那如果生成任务失败、重复消费、状态追踪，你怎么做？”

谢飞机： “状态就建表，失败就重试，重复消费就别让它重复……这个主要看团队配合。”

面试官： “你每次一到关键点就开始团队配合。”

---

问题4：JVM 层面，如果这个服务频繁 Full GC，你怎么排查？

面试官： “线上内容服务响应变慢，发现 Full GC 频繁。你怎么分析？”

谢飞机： “这个我会。先看日志，再看监控，再 dump 一下。一般就是对象太多了，或者内存不够了。我们可以调大堆。”

面试官： “思路方向是对的。那你知道常见要看哪些指标吗？”

谢飞机： “看那个……年轻代、老年代、对象分配、GC 次数、停顿时间。还有如果实在不行，就重启，属于最快止血方案。”

面试官： “最后一句你倒是很诚实。”

---

三、第二轮面试：电商带货与交易链路

场景升级：热门内容会挂载商品，用户点击后会进入商品详情、下单、支付。此时系统从内容社区拓展到交易系统，需要考虑分库分表、库存一致性、消息可靠性和接口安全。

问题1：商品详情页高并发访问，你会怎么做性能优化？

面试官： “现在内容爆了，一条热门视频挂了商品链接，商品详情页 QPS 突增。你怎么优化？”

谢飞机： “先加缓存，Redis 肯定要有。再加 Nginx，实在不行多扩几台机器。数据库压力大就主从。”

面试官： “还可以。那商品详情的数据有价格、库存、营销标签、评价摘要，这些更新频率不同，缓存怎么拆？”

谢飞机： “呃……可以拆成多个 key。比如 price 一个，stock 一个，comment 一个。这样听起来就很专业。”

面试官： “这次不只是听起来，方向也确实对。”

---

问题2：下单扣库存，怎么避免超卖？

面试官： “这是经典题。假设是秒杀活动，怎么避免超卖？”

谢飞机： “数据库加锁，或者 Redis 扣减。也可以乐观锁。总之不能让大家一起扣。”

面试官： “如果 Redis 先扣成功，数据库扣失败怎么办？”

谢飞机： “那就……补回来？或者发个消息补偿。”

面试官： “嗯，至少知道补偿思路。继续。”

---

问题3：支付成功后，订单、积分、优惠券、物流通知如何解耦？

面试官： “支付成功后要做很多事：订单改状态、发积分、扣优惠券、通知仓储。你怎么设计？”

谢飞机： “这种最适合用 Kafka 或 RabbitMQ。支付服务发一个支付成功消息，其他服务各自消费。这样就解耦了。”

面试官： “如果消息重复、消息丢失、消费失败怎么办？”

谢飞机： “重复就幂等，丢失就重发，失败就重试。这个我平时说得很多。”

面试官： “你确实总结得很像周报。”

---

问题4：微服务之间调用，你会选 OpenFeign 还是 gRPC？

面试官： “订单服务要调用商品服务、用户服务、营销服务。你会怎么选？OpenFeign 还是 gRPC？”

谢飞机： “如果公司是 Spring Cloud 体系，那我倾向 OpenFeign，上手快。gRPC 性能高，适合内部高性能调用。看业务选。”

面试官： “不错，这题答得可以。那服务治理怎么做？”

谢飞机： “注册发现、熔断限流、超时重试、链路追踪。比如 Eureka、Consul、Resilience4j、Jaeger、Zipkin 这些。”

面试官： “可以，这轮比上一轮强。”

---

四、第三轮面试：云原生、安全与可观测性

场景继续升级：平台已经是微服务架构，部署在 Docker + Kubernetes 上。为了应对活动流量、攻击风险、线上故障，需要候选人具备云原生、安全、监控排障能力。

问题1：如果你来做这个系统的 CI/CD，你会怎么设计？

面试官： “公司要求开发提交代码后，自动完成构建、测试、打包镜像、部署测试环境。你怎么做？”

谢飞机： “这个简单，Git 提交后 Jenkins 跑一下 Maven，打成 Jar，再做 Docker 镜像，推到仓库，然后 Kubernetes 部署。”

面试官： “那自动化测试、灰度发布、回滚呢？”

谢飞机： “测试可以接 JUnit 5、Mockito。灰度的话分批发布，回滚就回滚上一个版本。这个理念我是有的。”

面试官： “‘理念我是有的’——很危险的回答。”

---

问题2：登录鉴权你怎么设计？JWT、OAuth2、Spring Security 分别适合什么场景？

面试官： “平台既有 C 端 App，也有管理后台，还有第三方商家系统接入。认证授权你怎么设计？”

谢飞机： “Spring Security 做认证授权，JWT 做无状态登录，OAuth2 适合第三方授权登录。后台可以 RBAC 权限控制。”

面试官： “那 JWT 有什么问题？”

谢飞机： “它……一旦发出去，不太好撤销。还有 token 太大也会有点影响。一般可以配 Redis 黑名单或者缩短有效期。”

面试官： “这题回答得不错。”

---

问题3：线上如何做监控与链路追踪？

面试官： “如果用户反馈下单很慢，但你不知道慢在哪，你怎么排查？”

谢飞机： “先看监控。Prometheus 采集指标，Grafana 做看板，Micrometer 暴露业务指标。日志可以进 ELK。链路追踪看 Jaeger 或 Zipkin。”

面试官： “那你会关注哪些指标？”

谢飞机： “接口 RT、QPS、错误率、JVM 内存、GC、线程池、数据库连接池、Redis 命中率、Kafka 消费堆积这些。”

面试官： “可以，这题挺扎实。”

---

问题4：如果某个热点活动把系统打挂了，你会怎么做应急处理？

面试官： “最后一道综合题。假设一个明星直播带货，瞬间把系统流量打爆，订单服务开始超时，缓存也扛不住，你怎么处理？”

谢飞机： “先限流、降级、熔断，保核心链路。非核心功能比如评论、推荐、个性化先降级。再扩容服务，检查 Redis 和数据库负载，必要时做静态化和本地缓存。”

面试官： “还有呢？”

谢飞机： “再看看 MQ 有没有堆积，线程池有没有打满，连接池有没有耗尽。最后复盘，避免下次又挂。”

面试官： “很好，这题答得比我预期好。”

谢飞机： “谢谢老师，主要是这种场景我虽然没亲手解决过，但在故障群里见过。”

面试官： “……这倒也算一种参与。”

---

五、面试结束

面试官合上简历，语气平静地说道：

“今天先到这里。你的基础题还可以，部分场景题也有思路，但在复杂系统设计、分布式一致性、消息可靠性和线上排障细节方面，还需要继续加强。”

谢飞机立刻点头：

“明白，我回去就把这些知识点从‘听说过’升级到‘能说明白’。”

面试官说道：

“好，你先回去等通知。如果后续有进展，HR 会联系你。”

谢飞机起身鞠躬：

“好的老师。如果没进展，我也会继续努力，争取以后从‘回去等通知’进化到‘下周来入职’。”

---

六、问题详细答案解析

下面把上面所有问题做一次系统化拆解，帮助小白理解：为什么这么问、业务场景是什么、标准答案应该怎么答。

---

第一轮答案解析：AIGC 内容社区核心链路

1. Spring Boot 内容发布接口如何分层设计？

业务场景

用户在内容社区发布一篇图文或视频简介，后端需要：

• 校验参数是否合法
• 保存内容主表
• 保存标签、话题、媒体信息
• 记录发布日志
• 可能触发审核或推荐流程

推荐分层

常见的后端分层：

1. Controller 层

   • 接收 HTTP 请求
   • 做参数绑定
   • 返回统一响应结果
   • 不写复杂业务逻辑

2. Service 层

   • 编排业务流程
   • 处理事务
   • 调用多个 Mapper / Repository
   • 触发异步事件

3. Mapper / DAO 层

   • 负责数据库访问
   • MyBatis 编写 SQL
   • JPA/Hibernate 也可以用于简单数据操作

4. Domain / Entity / DTO / VO

   • DTO：接收前端参数
   • Entity：数据库实体
   • VO：返回前端展示对象
   • 可以配合 MapStruct 做对象转换

补充关键点

• 参数校验：用 JSR-303/380 注解，比如 @NotNull、@Size
• 统一异常处理：用 @RestControllerAdvice
• 统一日志：用 SLF4J + Logback/Log4j2
• 事务管理：发布内容主表和附属表时用 @Transactional
• 幂等设计：前端提交时加 requestId，避免重复提交
• 审计字段：创建人、创建时间、修改时间

示例流程

1. Controller 接收发布请求
2. 校验标题、内容、标签数量
3. Service 保存内容表
4. Service 保存标签映射表
5. 发送消息给审核服务 / 推荐服务
6. 返回内容 ID

---

2. Redis 缓存如何设计，如何解决穿透、击穿、雪崩？

业务场景

首页推荐流中，热门内容会被频繁访问。如果每次都查 MySQL，会把数据库打爆。

基本缓存模型

访问流程：

1. 先查 Redis
2. Redis 没有，再查 MySQL
3. 查到后写回 Redis
4. 下次直接走缓存

三大问题

1）缓存穿透

定义：查询一个根本不存在的数据，Redis 没有，数据库也没有，请求每次都打到数据库。

解决方案：

• 布隆过滤器：预先判断 key 是否可能存在
• 缓存空值：数据库查不到时，也缓存一个短期空对象
• 接口参数合法性校验：非法 ID 直接拦截

2）缓存击穿

定义：某个热点 key 突然过期，大量请求同时打到数据库。

解决方案：

• 热点 key 永不过期 + 逻辑过期
• 互斥锁 / 分布式锁：只让一个线程回源数据库
• 本地缓存 + Redis 多级缓存

3）缓存雪崩

定义：大量 key 同时过期，导致大量请求同时回源数据库。

解决方案：

• 设置 随机过期时间，避免同一时刻失效
• 做 多级缓存
• 高可用 Redis 集群
• 服务降级与限流

实际设计建议

• 内容详情：content:detail:{id}
• 点赞数：content:like:{id}
• 评论数：content:comment:{id}
• 推荐流列表：feed:user:{userId} 或 feed:hot

如果是热点内容，可以：

• 用 Caffeine + Redis 组成本地缓存 + 分布式缓存
• 配合 Spring Cache 简化缓存代码

---

3. AIGC 生成内容的异步任务怎么设计？

业务场景

用户点击“生成小红书风格文案”，AI 生成可能需要 10~30 秒。如果接口同步等待，会导致：

• 用户体验差
• 请求超时
• Tomcat/Netty 线程长时间占用

推荐设计

采用 异步任务模型：

1. 用户提交生成请求
2. 服务快速返回一个 taskId
3. 后端把任务写入数据库 / MQ
4. AI 任务消费者异步处理
5. 任务完成后更新状态：PENDING / RUNNING / SUCCESS / FAILED
6. 前端轮询查询结果，或通过 WebSocket 推送结果

可选技术方案

• 简单场景：@Async + 线程池
• 中大型场景：Kafka / RabbitMQ / Pulsar
• 高吞吐异步编排：Kafka 更常见
• 状态存储：MySQL / Redis

任务表设计示例

字段可包括：

• task_id
• user_id
• prompt
• status
• result_content
• error_msg
• retry_count
• create_time
• update_time

核心问题

• 失败重试：限定重试次数，防止死循环
• 幂等消费：根据 taskId 保证重复消息不会重复执行
• 超时控制：任务长时间无结果需要标记失败
• 消息可靠性：发送确认、消费确认、死信队列

---

4. JVM 频繁 Full GC 如何排查？

常见原因

• 内存设置不合理
• 大对象频繁创建
• 老年代对象堆积
• 内存泄漏
• 缓存使用不当
• 线程池堆积大量任务对象

排查步骤

1. 看监控

   • 堆内存使用率
   • Full GC 次数
   • GC 停顿时间
   • Old 区使用变化

2. 看 GC 日志

   • Java 8 常加：-XX:+PrintGCDetails -Xloggc:gc.log
   • Java 11/17 可用统一日志：-Xlog:gc*

3. 分析堆转储文件

   • 使用 jmap 导出 dump
   • 用 MAT、VisualVM、JProfiler 分析大对象和引用链

4. 定位代码问题

   • 是否有大集合未释放
   • 是否有缓存 key 设计不合理
   • 是否有 ThreadLocal 未清理
   • 是否有连接对象泄漏

JVM 关注指标

• Young GC / Full GC 次数
• GC pause time
• Eden / Survivor / Old 使用率
• 对象晋升速度
• Metaspace 使用率
• 线程数量

解决思路

• 优化对象创建，减少临时对象
• 调整堆大小、新生代比例
• 更换合适 GC，如 G1
• 规范缓存容量
• 排查内存泄漏

---

第二轮答案解析：电商带货与交易链路

5. 商品详情页高并发访问怎么优化？

业务场景

一条热门视频带火商品，大量用户同时访问商品详情页。页面数据来源复杂：

• 商品基础信息
• 实时价格
• 实时库存
• 营销活动信息
• 用户评价摘要

优化方案

1. 多级缓存

   • 本地缓存：Caffeine
   • 分布式缓存：Redis
   • 静态资源走 CDN

2. 缓存拆分 不同数据更新频率不同，应拆开缓存：

   • 商品基础信息：更新少，缓存时间长
   • 价格：更新中等
   • 库存：更新频繁，可短缓存甚至不直接缓存最终值
   • 评论摘要：异步聚合

3. 读写分离

   • MySQL 主从架构
   • 详情查询走从库

4. 接口聚合

   • 用聚合服务组装详情，避免前端多次请求

5. 热点隔离

   • 热门商品单独做缓存预热
   • 必要时做专门热点服务

---

6. 下单扣库存如何避免超卖？

超卖原因

多个请求同时读取到同样的库存值，然后都成功扣减。

常见方案

1）数据库乐观锁

库存表增加 version 字段：

update stock
set count = count - 1, version = version + 1
where product_id = ? and count > 0 and version = ?

适合并发不是极端高的场景。

2）悲观锁

用 select ... for update 锁行。 适合强一致，但吞吐较低。

3）Redis 预扣库存

高并发秒杀场景常用：

• 先在 Redis 中原子扣减
• 扣减成功后异步下单
• 最终数据库落库

可用 Lua 脚本保证原子性。

Redis 扣成功、数据库失败怎么办？

这就是最终一致性问题。

解决方式：

• 发送补偿消息，把 Redis 库存加回去
• 订单创建失败回滚库存
• 定时任务对账修正库存

推荐思路

• 普通电商：数据库乐观锁足够
• 秒杀/直播带货：Redis 预扣 + MQ 异步创建订单 + 补偿机制

---

7. 支付成功后如何解耦订单、积分、优惠券、物流？

业务场景

支付完成后会触发很多后续动作：

• 订单状态更新
• 积分发放
• 优惠券核销
• 仓储发货通知
• 用户消息通知

如果这些都写在支付服务里：

• 服务耦合严重
• 修改风险大
• 一个下游失败会拖慢整个链路

正确做法：事件驱动 + 消息队列

流程：

1. 支付服务确认支付成功
2. 发送 PAY_SUCCESS 消息到 Kafka / RabbitMQ
3. 订单服务消费消息更新订单状态
4. 积分服务消费后发积分
5. 营销服务消费后核销优惠券
6. 物流服务消费后创建发货单

核心问题

1）消息重复

原因：生产者重发、消费者重试

解决：消费幂等

• 用业务唯一 ID 去重
• 建消费记录表
• 利用 Redis setnx

2）消息丢失

解决：

• 生产者发送确认
• Broker 持久化
• 消费者手动 ack
• 失败进入重试 / 死信队列

3）消费失败

解决：

• 重试机制
• 死信队列
• 人工补偿

---

8. 微服务调用选 OpenFeign 还是 gRPC？

OpenFeign 适用场景

• 基于 Spring Cloud 体系
• HTTP/JSON 调用
• 上手快，开发效率高
• 适合后台管理、电商常规服务调用

gRPC 适用场景

• 高性能内部 RPC
• 跨语言调用
• 强接口约束，基于 Protobuf
• 更适合低延迟、高吞吐场景

对比总结

| 维度 | OpenFeign | gRPC | |---|---|---| | 协议 | HTTP/1.1 或 HTTP/2 | HTTP/2 | | 数据格式 | JSON | Protobuf | | 开发门槛 | 低 | 中 | | 性能 | 一般 | 更高 | | 可读性 | 好 | 一般 | | 跨语言 | 可以 | 更强 |

服务治理配套

• 注册发现：Eureka / Consul
• 熔断限流：Resilience4j
• 网关：Zuul（旧）、Spring Cloud Gateway
• 配置中心：Spring Cloud Config / Consul
• 链路追踪：Jaeger / Zipkin

---

第三轮答案解析：云原生、安全与可观测性

9. CI/CD 如何设计？

目标

开发提交代码后，自动完成：

• 编译
• 单元测试
• 代码扫描
• 打包
• 镜像构建
• 推送镜像仓库
• 部署测试环境

标准流程

1. 开发提交代码到 Git
2. Jenkins / GitLab CI / GitHub Actions 触发流水线
3. 执行 Maven/Gradle 构建
4. 跑 JUnit 5、Mockito 测试
5. 生成 Jar
6. 构建 Docker 镜像
7. 推送 Harbor / Docker Registry
8. 更新 Kubernetes Deployment
9. 发布测试环境
10. 验证通过后再发布生产

进阶能力

• 灰度发布
• 蓝绿发布
• 金丝雀发布
• 自动回滚
• 质量门禁

---

10. JWT、OAuth2、Spring Security 分别适合什么场景？

Spring Security

是 Java 最主流的安全框架，用于：

• 登录认证
• 权限控制
• 过滤器链扩展
• 接入 JWT / OAuth2

JWT

JSON Web Token，适合：

• 前后端分离
• App / 网关鉴权
• 无状态认证

优点：

• 服务端不用保存 session
• 适合分布式系统

缺点：

• 签发后不好主动失效
• token 泄露风险高
• 内容太大影响传输

OAuth2

适合：

• 第三方授权登录
• 第三方系统接入
• 统一身份认证平台

例如：

• 商家系统接入平台
• 使用 Keycloak 做统一认证中心

实际组合

• C 端用户登录：Spring Security + JWT
• 后台权限管理：Spring Security + RBAC
• 第三方开放平台：OAuth2 / OIDC + Keycloak

---

11. 线上监控与链路追踪怎么做？

三大观测维度

1. Metrics 指标
2. Logs 日志
3. Traces 链路

常见技术组合

• Prometheus：采集指标
• Grafana：展示看板
• Micrometer：Spring Boot 指标埋点
• ELK Stack：日志检索分析
• Jaeger / Zipkin：链路追踪

重点监控指标

应用层

• QPS
• RT
• 错误率
• 成功率

JVM 层

• 堆内存
• GC 次数
• GC 停顿
• 线程数

中间件层

• MySQL 慢查询
• 连接池使用率（HikariCP）
• Redis 命中率
• Kafka 消费堆积

业务层

• 下单成功率
• 支付成功率
• AIGC 任务成功率
• 推荐接口超时率

排查思路

用户说“下单慢”：

1. 先看 Grafana 是否整体 RT 飙高
2. 看 Jaeger 链路哪一跳最慢
3. 查 ELK 日志是否报错
4. 查数据库、Redis、MQ 指标是否异常
5. 看线程池和连接池是否耗尽

---

12. 热点活动把系统打挂了怎么应急？

核心原则

先止血，再恢复，再复盘。

止血措施

1. 限流

   • 网关限流
   • 接口限流
   • 用户维度限流

2. 降级

   • 关闭非核心功能
   • 推荐、评论、画像延迟处理
   • 保住下单、支付主链路

3. 熔断

   • 下游故障时快速失败
   • 防止故障扩散

4. 扩容

   • Kubernetes 水平扩容 Pod
   • 增加消费者实例

5. 缓存兜底

   • 热点数据预热
   • 静态化页面
   • 本地缓存临时兜底

进一步排查

• Redis 是否 CPU 飙高
• 数据库连接池是否打满
• MQ 是否堆积
• 线程池队列是否满
• 外部依赖是否超时

事后复盘

• 容量评估是否不足
• 压测是否覆盖真实场景
• 限流阈值是否合理
• 监控告警是否及时
• 是否缺少预案与自动扩容

---

七、适合继续扩展学习的技术栈清单

如果你想把这篇文章里的知识继续深入，可以按下面顺序学：

1. Java 基础与 JVM

   • Java 8/11/17 新特性
   • 类加载机制
   • 垃圾回收器 G1、ZGC 基础

2. Spring 生态

   • Spring Boot
   • Spring MVC
   • Spring Security
   • Spring Cache
   • Spring Cloud

3. 数据库与缓存

   • MySQL 索引、事务、锁
   • MyBatis / JPA
   • Redis 数据结构与高可用

4. 消息队列

   • Kafka
   • RabbitMQ
   • 消息可靠性与幂等

5. 微服务与云原生

   • OpenFeign
   • Resilience4j
   • Docker
   • Kubernetes

6. 监控与运维

   • Prometheus
   • Grafana
   • ELK
   • Jaeger

---

八、总结

这场面试本质上考察的是三件事：

1. 你是否真的掌握 Java 后端基本功

   • Java、JVM、Spring Boot、MyBatis、Redis、MQ

2. 你是否能把技术放到业务场景中回答

   • 内容社区、AIGC、电商下单、支付链路、高并发活动

3. 你是否具备工程化思维

   • 微服务、监控、限流、降级、CI/CD、安全设计

谢飞机的问题在于：

• 简单题能答到主干
• 一到复杂场景就开始“看团队配合”
• 知道关键词，但细节不扎实

这也是很多面试者的真实状态：

不是完全不会，而是会得不够系统，答得不够落地。

如果你能把本文后面的答案真正吃透，再结合自己的项目经历进行整理，那么在互联网大厂 Java 面试里，面对大多数场景化提问，就不会只剩下“老师这个我了解一点”。

愿你下一次面试时，不做“谢飞机”，而是做那个能把问题讲透、把系统设计讲清楚的人。