阿里巴巴（中国）有限公司校招 Java 后端面试经验——求职精灵（finsight.work）

回答框架：内存分区 → GC 算法 → 收集器演进 → 触发条件 → 一个真实排查案例，五层说完基本不会被追问到空。

1. 内存分区：线程私有的虚拟机栈、本地方法栈、程序计数器；线程共享的堆与方法区（JDK8 后为元空间，使用本地内存）。
2. 堆分新生代与老年代，新生代用复制算法，老年代用标记-整理，方法区主要回收废弃常量与不再使用的类。
3. 收集器：G1 把堆划成等大 Region，可设最大停顿目标，适合 4G 以上堆；ZGC 几乎全程并发，停顿在毫秒级，适合延迟敏感场景。
4. 触发：Eden 满触发 Minor GC，老年代空间不足、元空间不足或显式调用会触发 Full GC。
5. 案例：曾用 jstat -gcutil 发现老年代持续上涨，jmap 定位到一个没有容量上限的本地缓存，修复后 Full GC 从每小时十次降到零。

回答框架：先讲「是什么、解决什么问题」，再讲容器启动流程，最后讲 AOP 的代理选择与失效场景。

1. IOC 是把对象创建与依赖注入交给容器，调用方只声明依赖，从而解耦。
2. 实现上，容器扫描注解得到 BeanDefinition，通过反射实例化，再完成属性填充与初始化，单例 Bean 存放在 ConcurrentHashMap 中。
3. 循环依赖靠三级缓存解决：一级放成品，二级放早期暴露对象，三级放对象工厂，核心是让 A 在未完成初始化时就能被 B 引用。
4. AOP 是在方法调用前后织入横切逻辑，典型应用是事务、日志与权限。
5. 代理选择：目标类实现接口用 JDK 动态代理，否则用 CGLIB 生成子类；因此同类内部方法直接调用会绕过代理，导致 @Transactional 失效。

收尾可以补一句：理解代理边界，比记住「动态代理」四个字更有价值。

回答框架：先讲 B+ 树的结构与优势，再区分聚簇索引和二级索引，最后按场景列失效条件。

1. B+ 树非叶子节点只存 key，叶子节点存数据并用双向链表相连，层数低、磁盘 IO 少，范围查询只需顺着叶子链表扫。
2. 聚簇索引的叶子存整行数据，二级索引的叶子存主键，查询非索引列需要回表；用覆盖索引可以避免回表。
3. 失效场景：LIKE '%xx' 前置通配符、对索引列使用函数或运算、隐式类型转换、联合索引不满足最左前缀、OR 两侧存在非索引列、NOT IN 或 != 导致优化器放弃索引。
4. 补充：数据量小、区分度低或查询命中大部分行时，优化器也可能主动选择全表扫描，这不等于索引写错了。
5. 排查用 EXPLAIN 看 type、key、rows 与 Extra，重点确认是否出现 filesort 或临时表。

回答框架：先定义幂等，再说清重复来源，最后按业务类型给方案并做组合。

1. 幂等是同一请求执行一次和多次，最终状态一致；重复来源包括客户端重试、网关超时重发、MQ 重复投递与用户重复点击。
2. Token 机制适合下单支付：进入页面先取 Token 存 Redis，提交时用 SET NX 占用，占用成功才处理业务。
3. 唯一索引适合插入类操作：订单号、请求号建唯一索引，捕获冲突后返回已处理。
4. 乐观锁适合更新类操作：UPDATE ... SET status = 2, version = version + 1 WHERE id = ? AND version = ?。
5. 状态机适合流程类业务：只允许从待支付到已支付，更新前校验当前状态，非法流转直接拒绝。

收尾：真实系统通常「唯一索引 + 状态机」双保险，因为只靠应用层判断在并发下并不可靠。

回答框架：先讲使用场景，再给最小实现，然后逐个指出问题与解法，最后谈集群故障。

1. 场景：库存扣减、任务调度、防止重复处理，要求同一时刻只有一个持有者。
2. 最小实现：SET key uuid NX EX 10，一条命令完成占锁与过期，避免 setnx 后 expire 的非原子问题。
3. 误删：执行时间超过 TTL 后锁被他人持有，原持有者删锁会删错。解法是用 Lua 先比对 uuid 再删除。
4. 不可重入：用 Hash 存 uuid 与重入次数，加锁加一、解锁减一，归零再删除。
5. 续期：Redisson 的看门狗每三分之一 TTL 续期一次，避免业务没跑完锁先过期。
6. 集群故障：主从切换可能丢锁，强一致场景可用 RedLock 向多数节点加锁，但成本高，多数业务用单实例加持久化即可。

回答框架：四个级别 → 三类并发问题 → InnoDB 在 RR 下怎么处理幻读 → 生产环境怎么选。

