先说结论：这轮面试让我对“三年经验”这个坎有了更具体的认知。极兔的一二面没有太多虚头巴脑的东西，考察范围非常务实，从JVM、并发、MySQL到项目细节、场景设计、算法，每个环节都在验证“你有没有真的写过多线程代码、有没有处理过线上问题、对底层原理是不是背出来的”。这篇文章把两轮面试的完整过程、考题、我当时的回答思路、以及事后复盘出的问题全部整理出来，给准备社招面经的朋友一个参考。
1. 极兔面试的整体流程与准备盘点
我的情况：三年Java后端，主做物流相关业务系统，平时工作涉及订单流转、运单状态同步、定时任务调度这些模块。投的是极兔的中级后端开发岗，面试流程是一二轮技术面连着的，中间隔了不到一周。两轮面试都是电话+在线coding，没有到现场。
先说说我面之前做了哪些准备。三年的Java后端，其实基础八股文的比重不会特别大，面试官更关心的是你对自己写过的系统有没有深入思考。所以我把简历上每个项目的技术方案都重新过了一遍，重点准备了几类问题：
- 系统里遇到的最大并发场景是什么，怎么支持的
- 有没有做过SQL优化、慢查询排查，具体案例是什么
- 缓存和数据库一致性问题是怎么处理的，为什么这么选
- JVM调优有没有实操过，线上OOM或者频繁Full GC怎么处理的
从整个面试的走向来看，极兔的面试官对这些点的考察比重和我的准备方向基本吻合。两轮面试的侧重会有差别：一面偏基础和知识广度，二面偏项目深挖和系统设计思维。
| 环节 | 一面考察重点 | 二面考察重点 |
|---|---|---|
| 基础理论 | JVM内存划分、垃圾回收算法、并发工具原理 | 项目方案背后的取舍、为什么这么设计 |
| 数据库 | 索引优化、事务隔离级别、MVCC原理 | 慢SQL排查案例、分库分表思路 |
| 中间件 | Redis基本数据结构与过期策略 | 分布式锁、缓存一致性、消息队列选型 |
| 算法 | 中等难度数据结构题 | 业务场景模拟题，如轨迹回放、批量处理 |
一面整体考察知识面的扎实程度，二面考的是你有没有架构思维。下面展开说说每一轮的题目和我的实战应答。
2. 一面实录：从八股到场景题的考察路径
一面大概持续了50分钟，前半段是常规八股问答，后半段是场景题加一道算法题。电话面试有个特点，就是面试官看不到你脸上的表情，所以每道题都要在短时间内组织好逻辑，尽量分点回答，别东扯一句西扯一句。
2.1 开场先问项目：别急着背技术栈
自我介绍完，面试官第一个问题没有直接上八股，而是问“你最近做的一个项目，整体架构是什么样的，你负责哪些模块”。
很多人容易把这个问题答成流水账——Spring Boot + MyBatis Plus + Redis + RabbitMQ，然后就没然后了。这种回答最大的问题是面试官听完完全不知道你的技术方案是怎么来的。我当时把项目拆成了四个层次来说：
- 业务背景：这是一个面向网点的运单派送系统，日均处理大概几百万条状态变更
- 我负责的模块：运单状态机流转、异常件处理、定时任务调度
- 核心难点：状态流转的并发控制、大批量状态回传的削峰
- 技术方案：Redis分布式锁控制单据并发操作、MQ做异步解耦、批量刷库的策略
面试官听完点了点头，然后顺着“并发控制”开始往下挖。所以这里有个经验分享给后面面试的朋友：你主动抛出去的技术难点，就一定要提前准备好被追问的答案。你提到用了Redis锁，面试官大概率会继续问锁的实现、失效问题、可重入性；你提到MQ，他会问你怎么保证不丢消息。一开始就铺垫好自己熟悉的领域，等于把面试节奏往自己擅长的地方带。
2.2 JVM考点：内存划分、垃圾回收与线上排障
JVM是Java面试绕不开的一环，极兔一面同样问了。问题很直接：“JVM内存区域怎么划分的，哪些是线程共享的，哪些是线程私有的；常用的垃圾回收器讲一下，G1和CMS的区别是什么”。
我回答的思路是这样的：
- 内存划分：堆、方法区（元空间）、虚拟机栈、本地方法栈、程序计数器。线程共享的是堆和方法区；栈和计数器是线程私有的。顺带提到直接内存，因为NIO里有用到。
- 垃圾回收：分代收集理论，新生代用复制算法，老年代用标记整理或标记清除。新生代默认比例是8:1:1的Eden区加两个Survivor区。
- G1和CMS：CMS是标记清除算法的实现，并发收集、低停顿，但会产生内存碎片（这里我举了个碎片的来源——并发标记阶段用户线程还在跑，引用关系会变，所以必须重新标记）。G1是Region化的设计，把堆分成多个Region，按回收价值优先回收，支持可预测的停顿时间。
面试官追问了一个偏实战的问题：“线上有一个接口频繁Full GC，你从哪些方面排查？”
我提到了这个排查链路：先看监控面板确认Full GC频率和耗时，JVM参数打印GC日志；然后用jmap dump出堆快照，用MAT分析大对象；如果没有办法dump（比如内存太大），就先通过jstat观察各个分区的增长情况，判断是频繁创建对象还是内存泄漏；再用jstack看线程状态，找可能的死锁或大对象持有链。最后补充了一个常见场景：很多Full GC其实是代码问题，比如循环里创建大量局部对象、一个集合加了数据后一直持有引用、或者一次批量查询查了几十万条数据全部加载到内存。
这个回答算是比较完整，面试官也没有再深追。后来复盘我觉得有一个点忘了展开——直接内存和堆外内存的回收问题，特别是Netty这类框架在堆外申请了大量内存时，如果不设置MaxDirectMemorySize，也可能诱发Full GC时堆外内存清理。不过一面整体节奏比较快，没有在这个点上继续抠。
2.3 并发编程：锁的底层原理和AQS
并发这块，极兔一面问了两个纲的：synchronized和ReentrantLock的区别；AQS的原理。
这道题很多人能答上来前面的区别，但问到底层就卡壳了。我当时是这样组织的：
- synchronized是JVM层面实现的，通过Monitor监视器锁，底层依赖操作系统的mutex lock，重量级锁有用户态和内核态的切换开销。JDK 1.6之后有锁升级过程：无锁 → 偏向锁 → 轻量级锁（CAS自旋） → 重量级锁。
- ReentrantLock是JDK层面基于AQS实现的，需要手动加锁和解锁。支持公平锁和非公平锁、可响应中断、可以超时等待、支持多个条件变量。
AQS的原理我是这样讲的：AQS内部维护了一个volatile修饰的state状态值和一个CLH变种的双向等待队列。加锁的本质就是通过CAS修改state，成功则获得锁，失败则把当前线程封装成Node节点挂到队列尾部，并阻塞线程。释放锁时唤醒头节点的后继节点。ReentrantLock的可重入体现在state累加，释放时同样累减，只有减到0才算真正释放。
面试官追问了一个问题：“非公平锁和公平锁在源码层面的区别是什么？”
这个我记忆比较深，因为答得有点险。非公平锁在加锁时会先尝试CAS抢一次state，抢不到才走完整流程；公平锁则会先判断等待队列是否有前驱节点，有的话直接进队列排队。整体来说就是：非公平锁一上来就“插队”试一把，公平锁严格按照队列顺序来。
关于锁这块，我的建议是面试前把AQS的源码从头到尾读一遍，不需要背每行代码，但要能把addWaiter、acquireQueued、unparkSuccessor这几个核心方法的逻辑演进讲清楚。面试官从你说“CLH变种队列”就能分辨出你是真读过源码，还是只听说过概念。
2.4 Redis缓存三大问题和分布式锁
中间件部分问了Redis，重点在缓存穿透、缓存击穿、缓存雪崩的应对方案。面经常客了，我回答得比较顺畅：
- 缓存穿透：查询一个不存在的数据，缓存和数据库都没有，每次请求都打到DB。方案是布隆过滤器前置拦截，或者缓存空值并设置短过期时间。
- 缓存击穿：某个热点key过期瞬间，大量并发请求打到DB。方案是互斥锁重建缓存、逻辑过期（不过期直接返回旧值，异步更新）。
- 缓存雪崩：大量key同一时间过期或Redis宕机。方案是过期时间加随机值打散，集群高可用，多级缓存兜底。
然后面试官直接接了一个场景题：“你项目里拿Redis做分布式锁，说一下你怎么实现的，有什么坑。”
我现场讲了Redis分布式锁常见问题的演进路径：早期用setnx加expire两条命令，如果设置过期时间失败，锁就永久不释放。后来用SET key value NX EX timeout一个原子命令解决。但真正的坑在于锁的续期和主从切换场景。如果持有锁的线程业务还没执行完，锁就自动过期了；或者主节点挂掉后锁还没同步到从节点，另一个线程就会从新主节点拿到同一把锁。
这里我特别提了Redisson的看门狗机制，给锁设置默认30秒过期时间，通过定时任务每10秒检查线程是否还持有锁，如果还在执行就不断续期。主从场景问题没有完美解决方案，最多只能靠RedLock这种多节点投票机制降低概率，但红锁本身也有争议。实际中如果对数据一致性要求极高，我会优先考虑用ZooKeeper的临时节点做分布式锁，因为Znode的创建和删除天然具备会话级别的自动清理。
2.5 MySQL索引与事务隔离级别：答全容易，答深难
数据库部分是我觉得一面里最有含金量的部分，因为面试官一直在追问，没有给我背完就过的机会。
先问的是索引：“最左前缀原则讲一下，为什么MySQL用B+树而不是B树或者红黑树。”
这个问题的核心在于B+树的两大特性：非叶子节点不存储数据，只存索引键，所以同样大小的页能放下更多索引项，树的高度更低（一般三层就能容纳亿级数据）；叶子节点通过双向指针串联，天然支持范围查询，并且天然有序。B树的话叶子节点和非叶子节点都存数据，同样数量数据需要更多层，而且范围查询需要中序遍历，效率差不少。红黑树是二叉树，数据量大了树高太高，一次查询要走很多次磁盘IO。
第二个问题是事务：“MySQL默认隔离级别是什么，可重复读会不会产生幻读，MVCC的原理是什么，能不能解决幻读。”
我回答的逻辑链条是：默认隔离级别是可重复读。可重复读解决脏读和不可重复读用的是MVCC（多版本并发控制），每个事务看到的是自己启动时（ReadView）的快照版本，读操作走undo log版本链，不加锁。但单纯的快照读无法解决幻读，幻读发生在当前读（比如SELECT ... FOR UPDATE）时，另一个事务插入新记录导致查询范围多出数据。InnoDB解决幻读用的是间隙锁（Gap Lock）和临键锁（Next-Key Lock），锁住的是记录之间的间隙，让其他事务无法在间隙插入新数据。
面试官听完追问了一句：“可重复读模式下，普通的SELECT是快照读，那它能解决幻读吗？”
这个问题很有迷惑性。准确答案是：如果事务内所有查询都是普通的快照读，那MVCC的版本链机制使得事务始终看到同一个快照，业务层面不会感知到幻读；但如果快照读和当前读混用，或者第一次查询之后其他事务提交了插入，再用当前读（比如UPDATE、FOR UPDATE），就可能出现幻读。MySQL默认隔离级别下InnoDB通过锁机制在大多数场景规避了幻读，所以默认级别可以保证单表操作的隔离性，这也是和标准SQL定义不一致的地方。
我这么答完，面试官明显比较满意，后面就转到算法题环节了。
2.6 算法题：Thread的交替打印
一面算法题不算难，是一道交替打印的题目：要求用两个线程交替打印数字1到100，一个线程打印奇数，另一个线程打印偶数。
现场coding是在共享编辑器上写的。我提供了两种思路，第一种是用synchronized加wait/notify，第二种是用两个Semaphore做信号量控制。
用Semaphore实现的核心代码如下：
public class PrintOddEven { private static final Semaphore oddSemaphore = new Semaphore(1); private static final Semaphore evenSemaphore = new Semaphore(0); private static int num = 1; private static final int MAX = 100; public static void main(String[] args) { new Thread(() -> { while (num < MAX) { oddSemaphore.acquireUninterruptibly(); if (num <= MAX) { System.out.println(Thread.currentThread().getName() + ": " + num); num++; } evenSemaphore.release(); } }, "OddThread").start(); new Thread(() -> { while (num < MAX) { evenSemaphore.acquireUninterruptibly(); if (num <= MAX) { System.out.println(Thread.currentThread().getName() + ": " + num); num++; } oddSemaphore.release(); } }, "EvenThread").start(); } }这里有几个细节需要留意：奇数线程持有一个初始许可，偶数线程初始为0，这样保证第一个执行的一定是奇数线程；每次打印后释放另一个信号量，形成交替执行的闭环；临界位置要判断num <= MAX，防止打印到100之后线程继续执行。
面试官没有追问这段代码的边界情况，但我自己复盘时发现一个值得注意的点：两个线程共享num变量，这里没有用volatile修饰。因为Semaphore的acquire和release本身就建立了happens-before关系，释放信号量之前的写入对后续获取该信号量的线程是可见的，所以这里不写volatile也没有可见性问题。如果换用synchronized，管程的锁和释放同样具备内存屏障效果。
3. 二面深挖：项目细节、缓存一致性设计题
二面整体节奏比一面要慢，但问题更加发散，更加考验思维方式。面试官全程围绕我简历中的项目经历提问，但每个问题都比我预期要深一步，细节处还会直接指出你方案的漏洞。
3.1 缓存和数据库一致性问题：你踩过坑才知道为什么这么设计
二面第一个有分量的问题是：“你们系统里缓存和数据库的一致性怎么保证的？为什么这么选？”
我之前项目里的方案是基于Binlog的异步监听：先更新数据库，然后通过订阅MySQL Binlog变更解析出变化的数据，再同步更新Redis缓存。如果缓存更新失败，会进入重试队列，重试多次失败后告警人工介入。
面试官听完并没有直接说方案不好，而是问了一个更基础的问题：“为什么不选先删缓存再更新数据库这种常见策略？或者为什么不用延迟双删？”
这个问题问得很到位。我回忆了一下当时的思路，补了这么一段回答：
- 先删缓存再更新数据库的方案，在并发读写下存在明显的时间窗口问题：线程A删除缓存，还未更新数据库，线程B查询缓存未命中，从DB读到旧值并写回缓存，之后线程A才更新数据库，导致缓存里长期是旧值。
- 延迟双删是在先删缓存的基础上，更新数据库之后隔一段时间再删一次缓存，降低并发窗口的概率，但延迟时间怎么定是经验值，很难精确控制，双删之间再次出现并发写回旧值依然有极小概率。
- 基于Binlog异步更新的方案，利用MySQL主从复制体系里的Binlog作为数据变更的可靠载体，即使应用重启也不会丢变更记录，配合MQ消费做到最终一致。
面试官顺着这个方案继续问：“Binlog解析中间件你们用的什么，Canal的原理了解吗？”
Canal的原理其实不复杂：模拟MySQL从库的交互协议，把自己伪装成从库，向主库发送dump请求，主库将Binlog推送给Canal，Canal解析Binlog的row模式变更事件后转成JSON格式发给MQ。这里有个细节是Binlog必须开启row模式，因为statement模式记录的是SQL语句，无法可靠反推哪一行数据变了；mixed模式部分场景也是记录SQL，同样不可靠。项目落地时还踩过一个坑：Canal消费延迟的时候，如果应用服务刚好重启，消费端没记录好位点，会导致部分变更丢失，所以必须把Canal的位点信息持久化到ZooKeeper或者自己维护。
3.2 场景题实战：物流轨迹回放系统怎么设计
二面出了个开放性场景题，这道题让我印象很深：“有一个需求，用户要能看到包裹在每个节点的轨迹，比如揽收、出库、到达分拨中心、派送、签收。现在让你设计这个轨迹回放接口的后端方案，单量最高每秒几万条轨迹上报，你会怎么做。”
这是典型的物流行业业务场景题，我按三个层次去答：
第一层是写链路设计。轨迹上报的QPS很高，不能直接每次调接口都写库。方案是客户端（或网点PDA）上报轨迹后，先入MQ做削峰，消费端批量聚合数据，攒够一批或者达到时间窗口（比如200条或500毫秒）再批量写入。写入的数据表做按月份分表，主要按运单号哈希分片，保证同一个运单的轨迹落到同一张表，方便查询。
第二层是读链路设计。轨迹回放接口特点是读多写少、同一个运单频繁被查。方案是Redis缓存，以运单号为key，轨迹列表按序存储。写链路异步更新缓存，读链路优先走缓存，未命中再查DB并回填。缓存里用ZSet存轨迹节点的时间戳+内容，既能保证顺序，又能支持按时间段回放。
第三层是数据一致性兜底。如果异步写缓存失败，或者缓存因为容量问题被淘汰，查询会走到DB，DB不带缓存回源会有压力，所以还需要一个并行兜底机制：比如查询DB后异步回填缓存，并限制回源频率。另外，如果同一个运单的状态乱了——比如“已签收”之后又插入一条“运输中”，需要做状态机校验，拒绝逆流的状态流转。
面试官听完追问：“如果单个运单的轨迹数据量特别大，比如一个异常件滞留了几十天，产生了几万条轨迹记录，一次查出来性能很差，你怎么优化？”
这个问题很实际，说明面试官也是做过类似系统的。我的回答思路是：轨迹数据读多写少，可以按天分片存储，或者把轨迹数据拆成两层——摘要层（最近几条轨迹、当前状态）和明细层（全部轨迹）。查询接口默认只取最近N条（比如50条），需要看全量时再提供明细查询接口，用异步分页加载的方式。这种设计在很多订单系统里都有实践，因为它同时照顾了接口性能和用户的实际使用习惯。
3.3 线程池参数设置：面试官教的“根据任务类型倒推”
二面还有个Java并发的问题，但角度比一面刁钻：“你项目里的线程池参数怎么设置的？给你一个业务场景，每秒大概有500个任务需要异步处理，每个任务耗时100毫秒，你会怎么设置核心线程数、最大线程数、队列长度。”
说实话这个问题我当时的参数经验值更多，理论推导部分回答得不够精细，事后我重新推导了一遍。
线程池参数设置的经典方法论有两个：CPU密集型和IO密集型。CPU密集型线程数设置为N+1（N为CPU核数），IO密集型设置为2N或者用公式“CPU核数 * (1 + 线程等待时间/线程计算时间)”。
但这个场景明显是IO密集型（耗时主要在等待IO或外部服务响应）。500 QPS、单任务耗时100毫秒意味着单位时间内在执行的任务是500 * 0.1 = 50个，也就是至少需要50个线程并行的处理能力。如果按经验公式2N来算，8核机器给16个线程，是明显不够的。
我当时按这个思路拆解的：
- 核心线程数：考虑到任务耗时100毫秒，QPS 500，那么稳态需要的线程数 = QPS * 单任务耗时 = 50。所以核心线程数至少要设置成50，否则任务会大量积压到队列。
- 最大线程数：如果下游依赖偶发抖动，单任务耗时变成300毫秒，需要的线程数会膨胀到150。最大线程数设置要保留buffer，同时不能无限大，我给了100到150的区间参考，还要配合拒绝策略兜底。
- 队列长度：如果核心线程是50，一台机器能承受的堆积线程数大概 = 500（QPS）* 容忍的延迟秒数。如果允许任务在队列里等2秒，就是1000个任务，队列长度设1000比较合理。
面试官在我答完之后补充了一个很关键的观点：“线程池参数没有完美的答案，关键是你要能在监控里看到线程池的运行指标，根据实际场景去调整。核心线程、最大线程、队列是一组互相影响的参数，不能只拍脑袋设置，也不能改了一个参数不管其他参数。”这段话我记在了笔记里，算是面试附赠的收获。
3.4 消息队列选型：为什么是RocketMQ而不是Kafka
项目里我用到过RocketMQ，二面面试官问了个对比题：“为什么选RocketMQ，Kafka和RabbitMQ不行吗？”
这个话题我很熟，当时从各自的设计目标切入：
- Kafka的设计目标是高吞吐、日志型海量数据的顺序读写，它的优势在分布式日志收集、大数据管道场景。Kafka的消费模型是拉模式，批量拉取性能很好，但业务消息场景下它的消息确认机制、死信队列、延迟队列能力相对较弱。
- RabbitMQ是面向业务消息的老牌中间件，功能完善、路由灵活、管理界面好用。但它的吞吐量相对有限，而且去中心化、可扩展性不如Kafka这种分布式架构。
- RocketMQ是阿里开源的消息中间件，设计目标就是电商业务场景。它具备事务消息、延迟消息、消息重试、死信队列等完整的业务消息能力，同时基于CommitLog和ConsumeQueue的存储架构兼顾了高吞吐。
“在物流业务里，我们需要事务消息保证运单状态和消息发送的一致性，还需要延迟消息做超时未派送提醒，这些用RocketMQ要省事很多。”我补充了选型时的权衡点。
这个回答面试官比较认可，没有继续追问细节。
3.5 反问环节：从技术栈问到团队业务
二面最后留了大概七八分钟给我反问，我问了三个问题：
- 团队目前的技术栈构成，有没有定型的微服务框架
- 后端团队多少人，开发节奏是什么样的
- 快递业务里目前最挑战的技术难题是什么
这些问题的目的不是为了凑时间，而是在信息不对称的情况下判断这个团队的技术氛围是不是适合自己的成长节奏。面试官对第三个问题也给了不少信息，提到网点和转运中心的数据同步、车辆调度算法的优化、末端派送的动态路由等方向。这些信息我听完基本能判断出团队的业务属性和技术挑战，对于后续评估offer有不小的参考价值。
4. 复盘反思：哪些地方答得好，哪些卡了壳
面完之后我花了一天时间把两轮的每个问题重新过了一遍，做了个对错分析。这个复盘比面试本身的价值更大，因为它能把你的知识盲区精确地挖出来。
4.1 回答得比较顺的部分
第一个是Redis缓存三大问题和分布式锁的演进，因为平时项目里真的在处理这些事，从setnx到Redisson看门狗、主从切换问题，都是有实践经历的。第二个是慢SQL排查思路，讲的是自己真实遇到过的线上事故：一个报表查询接口因为多表LEFT JOIN + 非索引列条件导致全表扫描，数据库CPU直接飙高，后来通过EXPLAIN分析执行计划加联合索引解决。这种真实经历讲出来比任何八股文都有说服力。第三个是MySQL的MVCC和锁机制，因为提前把事务隔离级别的源码和文档都过了一遍，理解到位了，答起来有一套自己的逻辑体系。
4.2 回答得不够好的地方
第一个是线程池参数推导的过程，我一开始给出的核心线程数是明显偏小的，还是在面试官的引导下才补充了比例推导。这里暴露的问题是，我在实际工作中对线程池参数的设置依赖经验值偏多，缺少从请求量和响应时间倒推的量化思维。面完以后我自己模拟了几种参数组合，把公式吃透了。
第二个是JVM调优细节，我能讲出完整的排查流程，但一些具体命令的参数记忆不够清晰，比如jmap的-heap、-histo、-dump的具体格式，jstat的S0、S1、E、O、M、CCS这些列代表什么，如果面试官突然追问就有点发虚。事后我把常用命令和参数整理了一份速查表，算是对这个知识点的补强。
第三个是二面场景题中关于流量突增的预案，我一开始只讲了常规的扩容、限流、降级，面试官问“如果网关入口的流量已经打到5倍峰值，限流阈值还在等待动态调整，你还有什么办法”时，我想了一下才补充了：流量调度层面可以按用户或网点维度切分流量、静态页面或简单查询走CDN降级到本地缓存、写操作合并批量提交等方案。这反映出我对高并发方案储备还不够丰富，需要多看一些大流量活动的架构案例来补。
4.3 三年经验面试的整体判断
三年这个年限，在Java后端是个比较特殊的节点。大多数公司不会像应届生那样一题一题地考基础，也不会像高级岗那样上来就让你设计一个完整的高可用架构，而是更关注你是否具备以下能力：
- 有独立负责模块的经验，能讲清楚系统的核心链路和异常场景
- 能对技术选型给出站得住脚的理由，而不是“大家都用这个所以我也用”
- 对线上问题有基本的排查能力，能从日志、监控、dump、执行计划里定位问题
- 对数据一致性、缓存、消息队列这些核心组件有原理级理解，而不仅仅是会用API
极兔这两轮面试的题目设置，基本就是围绕这些能力点展开的。如果你能准备好我说到的这几条，面试时起码不会慌。
5. 给准备Java社招的朋友几条实战建议
面完这一轮，结合这几年的工作经验和面试经历，我给后面准备Java社招的朋友一些建议，尤其是三年左右的这个节点。
第一，简历上的每个技术名词都要准备好“为什么用”。现在面试官几乎不会按你的简历顺序逐项问，而是随手挑一个你提到的技术，问这个技术解决了什么问题，为什么不用替代方案。答不上来“为什么”的技术栈，宁愿不往简历上写，因为写了就要做好被追问的准备。
第二，八股文要背，但一定要理解着背。比如并发工具这块，你光知道synchronized是重量级锁、ReentrantLock是可重入锁，完全不够。面试官会顺着你的回答一路追问，从CAS到AQS到CLH队列，任何一个环节不理解都会卡住。最好的办法是开一个JDK源码阅读的项目，把核心类的注释和关键方法自己走一遍。
第三，平时养成整理线上问题复盘笔记的习惯。面试时最有杀伤力的就是讲真实案例。慢SQL你是怎么定位的、OOM时你是怎么dump分析的、消息积压后你是怎么恢复的，这些经历比任何八股文都有说服力。面试官想听的从来不是标准答案，而是你在面对问题时的分析路径和决策过程。
第四，算法题不要只刷热门100题，要带着多线程和并发控制的视角去准备。现在Java社招的coding题越来越倾向于“用多线程实现一个东西”或者“设计一个并发安全的组件”，这种题考察的不仅是数据结构，还有你对并发模型的理解。极兔一面的交替打印题目就是很典型的方向。
第五，反问环节一定要用好。面试是双向选择，不要浪费这个机会。技术栈、团队规模、核心业务场景、当前技术上最头疼的问题，这几个问题问出去，你对这个岗位的匹配度基本能判断个七八成。问的过程中也能看出面试官对团队有没有热情，判断团队氛围是否适合自己。
面完极兔这两轮，最大的感受就是：三年经验的Java面试，考察的不再是你能不能把代码写出来，而是你能不能解释代码背后的每一次决策。系统为什么这么设计、为什么选这个中间件、线程池参数怎么推导出来的、数据处理失败时怎么兜底，这些才是这个阶段面试真正想看的。希望这份面经对你准备Java社招有帮助。
