2023版Java面试八股文：核心考点与高频追问拆解-平芜编程栈

简介：《Java面试八股文2023最新版》面向准备跳槽、校招或社招面试的Java开发者，聚焦高频八股与知识体系梳理，覆盖Java SE基础、集合、JVM、多线程与并发、异常处理，以及Spring、SpringBoot、SpringCloud、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Redis、MySQL、Nginx、Linux等常见技术栈。压缩包共1个PDF文件，大小约9.43MB，按基础篇、JVM篇、多线程与并发篇、Spring篇等模块组织，目录清晰，便于按专题检索和查漏补缺。已有15846人学习，适合用作面试前快速复盘、知识点串联与高频题自测，也可结合项目经验补充设计模式、性能优化等延伸内容。

1. 面试官视角：Java 面试八股文到底考什么，分怎么给

Java 面试八股文背到第三遍，还是有人会在「HashMap 的长度为什么是 2 的 N 次方」上卡住——不是没背过，是只答到「散列均匀」就停了。这场面试考的不是记忆力，是你能不能把一个结论拆成「为什么这么设计、不这么设计会怎样、你在项目里怎么用」三层。分值上，Java SE 基础与集合大概占三成，并发与 JVM 占三成，框架与中间件（Spring、SpringBoot、MyBatis、MySQL、Redis、MQ）占三成，剩下一成给表达和追问应对。这份 2023 版整理从基础篇一路排到 ZooKeeper、Dubbo、Nginx、Git 和软实力，题量足够撑起一轮完整复习，适合工作一年多想跳槽、需要一份能直接背能直接练的清单的人。下面按考点密度从高到低拆开讲。

2. 基础篇与集合：equals、String、HashMap 这十几道题决定第一印象

面试前十分钟，面试官通常从基础篇挑三到五道热身。答得利索，后面就愿意往并发和框架深聊；答得含糊，时间会耗在这里，你准备最充分的 JVM 调优根本没机会说出口。基础篇的题看着零散，其实只有三条主线：类型与对象（基本类型、装箱拆箱、equals 与 hashCode、深拷贝浅拷贝）、字符串（String 三兄弟、常量池）、语言机制（重载重写、final、static、泛型、反射、序列化）。把这三条主线捋顺，二十多道题就是同一套话术的不同变体。

2.1 基础篇考点分布：二十二道题里真正会问的八道

先看一张密度表，判断哪些题值得背到能脱口而出，哪些题知道关键词就够。

考点	高频问法	常见追问	建议投入
基本类型与封装类	八种类型占几个字节、默认值	int 和 Integer 的区别、包装类缓存	高
equals 与 hashCode	两者区别、为什么要一起重写	不相等的对象能有相同 hashCode 吗	高
String 三兄弟	三者区别、为什么不可变	常量池、intern、循环拼接	高
重载与重写	区别、返回值能不能作为重载依据	静态方法能不能被重写	中
final 与 static	各自用法	static 代码块执行时机	中
深拷贝浅拷贝	区别、怎么实现	序列化实现深拷贝的代价	中
四种引用	强软弱虚的区别和场景	软引用适合做缓存吗	低
反射与序列化	原理、哪里用过	为什么 serialVersionUID 要显式写	低

八种基本类型这块，真正容易翻车的不是字节数，而是「int 默认 0、Integer 默认 null」这个差异带来的业务含义：数据库查出来是 null，用 Integer 接能区分「没查到」和「查到了 0」，用 int 接就会把 null 悄悄变成 0。回答时主动补这一句，比单纯背表格更像干过活的人。boolean 的字节数别死记，说清楚「单独使用编译后按 int 处理，数组里按 byte 处理」即可，这是规范层面的细节，答出来是加分项。

重载与重写的分界线要一句话讲透：重载是编译期决定的，同一个类里方法名相同、参数列表不同，跟返回值无关；重写是运行期决定的，子类方法签名必须与父类一致，访问权限不能更小，抛出的受检异常不能更宽。面试官常追问「静态方法能不能被重写」，答案是「不能，静态方法属于类，子类同名静态方法是隐藏，不是重写」，再补一句「private 方法同理，编译期就绑定了」。

