面试官：你叫谢飞机？来吧，今天面个Java，别让我失望

面试官：你叫谢飞机？来吧，今天面个Java，别让我失望

某互联网大厂，下午两点，会议室里空调吹得人脊背发凉。面试官老李推了推眼镜，翻开一份花里胡哨的简历。

第一轮：Java基础摸底

面试官：（低头扫了一眼简历）"谢飞机是吧？名字挺有创意。先来个简单的热热身——HashMap的底层数据结构是什么？"

谢飞机：（搓了搓手，眼睛一亮）"这个我熟！JDK 1.8之前是数组+链表，1.8之后变成了数组+链表+红黑树！当链表长度超过8、数组长度大于等于64的时候，链表就会转成红黑树。"

面试官：（微微点头）"不错，基本功还可以。那我接着问——HashMap为什么线程不安全？能不能举个例子？"

谢飞机：（信心上来了）"因为并发put的时候可能会导致数据覆盖，比如两个线程同时计算出的index一样，后put的会把前一个覆盖掉。还有1.7版本扩容的时候头插法会形成环形链表，CPU直接干到100%！"

面试官：（露出一丝笑意）"嗯，说到扩容——HashMap的扩容机制是怎样的？加载因子为什么默认是0.75？"

谢飞机：（开始飘了）"扩容就是容量不够了翻倍扩容嘛，每次扩成原来的2倍。加载因子0.75嘛……"（眼神开始飘忽）"这个……大概是作者觉得0.75这个数字吉利？毕竟是经过大量统计学验证的，空间和时间的折中嘛……具体怎么算出来的我也没看过论文。"

面试官：（笑容微微收敛）"好，换个方向。ArrayList和LinkedList的区别？各自的使用场景？"

谢飞机：（又活了）"ArrayList底层是数组，查询快，O(1)；LinkedList底层是双向链表，增删快，O(1)。查多用ArrayList，增删多用LinkedList！"

面试官：（身体前倾）"你说LinkedList增删是O(1)，那我问你——在LinkedList中间位置插入一个元素，时间复杂度真的是O(1)吗？"

谢飞机：（冷汗开始冒）"额……这个……要找到中间位置得先遍历，遍历是O(n)，找到之后插入才是O(1)，所以整体应该算O(n)？"

面试官：（叹了口气）"第一轮差不多到这。休息两分钟，接下来聊聊并发。"

第二轮：并发编程深入

面试官：（喝了口茶）"刚才聊了HashMap，那你肯定知道ConcurrentHashMap。ConcurrentHashMap在JDK 1.7和1.8的实现有什么区别？"

谢飞机：（擦了擦汗）"1.7是分段锁Segment，继承自ReentrantLock，默认16个段，并发度16；1.8去掉了分段锁，改用CAS+synchronized，锁粒度更细，锁的是数组里每个Node节点。put的时候如果对应位置是null就用CAS插入，不是null就用synchronized锁住头结点。"

面试官：（重新审视了一下简历）"答得还行。说说volatile关键字，它保证什么，不保证什么？底层是怎么实现的？"

谢飞机：（来了精神）"volatile保证可见性和有序性，不保证原子性！底层是内存屏障，写之前加StoreStore屏障，写之后加StoreLoad屏障；读之后加LoadLoad和LoadStore屏障。它禁止指令重排序，保证每次读都是从主内存读，写完立刻刷回主内存。"

面试官：（点头）"不错。那线程池的核心参数有哪些？拒绝策略你用过哪些？"

谢飞机：（越说越顺）"核心参数有7个！corePoolSize核心线程数、maximumPoolSize最大线程数、keepAliveTime空闲线程存活时间、unit时间单位、workQueue工作队列、threadFactory线程工厂、handler拒绝策略。拒绝策略有四种：AbortPolicy抛异常、CallerRunsPolicy交给调用线程执行、DiscardPolicy直接丢弃、DiscardOldestPolicy丢弃队列里最老的任务。"

面试官："那你说说——一个线程池，核心线程5，最大线程10，队列容量20，当同时来30个任务时，会发生什么？"

