严肃面试官 vs 搞笑“水货”谢飞机：Java 大厂三轮面试实录（含超详细答案）

严肃面试官 vs 搞笑“水货”谢飞机：Java 大厂三轮面试实录（含超详细答案）

——一场有笑点也有知识点的面试实录，文末附详细解析，保姆级带你复盘15个高频技术点。

开场

面试官（冷峻）：我们按真实业务链路来聊，三轮面试，每轮几个问题，跟着场景走。

谢飞机（挠头）：好的好的，我热身就绪，只要不问太难的，我都行！

面试官（淡定）：开始。

第一轮（场景：商品列表与并发基础）

背景：你负责“商品列表服务”，需要高性能查询、排序与缓存，服务并发访问量较高。

1）面试官：ArrayList 是怎么扩容的？fail-fast 产生的原因呢？

• 谢飞机：初始就很大，然后不够就翻倍吧？迭代器一边遍历一边改会报错，是因为它生气了。
• 面试官：嗯……有点方向。继续。

2）面试官：HashMap 的寻址、扩容、树化阈值？并发场景会出什么问题？

• 谢飞机：下标就是 hash%size，超过8就树化，线程多就大家排队用吧，问题不大。
• 面试官：先记一下问题大。

3）面试官：volatile 和 synchronized 的区别？在商品列表里哪个更合适？

• 谢飞机：volatile 让变量更“鲜活”，synchronized 是锁门。列表嘛，用 volatile 就完事了！
• 面试官：场景选择要谨慎。

4）面试官：线程池核心参数怎么配？拒绝策略怎么选？

• 谢飞机：核心线程 100，最大 1000，队列越大越稳，拒绝策略随缘吧。
• 面试官：别随缘。

5）面试官：JUC 里 CountDownLatch/CyclicBarrier/Semaphore 的区别？CAS 有哪些坑？

• 谢飞机：Latch 倒计时，Barrier 大家一起出发，Semaphore 像限流阀。CAS 就是“看心情自旋”。
• 面试官：嗯，这题答得还行。

第二轮（场景：下单与微服务治理）

背景：用户下单 -> 订单服务调用库存、营销、支付等微服务，链路长且有消息、缓存与任务调度。

1）面试官：说说 SpringBoot 自动装配的原理，再顺带谈谈 Bean 生命周期与循环依赖的处理。

• 谢飞机：SpringBoot 会“自己配自己”，Bean 先出生后工作，循环依赖我一般重启 IDEA。
• 面试官：重启不是答案。

2）面试官：MyBatis 的一级二级缓存机制是怎样的？如何避免 N+1 查询问题？

• 谢飞机：一级缓存很猛，二级缓存更猛，N+1 就 N 次 + 1 次嘛，忍一忍就过去了。
• 面试官：别忍。

3）面试官：Dubbo 超时与重试怎么配置？为什么幂等很重要？

• 谢飞机：超时就多试几次，幂等嘛，反正多扣几次钱也不是我的卡。
• 面试官：这卡要是你领导的呢？

4）面试官：RabbitMQ 如何保证消息可靠投递与消费端幂等？还能保证严格有序吗？

• 谢飞机：开个事务就“绝对一次”，顺序也“绝对”没问题！
• 面试官：绝对这两个字慎用。

5）面试官：xxl-job 在大促前如何进行分片与幂等处理？失败与告警怎么设计？

• 谢飞机：我设成每天凌晨三点跑，失败我就等它下次再跑。
• 面试官：大促等你下次，早黄了。

第三轮（场景：稳定性与性能治理）

背景：系统高峰期抖动、RT 飙升、偶发超时和错误，需要系统性排查与治理。

1）面试官：G1 与 CMS 的差异？线上频繁 Full GC 怎么快速定位？

• 谢飞机：Full GC 就是“满了清”，我一般重启服务器。
• 面试官：上线改配置比重启更保险。

2）面试官：Redis 的缓存雪崩、穿透、击穿与热点 Key，你如何兜底？

• 谢飞机：内存多加点就行，最不济 set 成永不过期。
• 面试官：永不过期是埋雷。

3）面试官：MySQL 索引与锁，如何避免回表与幻读？

• 谢飞机：select * 走心就行，幻读嘛，见怪不怪。
• 面试官：SQL 也要讲科学。

4）面试官：Linux + Docker 容器 CPU 飙高、内存 OOM 你怎么定位？

• 谢飞机：top 看一眼，感觉不对就 docker restart。
• 面试官：先别手欠。

5）面试官：在“订单与营销”场景里，如何用 DDD 划分限界上下文，并用设计模式实现优惠策略？

• 谢飞机：DDD 是“多多多开发”，策略嘛，写 if-else 就完事。
• 面试官：if-else 也要讲究艺术。

面试官（收尾）：今天先到这，回去等通知，结果会邮件告知。

谢飞机（小声）：能不能现在就通知……

面试题详解（按轮次/题号）

以下为每个问题的标准思路+实践要点，面向新手也尽量写清楚：

第一轮：商品列表与并发基础

1）ArrayList 扩容与 fail-fast