final 的三种用法按「类、方法、变量」讲，变量再分基本类型（值不能改）和引用类型（引用不能改，对象内容可以改）。static 按「静态变量、静态方法、静态代码块、静态内部类、静态导入」讲，重点是静态代码块在类初始化阶段执行，且只执行一次，常被用来做配置预加载。深拷贝浅拷贝的回答骨架是：浅拷贝只复制引用，两个对象共享同一个内部对象；深拷贝递归复制，常用重写 clone、序列化反序列化、手写拷贝构造三种方式，序列化方式简单但性能差，还要注意类必须实现 Serializable。

2.2 equals 与 ==、hashCode 三件套：真题演练

这道题几乎每场必问，但真正拉开差距的是第二问。

面试题：equals 与 == 的区别是什么？两个不相等的对象有可能有相同的 hashCode 吗？

答题思路分三层。第一层给结论：== 比较的是值或引用地址，基本类型比值，引用类型比是不是同一个对象；equals 是 Object 的方法，默认实现就是 ==，重写之后才比较内容。第二层说清「谁重写了」：String、Integer 这些包装类都重写了 equals，所以new String("a").equals("a")是 true，而==是 false。第三层主动把 hashCode 拉进来：重写 equals 必须重写 hashCode，因为哈希类集合先用 hashCode 定位桶，再用 equals 比内容，只重写 equals 会导致两个「相等」的对象散落在不同桶里，HashSet 里出现两条重复数据。

第二个问号的答案是「可以」，而且要给出理由：hashCode 是把对象映射到 int 的散列函数，冲突不可避免，Java 只约定两条规则——equals 相等的两个对象 hashCode 必须相等，hashCode 相等的两个对象 equals 不一定相等。下面这段代码是现成的例子。

// String 的 hashCode 按 31 进制累加，"Aa" 和 "BB" 恰好算出同一个值 System.out.println("Aa".hashCode()); // 2112 System.out.println("BB".hashCode()); // 2112 System.out.println("Aa".equals("BB")); // false，内容不同

这段代码说明的是散列碰撞的合理性，不是 String 的实现 bug。面试官紧接着会问「那 HashMap 怎么处理碰撞」，回答要点是：先对 hashCode 做扰动（高 16 位异或低 16 位）再和n-1做与运算定位下标，冲突时挂在链表上，链表长度到 8 且数组容量到 64 就转红黑树，查找时先比 hash 再比 equals。参数上记住三个数：默认容量 16、负载因子 0.75、树化阈值 8、退化阈值 6。这一串报出来，比只说「用链表和红黑树解决冲突」扎实得多。

2.3 String 三兄弟与装箱拆箱：三道最容易答浅的题

String 为什么不可变，标准答法是「内部数组被 final 修饰且不对外暴露修改方法，所有拼接操作都返回新对象」。价值在于三点：可以安全地放进常量池复用、hashCode 可以缓存、多线程下天然安全。StringBuffer 的方法加了 synchronized，线程安全但慢；StringBuilder 不加锁，单线程首选。回答时补一句实战经验：「循环里拼字符串必须用 StringBuilder，用 + 会在每次循环 new 一个 StringBuilder，数据量大时是明显的性能坑」。

面试题：3 * 0.1 == 0.3的返回值是什么？

答案是 false。0.1 在二进制里是无限循环小数，double 只能存近似值，3 乘完之后是 0.30000000000000004。正确做法是用 BigDecimal，而且必须用字符串构造，用 double 构造会把误差原样带进去。

System.out.println(3 * 0.1); // 0.30000000000000004 System.out.println(3 * 0.1 == 0.3); // false System.out.println(new BigDecimal("0.1") .multiply(new BigDecimal("3")) .equals(new BigDecimal("0.3"))); // true，字符串构造无误差

三个输出分别对应三个考点：浮点数的二进制表示误差、== 对 double 做精确比较不可靠、BigDecimal 构造参数必须传字符串。参数说明上再补一句：BigDecimal 的 equals 会比较 scale（小数位数），new BigDecimal("0.30")和new BigDecimal("0.3")用 equals 比是 false，要比值大小应该用 compareTo。