1. 读未提交：能读到未提交数据，脏读、不可重复读、幻读都可能发生。
2. 读已提交：只读已提交数据，解决脏读，但同一事务内两次读可能不同，Oracle 默认此级别。
3. 可重复读：事务内快照一致，解决不可重复读，是 MySQL 默认级别。
4. 串行化：事务串行执行，三类问题都不存在，但并发度最低。
5. InnoDB 在 RR 下用 MVCC 保证快照读一致，用 Next-Key Lock（记录锁加间隙锁）锁住范围，阻止其他事务插入，从而处理当前读场景的幻读。
6. 生产建议：高并发写入场景可切到 RC 减少间隙锁竞争，但必须确认业务能接受不可重复读。

先确认条件：树可能为空；返回的是按层组织的列表；奇数层从左到右、偶数层从右到左；节点值范围不限。
思路是 BFS 加方向标记：用队列逐层取出节点，每层用双端队列收集值，正方向尾插、反方向头插，这样不用最后再反转。

public List<List<Integer>> zigzagLevelOrder(TreeNode root) {
    List<List<Integer>> res = new ArrayList<>();
    if (root == null) return res;
    Queue<TreeNode> q = new LinkedList<>();
    q.offer(root);
    boolean leftToRight = true;
    while (!q.isEmpty()) {
        int size = q.size();
        LinkedList<Integer> level = new LinkedList<>();
        for (int i = 0; i < size; i++) {
            TreeNode cur = q.poll();
            if (leftToRight) level.addLast(cur.val);
            else level.addFirst(cur.val);
            if (cur.left != null) q.offer(cur.left);
            if (cur.right != null) q.offer(cur.right);
        }
        res.add(level);
        leftToRight = !leftToRight;
    }
    return res;
}

复杂度 O(n) 时间、O(n) 空间，队列最大宽度决定额外开销。追问「不用双端队列怎么做」：可以先按层收集再对偶数层 Collections.reverse，代码更直观但多一次遍历。

回答框架：先区分熔断与降级，再讲断路器三个状态，最后对比两个组件的隔离方式与生态。

1. 熔断是下游错误率超过阈值时切断调用，防止故障沿链路扩散；降级是返回兜底结果，保证主流程可用。熔断触发后通常走降级。
2. 断路器有三态：关闭时正常调用并统计；打开时直接拒绝；半开时放少量请求探测，成功则恢复，失败则继续打开。
3. Hystrix 用线程池隔离，隔离彻底但线程开销大，Netflix 已停止主要维护。
4. Sentinel 用滑动窗口统计，支持流量整形、热点参数限流、系统自适应保护，隔离以信号量为主，开销更小，社区活跃。
5. 选型：新项目优先 Sentinel，配合控制台做规则动态下发；已有 Hystrix 体系则评估迁移成本。

收尾补一句：熔断阈值要按接口分别设置，统一阈值要么误熔断，要么形同虚设。

回答框架：短码生成 → 存储与路由 → 读性能 → 容量估算，最后补一致性与防滥用。

1. 短码生成：用 Snowflake 生成自增 ID，再转 Base62，取后 6 位即可。6 位 Base62 空间约 568 亿，顺序递增对 MySQL 主键友好。哈希方案实现简单但会碰撞且无序，不推荐做主方案。
2. 存储：短码作为 sharding key，按哈希取模分库分表；映射表只存短码、长链、创建时间与状态，长链可压缩或单独存对象存储。
3. 读：CDN 或本地缓存挡热点，Redis 缓存短码到长链的映射，未命中再查库；用布隆过滤器拦掉不存在的短码，避免无效查询打穿数据库。
4. 容量：按每天 1 亿条、保留 5 年估算约 1800 亿条，每条几十到几百字节，需要提前规划分片数与冷热分层。
5. 追加：写入用发号器保证唯一，读多写少适合多级缓存；还要做恶意链接检测与访问频控。

回答框架：先给自己的理解，再用一个真实经历证明，最后说清它会怎样影响你的工作方式。

1. 我的理解是：判断优先级时，以最终用户的长期利益为第一标准，而不是以自己省事、指标好看为第一标准；内部协作里，下游团队也是客户。
2. 经历：我做过一个内部工具，功能上线后使用方反馈要六步才能完成一次操作。我最初觉得「功能齐了，学一下就会」，后来意识到这是开发者视角。
3. 行动：我跟着两位真实用户完整走了一遍流程，把高频操作合并、默认值前置，步骤从六步降到三步，并加了操作回显。
4. 结果：使用率明显上升，后续需求也从「加功能」变成「改体验」，说明方向对了。
5. 落到工作上：我会先问「这个方案对用户有没有价值」，再问「技术上是否优雅」；遇到指标与体验冲突时，优先保住核心体验。