一面开场还是老规矩自我介绍。我没堆项目名而是直接说了自己三年主要在做的业务方向物流订单履约、运费试算、轨迹推送这一套。面试官听完就笑了说“那咱们今天没跑偏问题基本都围绕这个来”。整个极兔一二面给我的感觉是框架问得不算多但基础挖得很深项目里的细节会被拿出来反复追问绝对不给你背八股混过去的机会。这篇面经我把能回忆起的题目和当时的思路完整写出来了希望能帮到准备大厂或物流电商方向的Java同行。1. 一面基础八股问得真不“八股”1.1 HashMap从put到扩容你写过的代码都去哪了面试官先让我简单说下订单全链路的状态流转我提了一句“为了保证幂等用订单号做key落在内存里做状态扭转”。他马上接住好那你说说HashMap的put过程数据到底怎么落进去的。这题很多人能背出来先算hash扰动函数打散高低位然后按数组长度减一做与运算得到桶位。如果桶位为空直接放进去不为空就看当前节点是链表还是红黑树链表就尾插。但面试官往下追问了几个细节为什么HashMap容量必须是2的幂因为(n - 1) hash比取模快而且只有容量是2的幂时结果才和取模等价。为什么Java 8把头插改成尾插头插在扩容时会形成环形链表1.7的resize里并发put会导致死循环CPU飙升1.8改成尾插能规避但并发丢数据问题还在。他接着问了resize。我现场画了个简化版旧数组元素要迁移时因为容量翻倍节点的新位置要么是原始索引要么是“原始索引 旧容量”。判断条件是hash oldCap等于0就留在原位等于1就移到高位。这个点我是真踩过坑早期我写代码自认为理解了扩容但面试官问“newTab[e.hash (newCap - 1)]这行代码有没有问题”时我还是愣了一下。实际JDK1.8为了减少rehash用了低位链和高位链拆分的写法。注意HashMap的扩容不是简单重新算一遍(length - 1) hashJDK8里用的是把原链表拆成loHead和hiHead两条然后分别放到newTab[j]和newTab[j oldCap]。这里的关键判断就是(e.hash oldCap) 0。最后他问“什么时候会树化”。我答链表长度超过8且数组长度超过64如果数组长度没到64会先扩容而不是树化。他追问“为什么是8”我答了泊松分布负载因子0.75时单个桶位链表长度为8的概率已经非常低树化是为了极端情况下防哈希攻击。1.2 线程池参数与拒绝策略你以为背8个参数就够了第二题来自我项目里的一段异步推送代码。为了推运单轨迹给客户我用Executors.newFixedThreadPool做过但后来被老同事说生产不能用改成了手动ThreadPoolExecutor。面试官顺势问线程池核心参数有哪些任务提交后按什么顺序执行我按执行流程答提交任务当前工作线程数小于核心线程数创建核心线程执行。达到核心线程数后新任务进入等待队列。队列满了创建非核心线程执行新任务。线程数到达最大线程数触发拒绝策略。他追问corePoolSize、maxPoolSize、workQueue的关系队列未满之前即使有空闲非核心线程也不会拿任务队列满之后如果当前线程数小于最大线程数会优先新建线程而不是等核心线程空闲。这块很多人搞反是先填队列不是先扩线程。关于不同拒绝策略我之前做支付回调通知一直用CallerRunsPolicy好处是让主线程自己跑任务既不会丢任务也天然限流缺点是会卡接口。极兔这边问的是“如果业务允许丢选哪个”我说DiscardPolicy和DiscardOldestPolicy都行但要有日志兜底不然线上问题完全无感知。线程数设置我给了一个自己的公式经验CPU密集任务用CPU核数 1IO密集任务用CPU核数 * 2或者更高。但更重要的是压测实测。我在项目里就是先按2 * CPU核数配然后根据队列积压速率调整。1.3 MySQL索引失效用EXPLAIN证明给我看一面问MySQL问得很细。面试官给了一个场景物流订单表有status、create_time、waybill_no三个字段查询条件是where status 1 order by create_time desc问怎么建索引。我先答直接建(status, create_time)联合索引面试官点头紧接着说“那如果我经常查status in (1,2,3)呢”。我愣了下说in条件在MySQL优化器里通常还能走索引但排序字段可能在排序时无法利用索引顺序需要filesort。这种情况我更建议试一试(status, create_time)索引和单独create_time索引看EXPLAIN的key和Extra字段决定。后来面试官把把问题转向索引失效。我总结了几个高频场景违反最左前缀跳过联合索引第一列。对索引列做函数运算或隐式类型转换例如where phone 138...但phone是varchar传数值时可能走不上索引。like %xxx前面带百分号不走索引。or连接非索引列会导致全表扫描。他特地问我“为什么函数运算会导致失效”。我说索引存储的是原始字段值B树比较的是原值如果把列套进DATE() / YEAR()里优化器必须算出函数结果才能判断没法直接拿查询值去B树比较优化器评估成本高就选了全表扫。经验遇到慢SQL先EXPLAIN看type是不是ALL然后看key是否为空Extra里有没有Using filesort或Using temporary。别上来就想改SQL很多时候是索引设计没跟上查询模式的变化。1.4 事务隔离级别与MVCC别只背名字极兔物流多个环节要写同一条订单状态比如揽收、运输、派送并发更新容易出问题。面试官问MySQL默认隔离级别是什么可重复读靠什么实现我答默认是REPEATABLE READ主要靠MVCC加锁实现。MVCC不是MySQL独有它用版本链和Read View做到“读不加锁读写不冲突”。行记录里有隐藏字段trx_id和roll_pointer每次更新生成undo log形成版本链。事务开始读的时候创建Read View记录活跃事务列表通过比较trx_id判断当前版本是否可见。他接着问可重复读下Read View什么时候生成“快照读”和“当前读”有什么区别这是我比较熟的点我说普通select是快照读第一次select时生成Read View后面都复用它select...for update、update、delete都是当前读读的是最新已提交版本还要加锁。面试官点头又补了一个问题那可重复读隔离级别下id 1的记录被另一个事务删了当前事务再查能查到吗我说快照读下还是能查到因为Read View还认为这个记录对当前事务可见当前读就查不到了。他说对然后笑着来了句“MVCC不是银弹很多线上问题都是快照读和当前读混用导致的”这句话我认同后来真遇到过一次数据不一致就是锁和快照读混用造成的。2. 一面Redis连环炮从缓存穿透打到分布式锁2.1 持久化选型RDB、AOF和混合到底用哪个面试官很直接你说你用了Redis缓存订单签收状态那Redis挂了会不会丢数据这块涉及持久化。RDB是快照默认有save规则或主动bgsave会fork子进程生成rdb文件恢复快但两次快照之间的数据会丢。AOF是追加日志默认everysec刷盘最多丢一秒数据但文件大恢复慢。他问“线上一般怎么配”我说Redis 4.0以后有混合持久化aof-use-rdb-preamble yesAOF文件前半段是RDB格式后面的增量用AOF日志兼顾恢复速度和丢失量。实际项目里我们同时开启AOF并设置appendfsync everysec配合主从节点这样单节点挂掉也能从副本秒切。他还追问AOF重写的触发条件。我说当aof文件超过上次重写后auto-aof-rewrite-percentage默认100且大于auto-aof-rewrite-min-size默认64mb时触发。重写不是压缩旧文件而是把当前数据集新增一条命令生成一个新AOF文件。2.2 缓存三大难穿透、击穿、雪崩这一part我熟因为物流系统里有几个接口的流量有明显波峰比如大促前批量查运单。面试官问如果用户疯狂查一个不存在的订单号你怎么防止打到数据库缓存穿透我说用布隆过滤器把存在的订单号hash进bitmap或者缓存空值设短过期时间。他问布隆过滤器有什么缺点我说有误判率可能把不存在的订单号判断为存在而且它不支持删除除非用Counting Bloom Filter。但实际业务里我更常用空值缓存因为订单号有固定前缀和规则直接对非法参数做拦截更简单。缓存击穿说的是热点key失效瞬间大量请求同时打到db。解决办法是互斥锁或者逻辑过期。我详细讲了逻辑过期的方式value不设置真实过期时间而是存一个逻辑过期时间字段查询时发现逻辑过期先获取分布式锁另一个线程重建缓存旧线程返回旧值。这个方法能扛住热点key但实现复杂且一定时间内读的是旧数据适合价格变化不剧烈的场景。缓存雪崩是大量key同时失效或Redis节点整体宕机。解决思路是过期时间加随机值或者做多级缓存加上降级限流。极兔这边因为流量相对集中他们更看重的是“本地缓存 Redis 数据库”三级降级策略。2.3 分布式锁setnx到Redisson还有那些坑面试官在项目里看到了我用Redis做分布式锁直接让我写伪代码。我说一定要用set key value NX EX 30别分两步setnx再expire会出原子性问题。他又问如果锁到期了业务还没执行完怎么办我答了Redisson的看门狗机制后台有个定时任务每隔三分之一锁超时时间续期如果客户端挂了续期停止锁最终会过期释放。但他补充了一句如果业务时间特别固定且不允许自动续期最好手动设置超时时间并加ThreadLocal存储请求签名释放锁时检查value。他还问“释放锁为什么需要Lua脚本”。我说用get和del两步有并发问题A线程执行完锁过期了B线程拿到新锁A线程此时再去del会把B的锁删掉。所以要用Lua脚本保证“判断value是自己”和“删除key”是原子操作。接着他问RedLock我说RedLock要多个独立Redis节点过半加锁才算成功但生产环境遇到GC停顿可能导致锁过期RedLock争议比较大不建议迷信。面试官对这个回答很认可说分布式锁不是组件越多越安全要结合自己的业务一致性诉求。3. 二面项目架构与设计细节见真章3.1 动态代理与AOP手写JDK代理再说说CGLIB二面上来就是设计题后端打印接口耗时怎么做我答Spring AOP 自定义注解。他接着问AOP底层是什么。JDK动态代理和CGLIB的区别是Java面试高频点但极兔这边问得比较深JDK代理是接口代理底层通过Proxy.newProxyInstance生成一个实现了目标接口的代理类代理类持有InvocationHandler调用方法时反射转发。CGLIB是继承目标类生成子类用ASM字节码技术重写父类方法所以不能代理final类和方法。他让我手写一个JDK动态代理。我当时写了类似这样的简化逻辑public class LogProxy { public static Object create(Object target) { return Proxy.newProxyInstance( target.getClass().getClassLoader(), target.getClass().getInterfaces(), (proxy, method, args) - { long start System.currentTimeMillis(); try { return method.invoke(target, args); } finally { System.out.println(method.getName() cost (System.currentTimeMillis() - start) ms); } }); } }关于CGLIBSpring在目标类有接口时默认用JDK没有接口时才用CGLIB但Spring Boot 2.x之后默认使用CGLIB代理。面试官总结了一句“动态代理的本质是字节码生成”我觉得这句话比背十遍区别有用。3.2 策略模式实战物流运费计算模块的重构二面有个场景题让我印象很深。他说快递运费计费规则很复杂有按重量、按体积重、按区域、按时效还会叠加优惠你作为系统设计者怎么让代码不变成一坨if-else。这个我正好做过类似重构。核心是策略模式 工厂模式把规则引擎抽出来。我画了个思路接口FreightStrategy定义calculate(FreightContext context)每种计费方式一个实现类再用一个策略工厂根据传进来的业务类型返回对应实现。他说“如果一种计费方式是组合策略呢比如首重续重 偏远地区附加费”我说那就不是单一策略能解决的我会把“组合”也当成一种策略——CompositeFreightStrategy内部维护一个List 按序执行并把结果累加。这块再进一步可以引入责任链每个策略节点只处理自己能处理的处理不了就交给下一个节点。他追问Spring里怎么管理这么多策略实现类。我说可以用MapString, FreightStrategy把bean name作为key或者自定义注解标记策略类型在启动时注册到工厂。现在Spring Boot项目里我一般用依赖注入ListFreightStrategy拿到所有策略再通过StrategyRegistry按类型路由。这样扩展新计费规则时只需要新增类不改老代码满足开闭原则。3.3 JVM调优案例一次集装箱下单接口的Full GC排查二面问完设计突然转向JVM你们线上有没有Full GC频繁的案例。我讲了一个真实案例。下单接口高峰期CPU飙升接口偶尔超时。监控看到Full GC次数从一天几次变成一小时几十次。我先dump了堆用MAT分析发现ConcurrentHashMap里存了太多订单缓存对象每单都存一份完整运单信息而且没有清理机制。再加上业务代码里用ArrayList临时存储大量中间结果内存分配太快。排查过程先用jstat -gcutil pid 1000看GC曲线发现Old区一直在涨FGC次数增加。再用jmap -dump:formatb,fileheap.hprof导出堆MAT查Dominator Tree找到那个对象占用最大的类。修复方案有三条订单缓存改成本地化弱引用但配合过期清理或者直接用Caffeine并设置最大条目数。大对象不要长期引用处理完置空方法内局部变量及时脱离作用域。调整JVM启动参数把-Xms和-Xmx设为一致避免堆动态扩容带来的额外开销。面试官问“为什么不建议直接在启动参数上把堆调大”我说堆调大确实能延迟FGC但每次FGC时间也会变长治标不治本。内存问题的核心还是对象生命周期管理要先从业务代码找对象泄漏和持有链过长的问题。注意JVM参数不是越大越好。堆太大导致单次GC暂停时间长接口RT会突然抖动。我后来把对象缓存瘦身之后FGC时间反而降下来了。3.4 Spring Bean生命周期循环依赖是真的“三级缓存”吗二面收尾问题很经典Spring Bean生命周期说一下。这个背流程不难但极兔面试官听得特别细我每说一步他都会问“这一步里Spring做了什么事”。我按阶段快速过实例化、属性填充、初始化BeanPostProcessor前置方法、afterPropertiesSet、自定义init-method、销毁。中间插入Aware接口和BeanPostProcessor。他把重点放在循环依赖上Spring怎么解决setter循环依赖我解释了三级缓存一级缓存singletonObjects放完整的单例Bean。二级缓存earlySingletonObjects放提前暴露的早期Bean此时属性还没填完。三级缓存singletonFactories放一个对象工厂ObjectFactory用于生成代理对象。为什么需要三级而不是两级因为要兼顾循环依赖和AOP。如果只是解决循环依赖二级就够了但Spring希望在创建代理时能保持早期引用的一致性如果A和B循环依赖A在填充B时需要暴露字节码增强后的代理。如果直接用二级缓存保存原始对象后续A需要做AOP时代理对象就只能在最终阶段生成那B里持有的原始A对象就不会是代理了。三级缓存通过ObjectFactory延迟了“是否为代理”的决定保证整个容器最终拿到的是同一个增强对象。他补充问“构造器循环依赖能解决吗”我说不能因为构造器在实例化阶段就必须传入依赖还没有机会暴露三级缓存。解决办法是用Lazy或DependsOn避免这种设计。4. 反问与复盘拿到Offer后又做了什么4.1 反问环节怎么问才有价值极兔二面最后留了十分钟反问。我没有问薪资待遇问的是团队目前有多少后端代码评审和发布流程是什么样的核心系统有独立的SRE吗线上告警和值班怎么排你们这个跨境物流链路最大的技术挑战是哪个环节前两个问题是为了判断自己进去后的工作节奏和成长空间第三个问题能看出面试官对自己业务的理解。他回答的时候一直在讲清关数据对接的稳定性问题这其实也侧面说明了过去可能因为外部接口超时导致订单状态不一致。这种非技术问题面试官反而很愿意展开聊得越深他对你的印象越具体。我当时还补了一句“如果有幸入职前三个月我想先把现有订单状态机的代码吃透再谈优化”这句话比空洞的“我很努力”更有说服力。4.2 三年Java面试必须避开的坑这些是我几次面试踩出来的经验希望能帮到准备跳槽的人别只背结论。HashMap为什么要扰动、线程池为什么先填队列、AOF为什么默认everysec面试官随便追问就能看出你是真懂还是背的。项目里凡是写“用了Redis”都得准备好三连问缓存了什么key、过期时间怎么定、数据一致性怎么保证。否则简历写一句“使用Redis提高系统性能”就是给自己挖坑。设计模式不要只说理论最好能讲一个自己重构过的场景。比如策略模式你说“订单运费用了策略模式”面试官肯定问策略怎么注册、怎么路由、怎么扩展。4.3 一份自测清单查漏补缺我在准备面试时给自己列了张自测表走一遍基本能覆盖大厂和独角兽重点模块必须能说清的关键点自测情况Java基础HashMap、ConcurrentHashMap、锁升级、AQS、ThreadLocal需要复习ThreadLocal内存泄漏并发编程线程池参数、synchronized/ReentrantLock、volatile、CAS基本OKMySQL索引结构、事务隔离级别、MVCC、死锁、慢查询优化explain要再熟练Redis持久化、缓存穿透/击穿/雪崩、分布式锁、集群架构需要补cluster槽位迁移SpringBean生命周期、循环依赖、事务传播、AOPOKJVM内存区域、垃圾收集器、调优案例、类加载OK项目设计状态机、策略模式、接口幂等、分布式事务分布式事务是短板这张表打印出来贴在电脑边每天抽半小时过一遍重复几轮以后面试状态会稳很多。个人经验面完别急着等结果把过程变成自己的复习材料说实话极兔这两轮面试难度没有很多一线互联网那么大但胜在问题非常集中几乎每一题都和物流业务场景强相关。尤其是二面那两道设计题动态代理和策略模式都是我平时实际用过的但被面试官拆到字节码层面时我还是有一瞬间卡壳。这次面试给我最大的提醒是三年经验的程序员不能只在应用层写CRUD框架底层的运转逻辑、性能问题出现时的排查路径才是区分“熟练工”和“潜力股”的关键。我把这次面经整理出来不只是为了记录题目。如果你最近也在准备Java面试建议把每道题都当成一个入口HashMap背后是数据结构线程池背后是操作系统调度MVCC背后是事务与并发的关系顺着这个思路往下挖等你形成自己的知识网格不管是去极兔还是去别家心态都会完全不一样。