装箱拆箱的经典题是Integer a = 127, b = 127与Integer c = 128, d = 128的对比。前者 true，后者 false，因为 Integer 内部有 -128 到 127 的缓存数组，命中缓存返回同一对象，超出范围就 new。缓存上界可以通过虚拟机参数调整，下界固定。回答时落到实践：包装类比较一律用 equals，或者先拆箱成基本类型，别用 ==。

还有一道冷门但常考的：a = a + b与a += b的区别。后者隐含强制类型转换，short s = 1; s += 1能编译通过，s = s + 1编译报错，因为加法结果提升为 int。try-catch-finally 那道题的标准答法是：finally 一定执行，除非执行了System.exit或进程被终止；如果 try 里有 return，先算返回值存起来，执行完 finally 再返回，而 finally 里写 return 会覆盖掉 try 的返回值，所以规范上禁止在 finally 里 return。

2.4 集合考点：ArrayList、LinkedList 与 fail-fast

ArrayList 底层是 Object 数组，第一次 add 时分配默认容量 10，扩容按旧容量的 1.5 倍（oldCap + (oldCap >> 1)），扩容时整体复制。查询 O(1)，中间插入删除 O(n)。LinkedList 是双向链表，头尾增删 O(1)，随机访问 O(n)，每个节点额外存两个引用，内存开销更大。面试官追问「有数组了为什么还要 ArrayList」，答四点：封装了自动扩容、提供了完整的 List API、支持泛型、能和集合框架其他部分互操作，最后补一句「ArrayList 不是线程安全的，多线程读可以用Collections.unmodifiableList，读写混合场景用 CopyOnWriteArrayList 或加锁」。

fail-fast 是集合篇的高频追问。机制是 ArrayList 内部维护 modCount，每次结构修改加一，迭代器创建时记下 expectedModCount，每次 next 检查两者是否相等，不等就抛 ConcurrentModificationException。注意两点：这是「尽力而为」的检测机制，不保证一定触发；正确删除元素应该用iterator.remove()或removeIf，不要在 for-each 里直接调 list.remove。

2.5 HashMap 连环追问：从 2 的 N 次方到红黑树

第一问，key 能不能用任何类。可以，但必须正确重写 hashCode 和 equals，否则 get 不到。更要命的是用可变对象做 key：put 进去之后改了对象里参与 hash 计算的字段，hashCode 变了，桶的位置变了，再 get 就找不到。所以实践里 key 优先选 String、Integer 这类不可变类。

第二问，长度为什么必须是 2 的 N 次方。这里最容易只答一句「散列均匀」。完整说法是：定位下标用(n - 1) & hash代替取模，位运算比除法快；n 是 2 的幂时 n-1 的二进制低位全是 1，与运算结果分布更均匀；扩容成 2 倍后，元素的新位置只有两种可能——原位置，或者原位置加 oldCap，判断依据是 hash 与新容量对应的那一位是 0 还是 1，完全不用重算 hash。把「扩容时不用重新计算 hash」说出来，面试官会认为你真读过源码。

第三问，HashMap 与 ConcurrentHashMap 的异同。相同点是底层结构一致，都是数组加链表加红黑树，扩容逻辑也类似。不同点列三条：HashMap 非线程安全，ConcurrentHashMap 用 CAS 加 synchronized 锁单个桶头节点，锁粒度细；ConcurrentHashMap 的 key 和 value 都不允许 null，因为并发下无法区分「没有这个 key」和「值就是 null」；size 的实现用 baseCount 加 CounterCell 分散计数，避免单一变量成为热点。

第四问，红黑树的特征。答五条：节点非红即黑；根节点是黑；叶子节点（NIL）是黑；红节点的子节点必须是黑；从任一节点到其所有叶子的路径上黑节点数量相同。补一句「最长路径不超过最短路径的两倍，所以是近似平衡，插入删除的旋转次数比 AVL 少，适合读写都频繁的场景」。