谢飞机：（手指开始掰算）"先创建5个核心线程干活，剩下25个进队列，但队列只能装20个，所以有5个进不去，线程数没到最大10，所以会再创建5个线程……等等不对……"（陷入了混乱）"应该是先……队列满了才创建新线程……核心线程先处理，再来任务进队列，队列满了，线程数没到最大，继续创建线程直到10个，再满了执行拒绝策略……所以30个任务的话，5个核心线程处理，20个进队列，剩下5个会触发创建新线程（5个非核心线程），刚好处理完，不会触发拒绝策略。对吗？"

面试官：（面无表情）"嗯。synchronized锁升级的过程讲一下。"

谢飞机：（开始胡言乱语）"这个……无锁、偏向锁、轻量级锁、重量级锁……升级的过程大概是……嗯……偏向锁就是贴个标签说这个锁归我了，轻量级锁就是CAS自旋，重量级锁就是操作系统互斥量……升级是不可逆的……具体细节嘛，要看JVM心情。"（心虚地笑了笑）

面试官：（放下茶杯）"第二轮到此为止。出去透口气，五分钟后我们继续。"

第三轮：框架与架构

面试官：（表情更加严肃）"前面聊得还行。现在问点工程上的东西。Spring中Bean的生命周期，尽量详细。"

谢飞机：（额头开始冒汗）"嗯……实例化、属性填充、各种Aware接口回调、BeanPostProcessor前置处理、初始化、BeanPostProcessor后置处理……然后就……就就……就可以用了！销毁的时候执行destroy方法。大概就是这样吧……"

面试官："不够详细。那换个问题——Spring如何解决循环依赖？"

谢飞机：（眼神开始游离）"三级缓存！singletonObjects一级缓存放成品Bean，earlySingletonObjects二级缓存放半成品提前暴露的Bean，singletonFactories三级缓存放Bean的工厂……A依赖B，B依赖A，先创建A，发现依赖B，去创建B，B发现依赖A，从三级缓存里拿到A的早期引用，B完成创建，A也完成创建……大概是这样？"

面试官："Spring事务的传播机制有哪些？什么场景用REQUIRES_NEW？"

谢飞机：（嘴巴开始比脑子快）"有……REQUIRED、SUPPORTS、MANDATORY、REQUIRES_NEW、NOT_SUPPORTED、NEVER、NESTED，一共7种！REQUIRES_NEW嘛，就是不管外面有没有事务，自己都要开一个新事务，比如下单和发短信，发短信失败了不能影响下单……"

面试官：（打断）"那REQUIRES_NEW和NESTED的区别是什么？"

谢飞机：（彻底卡壳）"……区别……区别就是……一个是……那个……哎呀反正都是开新事务，NESTED是嵌套事务，内外事务有关系……REQUIRES_NEW是完全独立……具体的……面试官要不咱们聊聊Redis？这个我更熟！"

面试官：（冷笑了一下）"行，那你说。Redis缓存穿透、缓存击穿、缓存雪崩分别是什么？怎么解决？"

谢飞机：（像抓住了救命稻草）"这个我背过！穿透是查不存在的数据，用布隆过滤器或者把null也缓存起来；击穿是热点key过期，用互斥锁或者逻辑过期；雪崩是大面积key同时过期，给过期时间加随机值，或者用Redis集群高可用！"

面试官："Redis的持久化机制RDB和AOF有什么区别？你们线上用的哪种？"

谢飞机：（开始放飞自我）"RDB是快照，隔一段时间把内存数据存到磁盘上，恢复快但可能丢数据；AOF是追加写命令日志，数据更安全但文件大恢复慢。线上嘛……我们两个都开！Redis 4.0之后还有混合持久化，RDB+AOF一起上，又快又安全！"

面试官："MySQL的索引底层为什么用B+树而不是B树或者红黑树？"

谢飞机：（彻底摆烂）"因为……因为B+树矮胖，层数低，IO次数少！非叶子节点不存数据，一页能存更多索引，查找稳定都得走到叶子节点。红黑树太高了，层数多IO多，不适合磁盘存储。B树嘛……非叶子节点存数据，范围查询不如B+树方便……差不多就这些吧，面试官，我有点渴了。"

