lloydsheng1. 面试开场：当严肃面试官遇上"水货"候选人
这场面试从一开始就充满了戏剧性。面试官是一位经验丰富的技术专家，表情严肃，提问直接；而候选人谢飞机则带着几分"水货"特质，回答问题时总是试图用轻松幽默的方式蒙混过关。这种反差让整个面试过程既紧张又有趣。
面试官的开场白简洁有力："我们按真实业务链路来聊，三轮面试，每轮几个问题，跟着场景走。"这句话立刻为整个面试定下了基调——这是一场基于实际业务场景的技术考察，而非简单的理论问答。谢飞机虽然嘴上说着"好的好的，我热身就绪"，但从后续表现来看，他的准备显然不够充分。
这种面试形式在现代技术面试中越来越常见。大厂面试通常会围绕实际业务场景展开，考察候选人解决实际问题的能力，而非死记硬背理论知识。面试官会模拟真实工作环境中的技术挑战，观察候选人如何分析问题、设计方案并权衡取舍。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 第一轮技术考察：商品列表与并发基础
2.1 ArrayList的扩容机制与fail-fast原理
面试官的第一个问题直指Java集合基础："ArrayList是怎么扩容的？fail-fast产生的原因呢？"
谢飞机的回答令人啼笑皆非："初始就很大，然后不够就翻倍吧？迭代器一边遍历一边改会报错，是因为它生气了。"这种拟人化的解释虽然有趣，但显然不够专业。
实际上，ArrayList的扩容机制是这样的：
- JDK8采用了懒加载策略，初始时并不分配数组空间，首次add操作时才将容量设为默认值10
- 当元素数量超过当前容量时，会触发扩容，新容量计算公式为：newCapacity = oldCapacity + (oldCapacity >> 1)，即增加约50%
- 扩容过程涉及创建新数组并将旧数组元素复制过去，这是一个相对耗时的操作
fail-fast机制是Java集合框架的一个重要设计：
- 迭代器内部维护一个modCount变量，记录集合的结构性修改次数
- 在迭代过程中，如果检测到modCount发生变化（说明集合被并发修改），就会抛出ConcurrentModificationException
- 这是一种快速失败机制，目的是尽早发现并发修改问题，避免更严重的错误
实际开发中，如果需要在遍历时修改集合，应该使用迭代器的remove方法，或者考虑使用线程安全的并发集合类。
2.2 HashMap的核心机制与并发问题
第二个问题转向了HashMap："HashMap的寻址、扩容、树化阈值？并发场景会出什么问题？"
谢飞机再次给出了令人捧腹的回答："下标就是hash%size，超过8就树化，线程多就大家排队用吧，问题不大。"面试官只能无奈地表示："先记一下问题大。"
HashMap的核心机制确实值得深入理解：
-
寻址机制：
- 计算key的hash值，通过spread方法进一步处理
- 最终下标计算：index = (n - 1) & hash，其中n是table长度（必须是2的幂）
- 这种位运算比取模运算效率更高
-
扩容机制：
- 默认负载因子0.75，当元素数量达到capacity*loadFactor时触发扩容
- 扩容时创建新table（大小为原table的2倍），并重新计算所有元素的位置
- 这个过程称为rehash，是一个相对耗时的操作
-
树化机制：
- 当单个桶中的链表长度达到8且table容量≥64时，链表会转换为红黑树
- 这是为了防止哈希碰撞导致的性能退化
- 当树节点减少到6时，会转换回链表
并发场景下，HashMap确实存在严重问题：
- JDK7中，多线程扩容可能导致环形链表，进而引发死循环
- 多线程put操作可能导致数据丢失或覆盖
- 解决方案是使用ConcurrentHashMap或外部同步机制
2.3 volatile与synchronized的选择
第三个问题考察了并发编程基础："volatile和synchronized的区别？在商品列表里哪个更合适？"
谢飞机的回答再次展现了"水货"本色："volatile让变量更'鲜活'，synchronized是锁门。列表嘛，用volatile就完事了！"面试官只能提醒："场景选择要谨慎。"
这两种同步机制确实有本质区别：
-
volatile：
- 保证变量的可见性（一个线程的修改对其他线程立即可见）
- 防止指令重排序
- 但不保证复合操作的原子性（如i++）
-
synchronized：
- 保证代码块的互斥访问
- 保证可见性和原子性
- 支持锁升级机制（偏向锁->轻量级锁->重量级锁）
在商品列表场景中：
- 对于简单的状态标志（如是否正在加载），可以使用volatile