第五问，Hashtable 与 HashMap 的区别，用表格对比最清楚。

维度	HashMap	Hashtable	ConcurrentHashMap
线程安全	否	是，方法级 synchronized	是，CAS 加桶级锁
null 支持	key 和 value 都可以为 null	都不允许	都不允许
默认容量	16	11	16
扩容方式	2 倍	2n+1	2 倍，支持多线程协助扩容
迭代行为	fail-fast	枚举器不抛 CME	弱一致性迭代器

这张表的用法是：面试官问哪一格就答哪一格，别一口气全背。最后主动收一句「所以新项目里没有理由再用 Hashtable，需要线程安全就用 ConcurrentHashMap」。

3. 并发与 JVM：synchronized、线程池、GC 的追问最深

并发和 JVM 是区分「背过」和「懂了」的分水岭。这两块的题有个共同特点：结论很短，追问很长。你说 volatile 保证可见性，面试官马上问「那它保证原子性吗」；你说线程池有七个参数，下一句就是「核心线程数你怎么设」。准备策略不是多背题，而是每道题都准备三层——定义、原理、一个真实参数或场景。

3.1 并发考点地图：从线程创建到线程池七参数

创建线程的方式，标准答法是四种：继承 Thread、实现 Runnable、实现 Callable 配合 FutureTask、用线程池。答题时补一句「前三种是语法层面，生产环境只用线程池」，直接把话题引向你准备更充分的地方。

线程状态记六个：NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED。BLOCKED 特指等 synchronized 锁，WAITING 是调用了 wait、join、park 之后的无期限等待，这个区分常被追问。

sleep 与 wait 的区别要答四条：sleep 是 Thread 的静态方法，wait 是 Object 的实例方法；sleep 不释放锁，wait 释放锁；sleep 到时自动唤醒，wait 需要 notify 或超时；wait 必须在同步块里调用，否则抛 IllegalMonitorStateException。最后一条常被追问「为什么」，答案是避免丢失唤醒——如果 wait 不在同步块里，可能在判断条件之后、调用 wait 之前，另一个线程已经 notify 完了，当前线程再 wait 就永远醒不过来。

volatile 的两个语义：保证可见性（写操作后插入写屏障，强制刷回主存并让其他 CPU 缓存行失效）、禁止指令重排（通过内存屏障）。它不保证原子性，i++这种复合操作照样出问题，要原子性用 AtomicInteger 或加锁。典型使用场景是状态标志位和双重检查锁定的单例字段。

synchronized 的锁升级路径是：无锁 → 偏向锁 → 轻量级锁 → 重量级锁。偏向锁记录线程 ID，同一线程重入不用 CAS；有竞争就升级为轻量级锁，用 CAS 自旋；自旋失败再升级为重量级锁，线程挂起进入等待队列。锁信息存在对象头的 Mark Word 里。修饰实例方法锁的是 this，修饰静态方法锁的是 Class 对象，修饰代码块锁的是括号里的对象。

线程池七个参数必须能一口气报出来：corePoolSize、maximumPoolSize、keepAliveTime、TimeUnit、workQueue、threadFactory、handler。执行流程是：核心线程未满就建核心线程；核心满了进队列；队列满了且未到最大线程数就建非核心线程；都满了走拒绝策略。四种拒绝策略：AbortPolicy 抛异常（默认）、CallerRunsPolicy 让提交任务的线程自己跑、DiscardPolicy 静默丢弃、DiscardOldestPolicy 丢掉队列里最老的任务再提交。

3.2 真题演练：三个线程 T1、T2、T3 按顺序执行

面试题：有三个线程 T1、T2、T3，如何保证它们按顺序执行？

最直接的答法是 join，代码短，逻辑清楚。

public class OrderedRun { public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> System.out.println("T1"), "T1"); Thread t2 = new Thread(() -> System.out.println("T2"), "T2"); Thread t3 = new Thread(() -> System.out.println("T3"), "T3"); t1.start(); t1.join(); // 主线程阻塞，直到 t1 终止 t2.start(); t2.join(); // 保证 t2 在 t1 之后、t3 之前 t3.start(); } }