面试官：（合上笔记本，摘下眼镜擦了擦）"行了谢飞机，今天的面试就到这。你的基础还不错，但深度明显不够。回去等通知吧，有结果我们会联系你的。"

谢飞机：（起身，挤出笑容）"好的好的，谢谢面试官！那个……大概多久会有通知？"

面试官：（头也不抬）"看HR安排。"

谢飞机走出会议室，长舒一口气。打开手机，默默点开B站收藏夹——「Java面试八股文，三天速成进大厂」。

答案解析

下面是对本次面试中涉及的技术问题的详细解析，适合小白系统学习。

一、HashMap底层数据结构

1. 数据结构演变

JDK 1.7：数组 + 链表（头插法）

JDK 1.8：数组 + 链表 + 红黑树（尾插法）

// HashMap内部结构简化示意 class HashMap<K,V> { Node<K,V>[] table; // 数组，每个元素是一个桶(bucket) } class Node<K,V> { final int hash; final K key; V value; Node<K,V> next; // 指向下一个节点，形成链表 } // 红黑树节点（当链表长度>=8且数组长度>=64时转换） class TreeNode<K,V> extends Node<K,V> { TreeNode<K,V> parent; TreeNode<K,V> left; TreeNode<K,V> right; TreeNode<K,V> prev; boolean red; }

2. 为什么链表转红黑树的阈值是8？

根据泊松分布，当负载因子为0.75时，链表长度达到8的概率极低（约千万分之一），所以8是一个比较合适的阈值。而退化为链表的阈值是6，留一个缓冲区间避免反复转换。

3. HashMap线程不安全的原因

• JDK 1.7：扩容时采用头插法，多线程环境下可能形成环形链表，导致get()时CPU 100%
• JDK 1.8：虽然尾插法避免了环形链表，但put()操作不是原子性的，可能导致数据覆盖
• 可见性问题：一个线程put后，另一个线程可能看不到最新数据

二、HashMap扩容机制

扩容时机

当size > threshold时触发扩容，threshold = capacity * loadFactor。

扩容过程（JDK 1.8）

// 扩容核心逻辑简化 final Node<K,V>[] resize() { Node<K,V>[] oldTab = table; int oldCap = oldTab.length; int newCap = oldCap << 1; // 容量翻倍 // 遍历旧数组 for (int j = 0; j < oldCap; j++) { Node<K,V> e = oldTab[j]; if (e != null) { // 单节点直接重新计算位置 // 链表：分成高位链和低位链 // 红黑树：同样拆分成高低位，必要时退化为链表 } } }

为什么加载因子是0.75？

这是一个时间和空间的权衡：

• 加载因子过小（如0.5）：空间利用率低，但哈希冲突少，查询效率高
• 加载因子过大（如1.0）：空间利用率高，但哈希冲突多，链表/红黑树变长，查询效率降低
• 0.75经过大量统计学测试，平衡了时间和空间

三、ArrayList vs LinkedList

| 特性 | ArrayList | LinkedList | |------|-----------|------------| | 底层结构 | 动态数组（Object[]） | 双向链表 | | 随机访问 | O(1) | O(n) | | 头部插入 | O(n) | O(1) | | 尾部插入 | 均摊O(1) | O(1) | | 中间插入 | O(n)（需要移动元素） | O(n)（需要遍历找到位置） | | 内存占用 | 连续内存，较少 | 每个节点额外存储前后指针 |

关键点：LinkedList在中间位置插入，需要先遍历找到位置（O(n)），然后插入才是O(1)，整体是O(n)。

// LinkedList的add(int index, E element)源码 public void add(int index, E element) { checkPositionIndex(index); if (index == size) { linkLast(element); } else { linkBefore(element, node(index)); // node(index)需要O(n)遍历 } }

四、ConcurrentHashMap（JDK 1.7 vs 1.8）

JDK 1.7：分段锁（Segment）

// 结构：Segment数组，每个Segment持有一把ReentrantLock // 默认16个Segment，并发度16 class Segment<K,V> extends ReentrantLock { HashEntry<K,V>[] table; }

• 每次put只锁住对应的Segment
• 不同Segment之间可以并发操作
• 缺点：并发度受限于Segment数量