• 初始容量：JDK8 懒加载，首次 add 时容量变为 10；如果构造时给定初始容量则按指定容量。
• 扩容公式：newCapacity = old + (old >> 1)，即 1.5 倍扩容；底层是复制到新数组。
• fail-fast：迭代器内部保存 modCount（结构性修改计数），遍历时发现 modCount 变化就抛 ConcurrentModificationException；是“快速失败”，目的在于尽早暴露并发修改问题。
• 线程安全：ArrayList 非线程安全，多线程写用 CopyOnWriteArrayList（读多写少）或外部同步，或改用并发容器。

2）HashMap 寻址、扩容与并发问题

• 寻址：index = (n - 1) & spread(hash)；n 为 table 长度，要求 2 的幂，位运算比取模快。
• 扩容：阈值 threshold = capacity * loadFactor（默认 0.75），扩容时元素 rehash 到新表。
• 树化：当桶内链表长度 >= 8 且表容量 >= 64 时树化为红黑树，减小查询退化；过小容量时优先扩容而非树化。
• 并发风险：JDK7 扩容可能形成环形链表导致死循环；多线程 put 可能数据丢失/覆盖。解决：在并发写场景使用 ConcurrentHashMap（分段/Node+CAS+红黑树）或外部锁。

3）volatile vs synchronized 以及场景

• volatile：只保证可见性与有序性（通过内存屏障），不保证复合操作原子性（如 i++）。适合状态标志、配置刷新等。
• synchronized：互斥+可见性，进入/退出临界区有内存语义，支持可重入与锁升级（偏向->轻量级->重量级）。适合需要原子性保护的临界区。
• 场景建议：商品列表里的“开关/版本号”等用 volatile；统计计数/缓存更新等需要原子性则用锁或原子类。

4）线程池核心参数与拒绝策略

• ThreadPoolExecutor(核心数, 最大数, 存活时间, 时间单位, 工作队列, 线程工厂, 拒绝策略)。
• 常见队列：
  • SynchronousQueue（直接移交，适合短任务高吞吐，如异步网关）。
  • LinkedBlockingQueue（默认无界，易撑爆内存，生产不建议无界）。
  • ArrayBlockingQueue（有界，稳定背压）。
• 拒绝策略：Abort（抛异常）、CallerRuns（调用方执行，反压）、Discard/DiscardOldest（丢弃）。生产多用有界队列+CallerRuns。
• 参数估算：CPU 密集型≈CPU 核数+1；IO 密集型≈CPU 核数×(1+平均等待/平均计算)。统一命名线程、预热核心线程、采集队列堆积指标。

5）JUC 常用同步器与 CAS 注意点

• CountDownLatch：一次性“闸门”，等待多个任务完成再继续。
• CyclicBarrier：可循环“栅栏”，一批线程相互等待后再同时出发。
• Semaphore：信号量限流，控制并发度。
• CAS：比较并交换，需注意 ABA 问题（可用带版本戳的 AtomicStampedReference）；自旋开销需结合回退+限时；长时间竞争用锁更合适。

第二轮：下单与微服务治理

1）SpringBoot 自动装配、Bean 生命周期与循环依赖

• 自动装配：@SpringBootApplication => @EnableAutoConfiguration；Spring Boot 通过 AutoConfiguration 导入（JDK8 起从 META-INF/spring.factories 逐步迁移到 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports），结合 @ConditionalXxx 条件注解按需装配。
• Bean 生命周期（简化）：实例化 -> 属性填充 -> 调用 Aware -> BeanPostProcessor(before) -> 初始化（@PostConstruct/InitializingBean）-> BeanPostProcessor(after) -> 就绪 -> 销毁回调。
• 循环依赖：
  • 单例 setter 注入可通过三级缓存（singletonObjects/earlySingletonObjects/singletonFactories）解决。
  • 构造器注入循环默认无法解决，建议打破循环：@Lazy、事件解耦、抽取接口、重构依赖方向。

2）MyBatis 缓存与 N+1

• 一级缓存：SqlSession 级别，同一会话、相同语句与参数命中；提交/关闭/更新会清空。
• 二级缓存：Mapper 级别，需开启且对象可序列化；注意与本地缓存一致性与失效策略（flushCache）。
• 避免 N+1：
  • 使用 join 或 IN 批量查询一次拿全；
  • 使用 resultMap 的 association/collection 做嵌套映射（合理设置 fetchType）；
  • 结合分页避免一次拿太多。

3）Dubbo 超时、重试与幂等

• 超时 timeout：方法/接口/全局可配，单位毫秒；区分调用方超时与提供方业务超时。
• 重试 retries：Failover 会对读类/幂等接口重试（默认 2 次），写类/非幂等接口用 Failfast 禁止重试，避免“扣费多次”。
• 幂等实现：业务层基于唯一业务键去重（如订单号）、幂等表、去重缓存；接口侧可加防重 Token、乐观锁或唯一约束。
• 负载与集群：随机/轮询/最少活跃等；集群策略有 Failover/Failfast/Failsafe/Failback/Forking，按场景选择。