这段代码的逻辑是：join 把调用方线程（这里是主线程）挂起，直到目标线程执行完毕，所以 t2 的 start 一定发生在 t1 结束之后。参数上 join 有无参和带毫秒两个重载，带超时的版本到点就返回，不保证目标线程已结束。底层实现是循环判断目标线程的 isAlive，活着就 wait，线程终止时 JVM 会 notifyAll 唤醒等待者。

这个答法的局限要主动说出来：三个线程必须是「启动一个、等一个、再启动下一个」，如果三个线程已经同时 start 了，join 就排不了序。那种场景要用 CountDownLatch：T3 先 await T2 的闩锁，T2 await T1 的闩锁，T1 跑完 countDown。或者更简单，用单线程线程池Executors.newSingleThreadExecutor()依次 submit。面试时给出两种以上方案并说明各自代价，比只背一个 join 强。

3.3 JVM 内存模型与对象创建：从类加载到对象头

运行时数据区按线程私有和共享分。私有三块：程序计数器（当前字节码行号，唯一不会 OOM 的区域）、虚拟机栈（栈帧里放局部变量表、操作数栈、动态链接、返回地址）、本地方法栈。共享两块：堆（对象实例，分新生代 Eden 加两个 Survivor 加老年代，默认比例 8:1:1）、方法区（JDK 8 之后用元空间实现，放在本地内存）。

对象创建过程五步：类加载检查（能不能在常量池定位到类符号引用、类是否已加载）、分配内存（规整的堆用指针碰撞，不规整的用空闲列表；并发安全靠 CAS 重试或 TLAB 本地分配缓冲）、初始化零值、设置对象头（Mark Word 存 hash、GC 分代年龄、锁状态；类型指针指向类元数据）、执行构造方法。TLAB 这个点常被追问：每个线程在 Eden 里预分配一小块私有区域，小对象优先在这里分配，避免指针碰撞的同步开销。

判断对象能不能回收用可达性分析，GC Roots 包括虚拟机栈中引用的对象、方法区静态属性引用的对象、常量引用的对象、本地方法栈中 JNI 引用的对象。引用计数法不用，因为解决不了循环引用。

面试题：对象一定分配在堆上吗？

答不一定，取决于逃逸分析。如果对象只在方法内部使用、没有逃逸出去，JIT 可以做三件事：栈上分配（对象随栈帧弹出自动回收，减轻 GC 压力）、标量替换（把对象拆成若干个基本类型局部变量，干脆不创建对象）、锁消除（对象不会被其他线程访问，synchronized 可以去掉）。参数上记住逃逸分析默认开启，可以用-XX:-DoEscapeAnalysis关掉做对比实验。

3.4 GC 与调优：Full GC 什么时候触发，收集器怎么选

回收算法四种：标记-清除（实现简单，产生碎片）、复制（新生代用，浪费一半空间但快）、标记-整理（老年代用，无碎片但慢）、分代收集（按对象存活周期分区，新生代复制、老年代标记整理）。

Full GC 的触发条件列五条：老年代剩余空间不足；元空间不足；显式调用System.gc()（可以用-XX:+DisableExplicitGC屏蔽）；Minor GC 后晋升的对象大于老年代剩余空间；CMS 出现 concurrent mode failure 退化成串行收集。回答时补一句排查思路：先用jstat -gcutil <pid> 1000观察 FGC 列的增长频率，再用jmap -histo或 dump 文件找大对象，最后用jstack确认是不是有代码在调 System.gc。

收集器怎么选，给一张对应表更清楚。

场景	推荐收集器	理由
单核小内存、客户端	Serial / Serial Old	没有线程交互开销
吞吐优先、后台计算型	Parallel Scavenge / Parallel Old	可控吞吐量，适合批处理
低延迟 Web 服务	G1	可设置最大停顿时间，分 Region 回收
超大堆、极低延迟	ZGC	停顿时间与堆大小基本无关

