分享｜5年Java面Shein，JVM回收器争议挂了，二刷终于OC

先交代背景：普通本科，Java后端，5年经验，上一家是某电商公司，负责过营销中台和订单系统的重构。

Shein的面试让我印象极深——一面因为JVM默认垃圾回收器的争议挂了，复盘后二刷才过。分享整个经历。

📌 第一阶段：一面挂得莫名其妙（6月）

一面（35分钟）——挂了

面试官围绕营销模块的业务和架构展开，问得不算深，但有一道题直接把我干懵了：

1️⃣ JDK 1.8 默认的垃圾回收器是什么？（类似情况好像也有一样同学遇到过，一样的挂了）

💡 思路参考：JDK 1.8 的默认垃圾回收器是 Parallel Scavenge + Parallel Old（并行回收器），不是CMS。但面试官认为CMS，我解释后他没说话，因为这个挂了我，可能是我理解错误了。5年经验要记住：不同JDK版本的默认GC不一样

2️⃣ 调用外部接口，第三方报错但实际成功了，怎么处理？

💡 思路参考：三重保障机制——重试机制（接口超时或异常时重试，但需幂等）、回调通知（第三方主动回调确认状态）、定时任务查询兜底（扫描超时未确认的记录主动查询）。5年经验要能说出每种方案的适用场景——回调最快但依赖对方，定时任务最慢但最可靠。

复盘：一面挂了不是因为技术不行，而是因为面试官对JDK默认GC的理解有误。但这也提醒了我——面试时遇到争议，不要硬刚，可以说”不同版本默认不同，我侧重的是调优思路”。

📌 第二阶段：二刷Shein，四面终于OC（7-8月）

重新投递后，这次准备更充分。

一面（二刷，50分钟）——过了

1️⃣ 项目深挖：营销系统的QPS架构分析

💡 思路参考：营销模块涉及优惠券发放、活动配置、用户触达。峰值QPS约2000，用Redis缓存活动配置（命中率95%），MQ异步处理用户触达。5年经验要能说出接口时延的分布——哪个方法耗时最多、为什么、怎么优化的。

2️⃣ JVM调优实战

💡 思路参考：说一个真实案例——某次大促后老年代持续上涨，Full GC频繁。排查链路：jstat -gcutil观察GC频率 → jmap -dump导出堆内存（4GB文件）→ MAT分析Dominator Tree → 定位到某个缓存Map没有容量上限 → 改用Caffeine（设置maximumSize和expireAfterWrite）。5年经验要能说出dump文件分析的具体步骤。

二面（50分钟）——过了

1️⃣ 系统设计：设计一个高可用营销中台

💡 思路参考：分层架构——接入层（网关+限流+鉴权）、业务层（活动配置、优惠券发放、用户触达）、数据层（Redis缓存+MySQL持久化）。核心难点：活动配置的热更新（配置变更后实时生效，用配置中心+监听机制）、优惠券库存扣减（Redis Lua脚本保证原子性）、用户触达的最终一致性（本地消息表+MQ）。

三面（交叉面）——过了

1️⃣ 线上故障排查

💡 思路参考：说一个真实的P1级事故。某次活动流量突增，Redis连接池被打满。排查过程：看监控确认连接池状态 → 发现热Key问题（某个活动ID被大量请求）→ 紧急做本地缓存（Caffeine，过期时间10秒）→ 恢复。事后加热Key分散策略。

HR面——OC

📝 复盘

Shein的面试让我明白：5年经验的面试，八股依然是入场券，但早已不是通关券。背得再熟，接不住场景追问，后面基本就凉了。

🎯 后来怎么调整的？

一面挂的原因让我意识到：5年经验不能只停留在”能答出标准答案”，而要能讲清楚为什么这样设计、有什么trade-off、结合项目说用过什么、踩过什么坑。