4）RabbitMQ 可靠投递、消费幂等与有序性

• 生产端：开启 Publisher Confirm（confirmSelect）+ Return（mandatory）+ 持久化（deliveryMode=2，持久 exchange/queue）+ 重试与退避。
• 消费端：手动 ack，失败 nack/requeue 或投递到死信队列；消费幂等可用去重表/Redis set（幂等键=消息ID/业务键）。
• 顺序性：单分区（单 queue 单消费）可保证局部顺序；全局严格有序代价高，通常通过“按键路由+单线程处理”实现局部有序。
• 语义：常见是至少一次（at-least-once）；精确一次（exactly-once）需要端到端事务或幂等业务抵消，复杂且成本高。

5）xxl-job 分片、幂等与告警

• 分片广播：同一任务按分片序号与总片数拆分并行，处理大批量数据需“按范围/哈希分片”。
• 幂等：分片参数入库作为幂等键，或对处理记录打“已处理”标记；任务重试前先检查状态。
• 失败与告警：合理设置失败重试与超时；接入钉钉/企业微信/短信告警；重要任务接入熔断/降级。
• 调度：避开凌晨统一时点，打散调度时间；对长任务设置拆分与断点续跑。

第三轮：稳定性与性能治理

1）G1 vs CMS 与 Full GC 排查

• CMS：并发标记-清除，停顿短，但会有内存碎片与 Concurrent Mode Failure 风险。
• G1：基于 Region，按停顿时间模型做 Mixed GC，能预测停顿；减少碎片，适合大内存。
• 常见 Full GC 触发：
  • 元空间不足（类加载过多/泄漏）；
  • Promotion failed/To-space exhausted；
  • System.gc() 被显式调用；
  • 大对象直接进老年代过多。
• 排查手段：
  • 开 GC 日志（Xlog:gc*），用 gceasy/GCViewer 分析；
  • jstat -gc/-gccause, jmap -histo, jcmd GC.class_histogram；
  • 采集分代使用率、晋升失败、停顿耗时；
  • 临时缓解：增加堆/元空间、降并发、限流；根因：修代码/减少类加载/优化对象生命周期。

2）Redis 雪崩、穿透、击穿与热点

• 穿透：访问不存在 key，打穿到 DB。方案：布隆过滤器、空值缓存（短 TTL）。
• 雪崩：同一时间大量 key 过期。方案：过期时间加随机抖动、预热、限流降级、分级缓存。
• 击穿：热点 key 失效瞬间大量请求打 DB。方案：互斥锁/单线程加载、逻辑过期+后台刷新、热点副本。
• 热点预案：预热、拆分大 key、分片路由、监控热点与大 key；缓存一致性采用 Cache-Aside 模式（写 DB->删缓存，或延迟双删+binlog 异步修正）。

3）MySQL 索引与锁

• 聚簇索引：InnoDB 的主键索引即数据；二级索引叶子节点存主键，可能回表。
• 覆盖索引：查询列都在二级索引里，避免回表（select 列表只含索引列）。
• 联合索引：最左前缀原则，等值->范围的顺序优化；提高区分度。
• 锁：记录锁、间隙锁、Next-Key 锁；RR 隔离级别下用 Next-Key 防止幻读。更新时尽量用精确条件命中索引，避免大范围锁冲突。
• 工程建议：EXPLAIN 观察 type/rows/extra；避免 select *；分页用“延迟关联”（先取主键再回表）。

4）Linux + Docker 资源定位

• CPU 飙高：top/htop 定位进程->jstack 打印线程栈->火焰图看热点；容器内可看 docker stats、cgroup 限额（/sys/fs/cgroup）。
• 内存 OOM：dmesg | grep -i kill 查看 OOM Killer；排查是否触达 memory.limit_in_bytes；怀疑泄漏可用 jmap -dump 与 MAT 分析堆。
• IO/网络：iostat、pidstat、sar/vmstat；网络用 ss -lntp、tcpcopy/抓包。
• 镜像与构建：分层只读+可写层；用多阶段构建、瘦身基础镜像、.dockerignore；以非 root 运行、合理 ulimit。

5）DDD + 设计模式：订单与营销

• 限界上下文：订单、库存、支付、营销各自独立模型与语言；上下文映射用 ACL（防腐层）隔离外部模型。
• 聚合与一致性：以“订单”为聚合根，保证状态转换（待支付->已支付）在聚合内原子；跨上下文用事件驱动（最终一致）。
• 策略模式：优惠计算抽象为 DiscountStrategy（满减/满折/会员价），运行时按活动配置选择具体策略。
• 模板方法：下单流程模板（校验->定价->扣减库存->落单->发事件），可在钩子点扩展风控/营销埋点。
• 工程落地：仓储 Repository 持久化、领域服务封装规则、防重 Token/业务幂等键保证接口幂等。

小结

• 面试中“讲清楚原理 + 结合业务落地 + 权衡取舍”最加分。
• 不会就承认边界，别“绝对”；会就给出权衡与指标。
• 文末答案可作复盘清单，按场景对照项目逐条落地。