JVM 调优参数记常用的几个：-Xms和-Xmx设成一样避免动态扩容，-Xmn设新生代大小，-XX:MetaspaceSize设置元空间初始阈值，-XX:+UseG1GC指定收集器，-XX:MaxGCPauseMillis设 G1 的目标停顿时间。调优命令记 jps、jstat、jmap、jstack、jinfo 五个，能说出各自看什么就够。

3.5 真题演练：Minor GC 与 Full GC 分别在什么时候发生

这题看着简单，答浅了就是「新生代满了」和「老年代满了」两句。完整答法分三步。第一步定义：Minor GC 只回收新生代，触发条件是 Eden 区满，因为大部分对象朝生夕死，所以频率高、速度快，会触发 Stop The World，但停顿短。第二步列 Full GC 的多种触发条件（就是上一节那五条），强调它回收整个堆加元空间，停顿长，要尽量避免。第三步给排查手段：jstat 看频率，配置-XX:+HeapDumpOnOutOfMemoryError留现场，-XX:+PrintGCDetails或统一日志看每次回收前后的容量变化，判断是内存泄漏还是单纯的堆太小。最后补一句「如果每次 Full GC 之后老年代占用降不下去，基本就是泄漏，dump 下来用工具找引用链，而不是调大堆参数硬扛」，这句话是区分有没有真排查过故障的关键。

4. 框架与中间件：Spring 循环依赖、SpringBoot 装配、MySQL 与 Redis 的答题主线

框架题最容易变成罗列注解。面试官想听的不是「@Autowired 是自动装配」，而是「为什么字段注入不推荐」「循环依赖三级缓存每一级存什么」「索引失效的几种情况你踩过哪个」。这一章按 Spring、SpringBoot、MySQL、Redis、MQ 五条线走，每一条都准备一个能展开的深水点。

4.1 Spring IOC 与 AOP：循环依赖三级缓存怎么答

IOC 是控制反转，对象的创建和依赖关系交给容器管理；DI 是它的实现方式。依赖注入三种：构造器注入（推荐，依赖不可变、便于测试）、setter 注入、字段注入（写起来方便，但隐藏依赖、不好单测，Spring 官方不推荐）。Bean 的作用域五种：singleton、prototype、request、session、application，默认单例。

单例 Bean 是不是线程安全的？答案是不保证。Spring 只负责创建单例，不给你加锁，有没有状态决定安不安全。如果 Bean 里有可变的成员变量，就是非线程安全的，无状态（只有方法没有实例字段）才安全。这个回答能顺带展示你对「框架不解决业务并发」的理解。

AOP 是面向切面，把日志、事务、权限这类横切逻辑从业务代码里抽出来。实现方式两种：JDK 动态代理基于接口，用 Proxy 和 InvocationHandler；CGLIB 基于继承，生成子类字节码。Spring 默认规则是目标类有接口用 JDK 代理，没有接口用 CGLIB。通知类型五种：前置、后置返回、后置异常、环绕、最终。环绕通知是唯一能拿到 ProceedingJoinPoint 并控制是否放行的一种。

循环依赖是 Spring 篇的最高频追问。回答骨架是三级缓存：一级singletonObjects存完整的 Bean；二级earlySingletonObjects存提前暴露的半成品；三级singletonFactories存能生成半成品的 ObjectFactory。A 依赖 B、B 依赖 A 的过程是：A 实例化后把工厂放进三级缓存，注入 B 时发现 B 没创建，去创建 B，B 注入 A 时从三级缓存拿到 A 的早期引用并升级到二级缓存，B 创建完成后放入一级缓存，A 随后完成初始化。关键边界要说清楚：只能解决单例加 setter 或字段注入的循环依赖；构造器注入的解决不了，因为对象都没实例化出来；prototype 作用域的也解决不了；用了 @Async 的代理对象可能出问题。参数层面可以提一句spring.main.allow-circular-references这个开关，说明新版本默认关闭循环依赖支持，引导候选人思考「为什么官方要禁」。

4.2 SpringBoot 自动装配与 starter：三个必答点

第一点，核心注解。@SpringBootApplication是组合注解，由@SpringBootConfiguration（标识配置类）、@EnableAutoConfiguration（开启自动装配）、@ComponentScan（扫描当前包及子包）三个组成。能拆开说，说明你不是只背了一个名字。

