校招 未知部门 / 后端-Java / 多轮

<h2>分享｜6年Java面字节，一面50题拷打，三面终于OC</h2> <p>先交代背景：普通本科，Java后端，6年经验，上一家是某电商平台，负责过订单中台和支付系统的架构设计，带过10人团队。</p><p>字节一面整理了50道题的六域分类，考的不是你“背了多少”，而是“有没有想过为什么”。我面了字节三轮技术面加HR面，整个过程磕磕绊绊，最终OC。</p><p><strong>📌 第一阶段：一面50题拷打（7月）</strong></p><p>面试官围绕并发、JVM、Spring、MySQL、Redis、MQ六个知识域连环追问，全程70分钟。</p><p><strong>1️⃣ synchronized和ReentrantLock的核心区别，什么场景只能用ReentrantLock？</strong></p><p>💡 <strong>思路参考</strong>：synchronized是JVM层关键字，锁的获取/释放由JVM自动管理，不可中断、不支持超时、不能绑定多个条件变量；ReentrantLock是AQS的实现，支持tryLock(timeout)超时等待、lockInterruptibly()响应中断，以及多个Condition对象（替代Object的wait/notify组，精确唤醒特定线程）。6年经验要能说出<strong>超时等待和可中断在实际项目中的价值</strong>——比如分布式锁降级场景下，tryLock超时后走本地降级路径。</p><p><strong>2️⃣ synchronized的锁升级条件，为什么JDK 15默认关闭了偏向锁？</strong></p><p>💡 <strong>思路参考</strong>：偏向锁→轻量级锁→重量级锁。偏向锁在单线程场景下几乎零开销，但一旦有第二个线程竞争，触发偏向撤销（STW），成本不低。JDK 15之后偏向锁被默认关闭，因为维护成本高且现代程序竞争普遍。6年经验要能说出<strong>什么业务场景下偏向锁有价值</strong>（读多写极少且无竞争的缓存场景）。</p><p><strong>3️⃣ volatile为什么不能保证原子性，i++在字节码层面发生了什么？</strong></p><p>💡 <strong>思路参考</strong>：volatile保证可见性和有序性，但不保证原子性。i++实际是三条字节码指令（getstatic、iadd、putstatic），volatile只能保证每条指令读写的可见性，但三条指令之间仍可能被其他线程插入。</p><p><strong>4️⃣ ThreadLocal在线程池场景下的内存泄漏是怎么发生的？</strong></p><p>💡 <strong>思路参考</strong>：ThreadLocalMap的key是弱引用（WeakReference），但value是强引用。线程池中线程长期存活，ThreadLocal变量被回收后，Entry变成key=null但value仍存活的无效条目，永远不会被清理，导致OOM。解决方案：finally块中手动调用remove()。</p><p><strong>5️⃣ JVM线上Full GC频繁，你怎么排查？</strong></p><p>💡 <strong>思路参考</strong>：标准排查链路——<code>jstat -gcutil</code>观察GC频率和老年代占用率→<code>jmap -dump</code>导出堆内存→MAT分析Dominator Tree找大对象→定位代码→修复。6年经验要能说出<strong>dump文件分析的具体步骤</strong>和<strong>MAT的Leak Suspects报告怎么看</strong>。</p><p><strong>6️⃣ MySQL的MVCC和间隙锁是怎么配合防止幻读的？</strong></p><p>💡 <strong>思路参考</strong>：可重复读隔离级别下，快照读（普通SELECT）用MVCC保证可重复读（基于Read View的可见性判断），当前读（SELECT FOR UPDATE / UPDATE / DELETE）用间隙锁防止其他事务插入新行。间隙锁只在可重复读隔离级别下存在。</p><p><strong>📌 第二阶段：二面三面全过了（8月）</strong></p><p><strong>二面（70分钟）——过了</strong></p><p><strong>1️⃣ 系统设计：设计一个支持亿级流量的电商大促系统</strong></p><p>💡 <strong>思路参考</strong>：流量削峰——CDN加速静态资源、Nginx限流（漏桶算法）、MQ削峰填谷（将请求先写入消息队列，消费者按能力处理）、Redis预扣库存（Lua脚本原子性）、分布式事务（TCC）。6年经验要能说出<strong>每层的瓶颈和扩容方案</strong>——Redis单节点QPS 10万+，集群分片可扩展到百万级。</p><p><strong>2️⃣ 分布式事务选型：TCC vs SAGA vs 消息最终一致性</strong></p><p>💡 <strong>思路参考</strong>：TCC适合核心资金链路（强一致性但侵入性大，需要实现Try-Confirm-Cancel三个接口），SAGA适合长事务（补偿回滚），消息最终一致性适合非核心异步场景。6年经验要能说出<strong>空回滚和悬挂问题的具体解决方案</strong>——空回滚是Try超时但Cancel被调用，需根据事务ID查询Try是否执行过；悬挂是Cancel先于Try执行，需根据事务ID标记Cancel已执行，后续Try到来时直接拒绝。</p><p><strong>三面（交叉面，80分钟）——过了</strong></p><p><strong>1️⃣ 系统设计：设计一个全链路压测平台</strong></p><p>💡 <strong>思路参考</strong>：全链路压测的核心是<strong>流量染色</strong>——压测流量打上特殊标记（如Header中的压测标识），在链路中透传，确保压测流量只走影子库/影子表，不污染生产数据。关键设计：数据隔离（压测数据写入影子库）、流量隔离（压测流量只路由到压测分组）、监控隔离（压测指标单独统计）。6年经验要能说出<strong>压测模型的设计</strong>——如何保证压测流量和真实流量1:1匹配。</p><p><strong>HR面——OC</strong></p><p><strong>📌 声明</strong></p><blockquote><p><em>以上思路参考来自 </em><strong><code><em>&quot;面题鸭🦆&quot;</em></code></strong><em> 各岗位专属考题的考点方向</em></p></blockquote><p><strong>📝 复盘</strong></p><p>字节6年经验的面试，考的是三件事：</p><ol><li>能不能独立设计系统（亿级流量、全链路压测）</li><li>线上出事了能不能扛住（Full GC、OOM、ThreadLocal泄漏）</li><li>能不能讲清楚为什么（每个技术选型都有明确的trade-off分析）</li></ol><p><strong>🎯 后来怎么调整的？</strong></p><p>一面挂的原因是JVM线上排查的思路不够系统，只会背参数不会结合实际场景分析。后来在 <strong><code>&quot;面题鸭🦆&quot;</code></strong> 上刷了一遍字节方向的JD专属出题，JVM调优、分布式事务选型这些方向覆盖得很全。二刷时心里有底很多。</p><p></p><p></p><a>#哪个瞬间让你对大厂祛魅了？#</a><a>#发面经攒人品#</a><a>#字节跳动工作体验#</a><a>#字节求职进展汇总#</a>