JDK 1.8：CAS + synchronized

// put方法核心逻辑 final V putVal(K key, V value, boolean onlyIfAbsent) { // 1. 计算hash // 2. for循环 + CAS for (Node<K,V>[] tab = table;;) { // 如果数组未初始化，CAS初始化 // 如果桶为空，CAS插入节点 // 如果正在扩容，帮助扩容 // 否则，synchronized锁住桶的头节点进行插入 } }

• 锁粒度更细：每个桶（Node）独立加锁
• 使用CAS进行无锁操作（如初始化、空桶插入）
• 并发扩容：多线程协助扩容（ForwardingNode机制）

五、volatile关键字

三大特性

| 特性 | 是否保证 | 说明 | |------|---------|------| | 可见性 | ✅ | 一个线程修改后，其他线程立即可见 | | 有序性 | ✅ | 禁止指令重排序 | | 原子性 | ❌ | i++等复合操作不保证原子性 |

底层实现：内存屏障

// volatile写 // StoreStore屏障：禁止上面的普通写和下面的volatile写重排序 // volatile写操作 // StoreLoad屏障：禁止上面的volatile写和下面的volatile读/写重排序 // volatile读 // volatile读操作 // LoadLoad屏障：禁止下面的普通读和上面的volatile读重排序 // LoadStore屏障：禁止下面的普通写和上面的volatile读重排序

经典应用：DCL单例模式