第二点，自动装配原理。@EnableAutoConfiguration通过@Import导入AutoConfigurationImportSelector，它去读 classpath 下META-INF里的自动配置类清单（早期版本用 spring.factories，后来的版本改成独立的 imports 文件），再用@ConditionalOnClass、@ConditionalOnMissingBean这类条件注解过滤，最后把符合条件的配置类注册成 Bean。所以「引入 starter 就能用」的本质是「依赖带进来了，配置类被条件注解激活了」。

第三点，starter 是什么。它不是框架，是依赖聚合加自动配置：一个 xxx-spring-boot-starter 的 pom 里通常引入若干必要依赖，再配一个自动配置类，加上 spring-boot-configuration-processor 支持配置元数据提示。自己写 starter 的步骤是建两个模块（autoconfigure 和 starter）、写配置属性类、写自动配置类、注册清单文件。

配置加载顺序也常问，从高到低大致是：命令行参数、Java 系统属性、操作系统环境变量、jar 包外部的 profile 配置文件、jar 包内部的 profile 配置、jar 包内外的 application 配置、@PropertySource指定的配置。答题时不用死背全序，说清「外部优先于内部、命令行最高、profile 高于默认」就够。

4.3 MySQL：索引、事务隔离级别与 MVCC

索引结构答 B+ 树，三个特点：非叶子节点只存键不存数据，同样大小的页能放更多键，树更矮；叶子节点用双向链表相连，范围查询快；所有数据都在叶子节点，查询路径长度一致。聚簇索引的叶子存整行数据，一张表只有一个；二级索引的叶子存主键值，查非索引列要回表。覆盖索引是指查询的列全在索引里，不用回表，explain的 Extra 列会显示 Using index。

SQL 优化按这个顺序讲：先看慢查询日志定位；再用 explain 看 type（最好到 ref 或 const，出现 ALL 是全表扫）、key（实际用的索引）、rows（预估扫描行数）、Extra（Using filesort 和 Using temporary 都要优化）；然后考虑加联合索引并遵守最左前缀、避免在索引列上做函数运算或隐式类型转换、用 limit 限制范围、大表考虑分区或分库分表。varchar(30)里的 30 是字符数不是字节数，int(11)里的 11 只是显示宽度，跟存储范围和性能无关，这两道是常见送分题。

事务隔离级别用表格记最稳。

隔离级别	脏读	不可重复读	幻读
读未提交	会	会	会
读已提交	不会	会	会
可重复读	不会	不会	InnoDB 下基本不会
串行化	不会	不会	不会

InnoDB 默认是可重复读。MVCC 的实现是 undo log 版本链加 ReadView：每行有隐藏的 trx_id 和 roll_pointer，回滚指针把历史版本串成链；ReadView 里有 m_ids（活跃事务 ID 列表）、min_trx_id、max_trx_id、creator_trx_id 四个字段，根据版本链逐条判断可见性。读已提交每次快照读都生成新 ReadView，所以能看到别人提交的新数据；可重复读只在第一次快照读时生成，之后复用，所以整场事务看到的是同一个快照。幻读靠间隙锁加 Next-Key Lock 解决，但要注意「快照读靠 MVCC、当前读靠锁」这个区分，很多人在这里答混。

4.4 Redis：缓存三问与持久化

缓存穿透是查一个数据库里也不存在的 key，每次都打到数据库。解决方案是缓存空值（设短过期时间）或用布隆过滤器提前拦截。缓存击穿是某个热点 key 过期瞬间大量请求打进来，解决方案是加互斥锁只放一个请求去回源，或者用逻辑过期不设物理过期时间。缓存雪崩是大量 key 同时过期或 Redis 整体不可用，解决方案是过期时间加随机值、多级缓存、集群高可用。

缓存与数据库的一致性，标准答法是 Cache Aside：先更新数据库，再删除缓存。为什么不是先删缓存再更新库？因为并发下会出现「A 删缓存、B 读库旧值写回缓存、A 更新库」的脏数据窗口。为什么是删除不是更新？更新缓存在并发写场景下更容易产生乱序。要求更强一致就上延迟双删（更新库后删一次，隔几百毫秒再删一次）或订阅 binlog 异步删。

Redis 持久化两种：RDB 是快照，fork 子进程写临时文件再替换，恢复快、文件紧凑，但两次快照之间的数据会丢；AOF 是追加写命令，appendfsync有 always、everysec、no 三档，everysec 最多丢一秒，文件大所以要重写压缩。生产上通常两个都开，用 RDB 做冷备、AOF 保证少丢数据。

数据类型与场景要能对上号：String 做缓存和计数器，Hash 存对象字段，List 做简单队列，Set 做去重和交并集，ZSet 做排行榜和延时队列。面试官问「为什么 Redis 单线程还这么快」，答三点：纯内存操作、IO 多路复用、单线程避免了锁竞争和上下文切换，再补一句「新版本网络 IO 改成多线程了，命令执行还是单线程」，这个补充很能体现你跟得上变化。

4.5 真题演练：MQ 如何保证消息不丢、不重复

面试题：如何保证消息的可靠传输？如果消息丢了怎么办？

答题思路是按消息链路分三段，每段给一个机制。生产端：用同步发送加确认机制（RabbitMQ 的 confirm、RocketMQ 的同步发送返回状态），失败重试并落库记录，保证「业务成功且消息发出」这件事有据可查。Broker 端：开启持久化（交换机、队列、消息都持久化），刷盘策略按可靠性要求选同步刷盘，再配主从复制防止单点宕机。消费端：关闭自动 ack，业务处理成功后再手动 ack，失败进重试队列或死信队列。

追问「重复消费怎么办」，答案是消费端做幂等：用业务唯一键加去重表、状态机判断（已支付的不再重复处理）、或者 Redis 存消息 ID 做短期去重。再补一句「消息队列只能保证 at least once，exactly once 要靠业务侧兜底」，这句话基本能结束这个回合。

顺带准备消息顺序性：全局有序只能单队列单消费者，代价是吞吐低；业务上更常见的是局部有序，按业务主键 hash 到同一分区，消费者单线程处理该分区。

5. 常见失分点：五类一听就露怯的答法，错在哪、怎么改

有些回答不是错，是浅。面试官听完不会反驳，但会在心里把你从「熟悉」降到「了解」。下面五条是高频踩坑点，每条按「错在哪、为什么错、怎么答对」拆开，对照自己的答题录音过一遍，能捞回不少分。

5.1 概念题失分：三条最容易停在第一层的回答

第一类，HashMap 长度为什么是 2 的 N 次方，只答「为了让散列更均匀」。错在只说了结果没说机制，面试官会认为你是背的。为什么错：这个设计的核心价值有两块，一是(n-1) & hash用位运算替代取模提升性能，二是扩容时元素只需判断 hash 的一个新增位就能决定留原位还是移到原位加 oldCap，完全不用重算。怎么答对：先说位运算替代取模，再说 n-1 低位全 1 保证分布均匀，最后说扩容 rehash 的便利性，三句话层层递进。

第二类，把 volatile 说成「保证可见性和原子性」。错在后半句，这是硬伤，面试官会立刻追问i++为什么不行。为什么错：volatile 只保证单次读或单次写的原子性，复合操作（读-改-写）中间可能被其他线程插入。怎么答对：明确说「可见性加有序性，不保证原子性」，主动举i++的反例，再补「要原子性用 AtomicInteger 的 CAS 或加锁」。

第三类，说「可重复读完全解决了幻读」。错在把隔离级别和锁机制混为一谈。为什么错：RR 下快照读靠 MVCC 看到一致快照，当前读靠 Next-Key Lock 锁住范围，但如果事务里先快照读、另一个事务插入并提交，当前事务再当前读，是可能看到新行的，标准文档里也承认这个边界。怎么答对：区分快照读和当前读，说明 InnoDB 在 RR 下用间隙锁「基本解决」幻读，但不同语句组合下仍有边界情况，回答时给出「大部分业务场景够用」的判断。