public class Singleton { private static volatile Singleton instance; // 必须volatile public static Singleton getInstance() { if (instance == null) { // 第一次检查 synchronized (Singleton.class) { if (instance == null) { // 第二次检查 instance = new Singleton(); // 可能重排序导致问题 } } } return instance; } }

new Singleton()不是原子操作，分为三步：

1. 分配内存空间
2. 初始化对象
3. 将引用指向内存地址

如果没有volatile，2和3可能重排序，导致其他线程拿到未初始化完成的对象。

六、线程池核心参数与工作原理

7个核心参数

public ThreadPoolExecutor(int corePoolSize, // 核心线程数 int maximumPoolSize, // 最大线程数 long keepAliveTime, // 非核心线程空闲存活时间 TimeUnit unit, // 时间单位 BlockingQueue<Runnable> workQueue, // 工作队列 ThreadFactory threadFactory, // 线程工厂 RejectedExecutionHandler handler) // 拒绝策略

任务处理流程

提交任务 ↓ 核心线程是否已满？ ├── 否 → 创建核心线程执行任务 └── 是 → 队列是否已满？ ├── 否 → 任务入队等待 └── 是 → 线程数是否达到最大值？ ├── 否 → 创建非核心线程执行任务 └── 是 → 执行拒绝策略

四种拒绝策略

| 策略 | 行为 | |------|------| | AbortPolicy | 抛出RejectedExecutionException（默认） | | CallerRunsPolicy | 由提交任务的线程自己执行 | | DiscardPolicy | 直接丢弃，不抛异常 | | DiscardOldestPolicy | 丢弃队列中最旧的任务，重新提交当前任务 |

题目场景分析

核心线程5，最大线程10，队列容量20，同时来30个任务

1. 前5个任务：创建5个核心线程处理
2. 第6~25个任务（20个）：核心线程已满，进入队列
3. 第26~30个任务（5个）：队列已满，线程数(5) < 最大线程数(10)，创建5个非核心线程
4. 结果：30个任务全部被处理，不会触发拒绝策略

七、synchronized锁升级

这是JDK 6引入的优化，锁状态从低到高依次为：

无锁 → 偏向锁 → 轻量级锁 → 重量级锁

各阶段详解

| 锁状态 | 实现方式 | 适用场景 | |--------|---------|---------| | 无锁 | 无 | 无竞争 | | 偏向锁 | Mark Word记录线程ID | 只有一个线程反复获取锁 | | 轻量级锁 | CAS自旋 | 少量线程交替执行，持有锁时间短 | | 重量级锁 | 操作系统互斥量 | 线程竞争激烈，持有锁时间长 |

升级过程

// Mark Word中锁标记位 // 无锁：001 // 偏向锁：101 // 轻量级锁：00 // 重量级锁：10 // 升级流程： // 1. 偏向锁：第一次获取锁时，CAS将线程ID写入Mark Word // 2. 偏向锁撤销：其他线程竞争时，撤销偏向锁 // 3. 轻量级锁：撤销后升级，线程在栈帧中创建Lock Record，CAS竞争 // 4. 自旋失败次数达到阈值（默认10次）或等待线程数超过CPU核数一半 // 5. 升级为重量级锁：挂起线程，由操作系统调度

注意：锁升级是单向不可逆的。

八、Spring Bean生命周期

完整生命周期如下：

1. 实例化（Instantiation） └── 通过反射创建Bean实例 2. 属性填充（Populate Properties） └── 包括@Autowired注入等 3. BeanNameAware.setBeanName() 4. BeanFactoryAware.setBeanFactory() 5. ApplicationContextAware.setApplicationContext() 6. BeanPostProcessor.postProcessBeforeInitialization() 7. @PostConstruct 或 InitializingBean.afterPropertiesSet() 8. init-method（自定义初始化方法） 9. BeanPostProcessor.postProcessAfterInitialization() └── AOP代理在此阶段生成 10. Bean就绪，可以使用 11. @PreDestroy 或 DisposableBean.destroy() 12. destroy-method（自定义销毁方法）

九、Spring三级缓存解决循环依赖

三级缓存

// DefaultSingletonBeanRegistry中 /** 一级缓存：存放完全初始化的Bean */ Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256); /** 二级缓存：存放早期暴露的半成品Bean（未完成属性填充） */ Map<String, Object> earlySingletonObjects = new HashMap<>(16); /** 三级缓存：存放Bean工厂，用于生成Bean的早期代理引用 */ Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);

解决流程（A ↔ B循环依赖）

1. 创建A → 实例化 → 将A的ObjectFactory放入三级缓存 2. 填充A的属性 → 发现依赖B 3. 去创建B → 实例化B → B的ObjectFactory放入三级缓存 4. 填充B的属性 → 发现依赖A 5. 从三级缓存获取A → 调用ObjectFactory.getObject() → 得到A的早期引用 6. 将A的早期引用放入二级缓存，从三级缓存移除 7. B拿到A的引用，完成属性填充 → B初始化完成 → B放入一级缓存 8. 回到A，A拿到B的引用，完成属性填充 → A初始化完成 → A放入一级缓存

为什么需要三级缓存？

二级缓存其实就够解决普通循环依赖。三级缓存的存在是为了处理AOP代理的情况：当循环依赖的Bean需要AOP代理时，需要在实例化完成后、属性填充前就生成代理对象，三级缓存的ObjectFactory就是在此时发挥作用。

十、Spring事务传播机制

7种传播行为

| 传播行为 | 说明 | |----------|------| | REQUIRED（默认） | 有事务则加入，无则新建 | | SUPPORTS | 有事务则加入，无则非事务执行 | | MANDATORY | 必须存在事务，否则抛异常 | | REQUIRES_NEW | 无论如何都新建事务，挂起当前事务 | | NOT_SUPPORTED | 非事务执行，挂起当前事务 | | NEVER | 必须非事务执行，否则抛异常 | | NESTED | 嵌套事务，使用Savepoint |

REQUIRES_NEW vs NESTED

// REQUIRES_NEW：完全独立的新事务 @Transactional(propagation = Propagation.REQUIRED) public void outer() { innerService.method(); // 新事务，outer事务被挂起 // outer和inner完全独立，互不影响 } // NESTED：嵌套事务，依赖外部事务 @Transactional(propagation = Propagation.NESTED) public void inner() { // 外部事务回滚，内部一定回滚 // 内部事务回滚到savepoint，不影响外部 }

| 对比 | REQUIRES_NEW | NESTED | |------|-------------|--------| | 事务独立性 | 完全独立 | 嵌套，依赖外部 | | 外部回滚影响内部 | 不影响 | 内部一定回滚 | | 内部回滚影响外部 | 不影响 | 不影响（回滚到savepoint） | | 实现方式 | 独立的数据库连接 | Savepoint机制 |

十一、Redis缓存三大问题

缓存穿透

问题：查询一个数据库中不存在的数据，缓存中没有，每次都穿透到数据库。

解决方案：

// 方案一：缓存空值 if (data == null) { redis.set(key, "NULL", 60); // 缓存空值，设置较短过期时间 } // 方案二：布隆过滤器 BloomFilter bloomFilter = new BloomFilter(); // 初始化时将所有已存在的key加载到布隆过滤器 if (!bloomFilter.mightContain(key)) { return null; // 直接返回，不查数据库 }

缓存击穿

问题：热点key过期，大量请求同时打向数据库。

解决方案：

// 互斥锁方案 public String getData(String key) { String value = redis.get(key); if (value == null) { // 加锁，只有一个线程去查数据库 if (redis.setnx("lock:" + key, "1", 10)) { try { value = db.query(key); redis.set(key, value, 3600); } finally { redis.del("lock:" + key); } } else { Thread.sleep(50); return getData(key); // 递归重试 } } return value; } // 逻辑过期方案：value中存储过期时间，异步更新，不阻塞请求

缓存雪崩

问题：大量key同时过期，或者Redis宕机，所有请求打到数据库。

解决方案：

// 1. 过期时间加随机值 int expireTime = 3600 + new Random().nextInt(600); // 1小时 + 随机0~10分钟 // 2. Redis集群（主从+哨兵/Cluster模式） // 3. 多级缓存（本地缓存 + Redis） // 4. 限流降级

十二、Redis持久化机制

RDB（Redis Database）

# 配置文件 save 900 1 # 900秒内至少1次修改则触发快照 save 300 10 # 300秒内至少10次修改 save 60 10000 # 60秒内至少10000次修改

• 优点：文件紧凑，恢复速度快，适合备份
• 缺点：可能丢失最后一次快照后的数据

AOF（Append Only File）

# 配置 appendonly yes appendfsync always # 每条命令都同步（最安全，最慢） appendfsync everysec # 每秒同步一次（推荐，最多丢1秒数据） appendfsync no # 由操作系统决定

• 优点：数据安全性高，最多丢1秒数据
• 缺点：AOF文件体积大，恢复慢

混合持久化（Redis 4.0+）

aof-use-rdb-preamble yes

AOF文件前半部分是RDB格式的快照，后半部分是增量AOF命令，兼顾了恢复速度和数据安全。

十三、MySQL索引：为什么是B+树？

B+树 vs B树

| 对比维度 | B树 | B+树 | |----------|-----|------| | 数据存储 | 叶子节点和非叶子节点都存数据 | 只有叶子节点存数据 | | 非叶子节点 | 存数据和索引 | 只存索引（key） | | 叶子节点 | 独立 | 有指针相连（双向链表） | | 范围查询 | 需要中序遍历 | 遍历叶子节点链表即可 | | 查询稳定性 | 可能在非叶子节点命中 | 必须到叶子节点 |

B+树 vs 红黑树

• B+树是多叉树，红黑树是二叉树
• 同样数据量，B+树高度远低于红黑树
• 数据库索引存储在磁盘，每次查找需要IO
• B+树层数少 → IO次数少 → 查询快

为什么不用Hash索引？

• Hash索引只支持等值查询，不支持范围查询
• Hash索引无法排序
• Hash冲突时效率下降
• 联合索引无法利用最左前缀

InnoDB中B+树的特点

-- 聚簇索引（主键索引）：叶子节点存储完整行数据 -- 二级索引：叶子节点存储主键值，需要回表查询 -- 覆盖索引：查询的列都在索引中，不需要回表 EXPLAIN SELECT id, name FROM user WHERE name = '张三'; -- Extra: Using index （覆盖索引，不需要回表）

总结

这篇文章通过一场面试对话，覆盖了Java后端面试中的核心知识点。从基础的数据结构（HashMap、ArrayList），到并发编程（volatile、synchronized、线程池、ConcurrentHashMap），再到框架和中间件（Spring、Redis、MySQL），形成了一套完整的面试知识体系。建议读者不仅背诵答案，更要理解背后的原理，这样才能在面试中游刃有余。

至少，别像谢飞机一样，回去还得打开B站学八股文。😄