企业官网建设流程全解析

每年到这个时间点，总能在技术社群里看到同一种景象：不管校招还是社招，大家手里都攒着几份PDF，文件名里写着“终极版”“精华版”“面试必背”，点开一看几百道题，答案背得滚瓜烂熟。但真到了面试现场，一问“为什么这么设计”，很多人就卡住了。

我这些年既面过别人，也被别人面过，慢慢发现一个很反直觉的事实：八股文本身没有错，错的是把它当成“背诵材料”而不是“理解提纲”来用。面试官真正想听的，不是你背出来的标准答案，而是你推导出这个答案的逻辑链。

所以这篇总结我打算换一种写法。同样是Java面试的核心知识点，我不只给你答案，还会把每个考点背后的“为什么需要它”“它到底解决了什么问题”“如果你来设计会怎么考虑”一起串起来。这也是一份面向2026届春招、秋招以及社招冲刺的复习地图，建议先收藏，再按章节逐步消化。

1. 面试前先想明白：这份总结该怎么用，才不会变成死记硬背

先说个我自己的观察。去年帮一个学弟做模拟面试，他简历上写着“熟悉JVM调优”，我问“你们项目里遇到过Full GC吗？怎么排查的？”他第一反应是背出JVM参数列表：-Xms、-Xmx、-XX:+UseG1GC，背得很完整。但当我接着问“为什么这两个参数要设成一样大”时，他愣了几秒，说“网上建议这么配”。这就是典型的“背答案但没理解答案”。

其实“为什么-Xms和-Xmx要一样大”这个问题的核心，是避免运行期堆扩容带来的性能抖动和对象地址变动。JVM在启动时如果初始堆很小，随着对象增多会触发扩容，扩容过程涉及堆内存重新划分和对象移动，会造成明显的停顿。生产环境直接初始化到最大堆，就是拿空间换稳定。

类似的例子在Java面试里到处都是。所以这篇总结里，我会有意把每个考点拆成三层：

• 是什么：一句话能讲清楚的定义，用来快速过知识点。
• 怎么用：代码层面、配置层面、场景层面的具体体现。
• 为什么：设计者当初面临什么问题，为什么选这个方案，有没有替代方案。

你复习的时候，不要光盯着“是什么”层，那层只是用来建立骨架。真正让你和竞争者拉开差距的，是“为什么”层。面试官问问题的深度通常也是沿着这个方向走的：先问定义，再问用法，最后追到底层原理和设计取舍。

另外提醒一句：不要试图“刷完”这份内容。它覆盖的是Java面试中最高频、最容易被追问的板块。更合理的用法是，先快速通读一遍把所有考点看个眼熟，然后针对自己不熟悉的板块单独建文档，用自己的话把答案写出来。写不出来的部分，才是你真正需要补的地方。

2. JVM核心考点：内存区域、垃圾收集与类加载，关键是能画出自己的逻辑链

JVM这块在Java面试中出现频率极高，而且几乎每一家都会让你说说内存区域。但很多人只背了“堆、栈、方法区”六个字，一追问就散架。这块我建议你把知识串成一条逻辑链：程序跑起来，数据放哪里，满了怎么办，谁负责清理，怎么清理。

2.1 内存区域：为什么要分堆和栈，答到这个层面才算过关

虚拟机栈、本地方法栈、程序计数器、堆、方法区，这五个区域怎么区分，大部分人都能背出来。但真正能体现功力的，是能不能说清楚为什么会这样划分。

核心原因有三个维度：

• 第一，线程隔离。栈和程序计数器是线程私有的，每个线程执行到哪一行、调用栈有多深，必须自己维护。堆和方法区是线程共享的，所以才有并发访问和加锁的问题。
• 第二，生命周期差异。栈里的栈帧随方法调用创建、随方法返回销毁，生命周期短且确定；堆里的对象什么时候没人用了，需要GC来判断，生命周期长且不确定。把这两类数据混在一起管理会非常低效。
• 第三，管理方式不同。栈是连续内存空间，只需移动栈顶指针就能分配和释放，速度极快；堆需要动态分配、垃圾回收、内存碎片整理，复杂得多。

理解了这三点，面试官如果再追问“JDK8里方法区去哪了”，你就能顺势讲出元空间（Metaspace）取代永久代的背景：永久代放在堆内，大小难以估算，很容易出现OutOfMemoryError: PermGen space；同时永久代参与Full GC，拖慢回收效率。而元空间直接使用本地内存，默认只受物理内存限制，字符串常量池也移到了堆里。这一改，本质是把“难以估量的元数据”从“需要精细管理的堆”里挪出去。

2.2 垃圾收集算法和收集器：从标记-清除到G1/ZGC，怎么讲才有层次

垃圾收集这块，很多人的回答停留在“标记-清除、标记-复制、标记-整理”三个算法名字上，再问收集器就只能背出CMS、G1。要拿到高分，需要把“算法”和“收集器”的关系说清楚。

收集器是具体实现，算法是收集器内部某个阶段采用的策略。比如CMS，它的初始标记和重新标记用到了STW（Stop The World），并发标记阶段用的就是“可达性分析+三色标记”，最终清理阶段则涉及标记-清除算法的变体。而G1整体上采用的是“分区+复制”的思路，把堆划分成多个大小相等的Region，每个Region都可以独立回收，这样就能做到“可预测的停顿时间”。

面试官很喜欢接着问“G1和CMS相比到底强在哪”。你可以从三个角度答：

• 回收策略：CMS是老年代收集器，需要配合ParNew使用；G1是面向整个堆的收集器，不需要分代配合。
• 碎片问题：CMS用标记-清除，会产生内存碎片，最终触发Full GC时停顿很长；G1用复制算法，回收后Region内是紧凑的，基本没有碎片。
• 可预测性：G1通过维护一个优先级列表，每次根据用户设定的预期停顿时间（-XX:MaxGCPauseMillis）选择回收收益最大的Region集合，这个设计思路叫“垃圾优先”。CMS不提供这种停顿时间预测。

如果你面的是高阶岗位，还可以补充一句ZGC或Shenandoah的染色指针与读屏障技术，它能做到十毫秒以内的暂停。但注意，不要为了炫技硬提一个自己讲不透的概念，面试官一旦追问“你项目中用过吗”，答不上来反而扣分。稳妥的做法是：G1讲透，ZGC点到为止。

2.3 类加载机制与双亲委派：不光背流程，还要能解释“为什么非要这么干”

类加载这个考点，标准答案是“加载、验证、准备、解析、初始化”五个阶段。但我觉得更值得重视的是双亲委派模型，因为它背后是一个典型的安全和隔离设计。

双亲委派的核心逻辑是：一个类加载器收到加载请求时，不会自己先尝试加载，而是把请求委派给父加载器。只有当父加载器反馈无法完成加载时，子加载器才尝试自己加载。这么设计至少有两个关键原因：

• 防止核心API被篡改。比如你自己写了一个java.lang.String，如果不经过委派，启动类加载器在加载String时就会加载到你写的这个类，整个JVM就乱套了。有了双亲委派，系统类库永远由启动类加载器加载，自定义类不会污染核心类库。
• 避免类的重复加载。同一个类，如果两个不同的加载器都加载了一遍，在JVM里会被当成两个不同的类，用instanceof判断时会出问题。委托给父加载器统一加载，可以保证同一个类在全系统中只会被加载一次。

面试官如果继续深化，可能会问“Tomcat为什么要打破双亲委派”。Tomcat需要同时部署多个Web应用，每个应用可能依赖不同版本的Spring、不同版本的类库，如果还要严格遵循双亲委派，所有Web应用共享同一个类加载器，那版本冲突就无解了。所以Tomcat为每个Web应用创建一个独立的WebAppClassLoader，并且优先加载自己WEB-INF/classes和WEB-INF/lib下的类，加载不到再交给父加载器。这个例子是“理解双亲委派”最好的延伸题。

3. 并发编程连环问：volatile、synchronized、AQS、线程池要从机制到场景串起来

并发是Java面试题里的“深水区”。很多候选人能说出几个关键字，但问到底层就含糊。我个人复习这个板块的心得是：不要单独背某个知识点，而是用“线程间如何协作、数据如何保证可见、锁如何竞争”这条主线把所有点串起来。

3.1 JMM和volatile：为什么靠内存屏障而不是靠锁

Java内存模型（JMM）规定了主内存和工作内存的交互规则。简单说，每条线程有自己的工作内存（缓存了主内存变量的副本），线程对变量的操作只能在工作内存中进行，不能直接读写主内存。这就带来了三个并发问题：可见性、原子性、有序性。

volatile能解决可见性和有序性，但解决不了原子性。这个结论每个看过八股的人都能说出来，但你能解释“volatile为什么能保证可见性”吗？

关键在于内存屏障。在volatile变量的写操作前后，JVM会插入屏障指令，强制把当前线程工作内存中修改的值刷新到主内存；在读操作前后，强制从主内存重新读取。同时，屏障还会禁止指令重排序，这就是有序性的来源。

举个例子，单例模式中常见的双重检查锁：

public class Singleton { private static volatile Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } }

如果你去掉volatile，即使synchronized保证了原子性和可见性，但instance = new Singleton()这一步在指令层面会被拆成三件事：分配内存、初始化对象、把引用指向内存。由于指令重排序，第三步可能先于第二步执行。此时另一个线程第一次判空发现instance不为null，直接返回了一个尚未完成初始化的对象。这就是volatile在这里存在的全部意义。

3.2 synchronized的锁升级过程：这个细节最常被追问

以前很多Java面试题还停留在“synchronized是重量级锁”，但自从JDK 6做了锁优化之后，这个说法就过时了。现在的标准答案是：无锁 → 偏向锁 → 轻量级锁 → 重量级锁，叫锁升级。

整个过程是这样演进的：

• 初始时没有任何线程竞争，对象头里的Mark Word记录的是无锁状态。
• 当第一个线程访问同步块时，JVM把对象头的锁标志位改为偏向锁，记录这个线程的ID。偏向锁的意思是“这个锁偏向于第一个获得它的线程”，如果后面还是同一个线程来访问，就不需要再做任何同步操作，性能极高。
• 一旦有第二个线程来竞争，偏向锁就会被撤销，升级为轻量级锁。轻量级锁通过自旋（CAS）尝试获取锁，不阻塞线程，适合锁持有时间很短的场景。
• 如果自旋失败或竞争进一步加剧，轻量级锁会升级为重量级锁。此时未获取锁的线程会进入阻塞状态，由操作系统调度，涉及用户态和内核态的切换，代价最大。

面试时如果能主动说出“偏向锁在JDK 15之后被默认禁用、JDK 18中已被标记为废弃”这个演进趋势，会显得你对Java版本变化很敏感。因为偏向锁在如今的高并发场景下收益越来越低，撤销偏向锁带来的STW代价反而不可忽略，所以HotSpot团队逐步把它“边缘化”了。

3.3 AQS的底层逻辑：ReentrantLock和Semaphore的公共答案

AQS（AbstractQueuedSynchronizer）是Java并发包里最核心的类。ReentrantLock、Semaphore、CountDownLatch、ReentrantReadWriteLock都是基于它实现的。面试官问AQS，本质上是在问“并发工具类的公共底座是怎么设计的”。

你可以这么回答：AQS维护了一个volatile int类型的state变量和一个FIFO双向等待队列。state的含义由子类自己定义，比如ReentrantLock里state表示锁的重入次数，Semaphore里state表示剩余许可证数量。线程获取锁时，通过CAS来修改state；如果修改失败，说明资源被占用，当前线程就会被包装成一个Node节点加入等待队列尾部，并通过LockSupport.park阻塞自己；释放资源时，把state改回去，然后唤醒队列头部的等待线程。

这里有个高频追问：“ReentrantLock和synchronized的区别有哪些？”可以用表格来总结：

需要注意的是，虽然ReentrantLock功能更丰富，但synchronized在JDK 6之后经过锁升级优化，简单场景下性能并不差，而且写法更简洁、不易出错。我在实际项目里会优先用synchronized，只有需要可中断、可超时、多个条件队列时才换ReentrantLock。

3.4 线程池：七个参数怎么记，拒绝策略怎么选

线程池为什么必须掌握？因为稍大一点的项目都会用到，而且面试官很容易从“你们项目里线程池怎么用的”一路问到底层。

七个参数分别是：核心线程数（corePoolSize）、最大线程数（maximumPoolSize）、空闲存活时间（keepAliveTime）、时间单位（unit）、任务队列（workQueue）、线程工厂（threadFactory）、拒绝策略（handler）。

记忆口诀其实很简单：“两个人、一个队、一个工厂、一个策略”。但比记参数更重要的是理解线程池的完整工作流程。用大白话讲：

• 线程池创建后，来一个任务，先看当前线程数是否小于核心线程数，小于就创建新线程执行。
• 当线程数达到核心线程数后，新任务进入任务队列排队。
• 当队列也满了，再看线程数是否小于最大线程数，小于则继续创建新线程，这部分线程就是非核心线程。
• 如果线程数已经达到最大线程数，队列也满了，就只能走拒绝策略。

拒绝策略有四种，默认是AbortPolicy（直接抛异常）。我在线上项目中最常用的是CallerRunsPolicy，让提交任务的线程自己执行这个任务，既不会丢任务，又起到天然“限流”的作用，让提交方感受压力从而放慢提交速度。DiscardPolicy一定要谨慎，因为它是静默丢弃，线上出问题很难排查。

另外，阿里Java开发规范里推荐用ThreadPoolExecutor的方式显式创建线程池，不要用Executors提供的快捷方法。原因很直接：Executors.newFixedThreadPool和newSingleThreadExecutor的队列是默认无界的LinkedBlockingQueue，任务堆积会导致内存暴涨；newCachedThreadPool的maximumPoolSize是Integer.MAX_VALUE，高并发下会创建大量线程，直接拖垮系统。这些坑在面试中也很容易被拿出来当反面案例。

4. 集合框架连问：ArrayList与HashMap是面试入口，却不是终点

集合这块看起来简单，但它是面试官最爱的“连环问”起点。ArrayList的问法能从构造器问到扩容，再到fail-fast机制；HashMap能从结构问到put流程，再到红黑树为什么阈值是8。我建议你带着“设计者视角”去复习，而不是只背源码行号。

4.1 ArrayList扩容为什么是1.5倍，而不是两倍

ArrayList底层是Object数组，默认容量10。每次扩容时通过int newCapacity = oldCapacity + (oldCapacity >> 1)计算新容量，也就是原来的1.5倍，然后调用Arrays.copyOf把旧数组内容拷到新数组。

这个1.5倍并不是拍脑袋定的。如果扩容倍数太小，比如1.1倍，那每次添加元素都可能触发扩容，频繁拷贝数组，性能很差。如果扩容倍数太大，比如2倍或3倍，虽然扩容次数少了，但一次性占用的内存空间更多，可能造成内存浪费。1.5倍是一个折中值：既保证扩容次数不会太频繁，又不会让数组容量增长过快。

顺着这个话题，面试官经常会追一个常见问题：“ArrayList和LinkedList有什么区别？”常规回答是“ArrayList基于动态数组，查询快、插入慢；LinkedList基于双向链表，插入快、查询慢”。但如果你能补充“在实际项目中，LinkedList的随机访问是O(n)，所以遍历不要用get(i)，要拿迭代器；而ArrayList的尾部插入因为扩容机制，均摊时间复杂度还是O(1)；另外LinkedList每个节点有额外的前后指针，内存占用比ArrayList大很多”，就会显得你既有理论知识又有实践感知。

4.2 HashMap的put流程和红黑树阈值，怎么讲才能让面试官点头

HashMap是Java面试中“最卷”的题目，需要讲清楚的点有：底层结构、hash扰动、扩容机制、红黑树转换条件。我建议按下面的顺序回答：

• 底层结构是数组+链表+红黑树。数组的每个位置叫桶（bucket），当多个key的hash值映射到同一个桶时，以链表形式存储；链表过长时转为红黑树。
• 计算索引时，先用key的hashCode做一次扰动计算：h ^ (h >>> 16)。这一步是把高位16位的信息混入低位，因为HashMap计算桶下标用的是(n - 1) & hash，如果n比较小，直接使用原始hash会让高半区的信息全部丢失，增加碰撞概率。扰动函数的目的就是让高半区也参与散列。
• put流程是：先判断数组是否为空，为空则扩容；再根据hash计算桶下标，如果桶为空直接放入；不为空则判断链表头节点是否匹配，匹配则覆盖；不匹配则遍历链表，链表长度超过8且数组长度超过64时转为红黑树。
• 扩容时，数组容量变为原来的两倍。JDK 8对扩容做了优化：因为新容量是旧容量的2倍，所以元素在新数组中的下标要么是原下标，要么是“原下标+旧容量”。这个结论取决于(n - 1) & hash中新增的那个高位bit。JDK 8通过判断hash的该bit来决定元素是否需要移动，避免了JDK 7中重新计算hash再插入的低效做法。

红黑树阈值为什么是8？这个问题的答案要从泊松分布说起。Java源码注释里说，在随机hashCode下，桶中元素个数达到8的概率非常低（大约千万分之一），所以设置成8既不会让树化频繁发生，又能防止极端碰撞场景下的性能退化。同时，树化还需要数组长度达到64，否则即使链表很长也先扩容，因为扩容后链表会被拆散，可能不需要树化。

4.3 ConcurrentHashMap的分段锁到CAS+synchronized：演进逻辑比代码更重要

面试官问你ConcurrentHashMap，本质上是在考察“对并发性能与一致性之间权衡的理解”。

JDK 7的ConcurrentHashMap使用Segment分段锁：整个Map被分成多个Segment，每个Segment内部是一张哈希表，不同Segment可并发操作，但同一Segment内仍然串行。锁粒度是Segment，理论上并发度等于Segment数。

JDK 8做了重大升级：放弃Segment，直接用Node数组，加锁粒度细化到单个桶，锁对象是桶的头节点。在桶为空的时候，用CAS无锁插入；在桶不为空时，再用synchronized锁住头节点进行插入或更新。这里用synchronized而不是ReentrantLock，是因为JDK 6之后synchronized经过锁升级优化，在低竞争场景下开销极小，同时语法更简洁，维护成本更低。

与此同时，JDK 8的ConcurrentHashMap和HashMap一样，在链表过长时也会转红黑树，用TreeBin包装红黑树根节点，同样支持并发读写。还有一个细节值得提：扩容时支持多线程协助迁移，即多个线程可以一起帮忙把旧数组的元素搬到新数组，迁移完成后才允许其他线程操作。这个“协助扩容”机制也是面试中考察比较深的问题。

5. Spring核心机制：Bean生命周期、循环依赖、AOP是三个绕不开的坎

Spring是Java后端岗位的标配，几乎每一轮技术面都会问。但很多人只是背了大概流程，一旦面试官追问细节就露馅。我发现最有效的复习方式，是把Bean的“一生”从头到尾走一遍，然后把循环依赖和AOP挂到这条生命周期线上，形成有因果关系的整体。

5.1 Bean生命周期：从定义到销毁，中间经历的每个阶段都要知道

Spring容器启动后，Bean的创建过程大致是：

1. 扫描或读取配置，得到BeanDefinition。
2. 实例化Bean：通过构造器反射创建对象实例。
3. 属性填充：对标注了@Autowired、@Resource等注解的属性进行依赖注入。
4. 执行Aware接口回调：例如BeanNameAware（设置Bean名字）、BeanFactoryAware（注入BeanFactory）、ApplicationContextAware（注入ApplicationContext）。
5. 执行BeanPostProcessor的前置方法postProcessBeforeInitialization。
6. 执行初始化逻辑：如果Bean实现了InitializingBean接口，调用afterPropertiesSet；如果配置了init-method，调用指定方法。
7. 执行BeanPostProcessor的后置方法postProcessAfterInitialization。这一步也是Spring AOP创建代理对象的关键时机。
8. 此时Bean就绪，可以被正常使用。
9. 容器关闭时，销毁Bean：如果实现了DisposableBean，调用destroy；如果配置了destroy-method，调用指定方法。

很多人会问，这个流程面试时必须一字不差吗？我的建议是记住主要脉络，然后用例子说话。比如你可以主动说：“我们项目里有个缓存预热的组件，就是在afterPropertiesSet里加载配置到内存的。如果用BeanPostProcessor，可以在每个Bean初始化后都做增强，适合做统一日志收集。” 这样显得你不仅背了流程，还在实际工作中用过。

5.2 循环依赖：三级缓存到底在解决什么问题

Spring解决循环依赖靠的是三级缓存，这可能是Java面试中“背诵率”最高的问题之一。三个缓存分别是：

• 一级缓存singletonObjects：存放已经完成整个创建流程的单例Bean。
• 二级缓存earlySingletonObjects：存放提前暴露的早期Bean引用，也就是实例化完成但还没完成属性填充和初始化的对象。
• 三级缓存singletonFactories：存放ObjectFactory，负责生成早期Bean的代理对象。

为什么需要三级，而不是两级？关键点在于：如果某个Bean被AOP代理，那么在循环依赖时，提前暴露给其他Bean的必须是代理对象，而不是原始对象。三级缓存里存的是ObjectFactory，它内部会判断这个Bean是否需要AOP，需要就返回代理对象，不需要就返回原始对象。如果只有两级缓存，在属性填充阶段就要把原始对象放进去，但那时还没执行BeanPostProcessor，代理对象还没生成，后面再补代理就会出现“注入的是原始对象”的问题。

这里有个容易被追问的边界：构造器注入的循环依赖无法被三级缓存解决。因为构造器注入发生在实例化阶段，Bean还没创建出来，无法提前暴露引用。这类循环依赖只能用@Lazy延迟加载来打破。还有一个边界是prototype作用域的Bean不缓存，也解决不了循环依赖。

5.3 AOP是动态代理的包装，理解底层才能应对追问

Spring AOP的核心是动态代理。默认情况下，如果目标类实现了接口，Spring使用JDK动态代理；如果没有实现接口，则使用CGLIB代理。JDK动态代理基于接口，通过Proxy.newProxyInstance生成实现类对象；CGLIB通过继承目标类来生成子类，重写目标方法。

面试中常见的问题是“JDK动态代理和CGLIB的区别”。可以从三个维度回答：

• 实现方式：JDK基于接口，CGLIB基于继承。
• 限制：JDK代理要求目标类必须有接口；CGLIB可以代理没有接口的类，但无法代理final类和方法。
• 性能：JDK 8之后JDK代理的创建和调用性能已经很好，Spring Boot默认在目标类没有接口时使用CGLIB，无需额外配置。Spring Boot 2.x之后官方也推荐使用CGLIB。

AOP的原理可以与Bean生命周期关联起来：在Bean初始化完成后，BeanPostProcessor会检查这个Bean是否匹配切点表达式，如果匹配，就生成代理对象并替换原来的Bean。这也是Spring AOP和AspectJ的最大区别：Spring AOP在运行时生成代理，AspectJ在编译期或类加载期织入。

如果面试官再问“为什么Spring事务有时候会失效”，答案也藏在AOP里：自调用时，this.method()调用不会经过代理对象，所以事务注解不会生效。解决办法是通过AopContext.currentProxy()获取代理对象，或者把调用拆到另一个Bean中。这是非常贴近实际工作的一类问题，值得多花几分钟理解。

6. MySQL与Redis高频点：索引结构、事务隔离与缓存一致性是“Java岗必附带题”

你会发现，Java岗面试几乎不会只问Java本身。尤其是后端岗位，MySQL和Redis基本属于“公共科目”。这块内容如果能在Java面试里答出深度，会明显拉高面试官对你的评价。

6.1 索引为什么选B+树而不是B树或者红黑树

MySQL的InnoDB存储引擎使用B+树作为索引结构。面试官问“为什么是B+树”，最佳回答方式是做一组对比：

• 对比红黑树/AVL树：它们是二叉树，随着数据量增大，树的高度会迅速增加。假设几百万行数据，树高可能是20层以上，每层对应一次磁盘I/O，性能会出问题。B+树的每个节点可以存储很多key，能够把树高控制在3~4层。
• 对比B树：B树每个节点既存索引也存数据，同一高度下能存储的索引数量更少，而且中序遍历需要递归访问多个节点，不适合范围查询。B+树的所有数据都存在叶子节点，并且叶子节点之间用指针串成有序链表，做范围查询时只需找到起点，然后沿着链表顺序读取，效率极高。
• 对比哈希索引：哈希索引等值查询O(1)很快，但不支持范围查询和排序，所以InnoDB默认还是用B+树。

如果面试官继续深挖“聚簇索引和二级索引的区别”，你可以说：InnoDB的聚簇索引（主键索引）叶子节点直接存放整行数据，所以通过主键查询只需要一次索引查找；二级索引叶子节点存放的是主键值，通过二级索引查询到主键后，还需要回表到聚簇索引再查一次，这个过程叫回表。覆盖索引就是二级索引包含了查询需要的所有字段，可以避免回表，是性能优化的重要手段。

6.2 事务隔离级别与MVCC：锁与版本链的配合

MySQL的事务隔离级别有四种：读未提交、读已提交、可重复读、串行化。默认隔离级别是可重复读（Repeatable Read）。

**MVCC（多版本并发控制）**是实现读已提交和可重复读的核心机制。在InnoDB中，每行记录都有隐藏列：事务ID（DB_TRX_ID）和回滚指针（DB_ROLL_PTR）。每次更新操作不会直接覆盖旧数据，而是生成一个新版本，并通过回滚指针串成版本链。

读操作怎么决定读哪个版本？依靠ReadView。ReadView记录了生成时刻活跃事务的ID列表。读已提交和可重复读的区别就在于生成ReadView的时机不同：读已提交每次执行SELECT都生成新的ReadView，所以能读到其他事务已提交的新数据；可重复读在第一次SELECT时生成ReadView，之后一直复用，所以事务内多次读取结果一致。

这个设计可以说非常巧妙：普通的快照读不用加锁，通过版本链和ReadView实现一致性快照，大幅提高了并发读的性能。当前读（比如SELECT ... FOR UPDATE、UPDATE、DELETE）则走的是加锁逻辑，会用到记录锁、间隙锁、Next-Key Lock。

关于间隙锁，有一个容易踩坑的点：在可重复读隔离级别下，InnoDB使用Next-Key Lock（记录锁+间隙锁）来防止幻读，这意味着对一个范围内的记录加锁时，会同时锁住这个范围内不存在的“间隙”，影响插入操作。生产环境高并发插入场景下，如果出现了大量锁等待，很多时候就跟间隙锁有关。

6.3 缓存的三个经典问题：穿透、击穿、雪崩

面试问Redis，穿透、击穿、雪崩几乎是三个标配问题。它们的本质区别可以用一句话记：

• 缓存穿透：查一个不存在的数据，缓存和数据库都没有，请求直接打到数据库。
• 缓存击穿：一个非常热点的key在缓存过期的瞬间，大量请求同时打到数据库。
• 缓存雪崩：大量key在同一时间段过期，或者Redis实例宕机，导致大量请求打到数据库。

针对穿透，常见方案有三种：缓存空值（设置较短的过期时间）、布隆过滤器拦截、参数校验。布隆过滤器尤其值得讲一下：它用多个哈希函数把key映射到bitmap上，判断某个key一定不存在时就直接返回，不用访问数据库。它的缺点是“可能存在误判”，但不存在“漏判”，对穿透场景很适合。

针对击穿，方案是：热点key不设置过期时间，或者后台异步更新缓存；也可以用互斥锁，只让一个线程去查数据库并回填缓存，其他线程等锁后直接读缓存。分布式场景下可以基于Redis的SETNX实现互斥锁。

针对雪崩，方案是：过期时间加随机值，避免大量key同时过期；使用多级缓存（本地缓存+Redis）；对请求做限流降级；主从架构加哨兵保障Redis高可用。

7. 临场答题的策略：同样是背过，为什么有人能拿Offer有人挂

最后这部分不聊具体知识点了，聊一个更实际的问题：知识点都过了一遍，面试时怎么把“我会”变成“面试官觉得我会”。

我参与过不少面试，发现候选人答案质量的分水岭，往往不在于知识面广度，而在于三点：

第一，先给结论，再给理由。面试官问“HashMap线程安全吗”，不要一上来就开始背源码。先说“不安全，多线程put可能导致死循环或数据覆盖”，再补一句“JDK 7中头插法在多线程扩容时会形成环，JDK 8改成尾插法解决了环的问题，但数据覆盖问题依然存在”。这种“总-分”结构，让面试官能在十秒内判断你懂不懂，后续追问才有意义。

第二，用项目说话。很多面试题看似是纯概念题，其实都可以和项目结合。比如问线程池参数怎么设置，你答完公式还不够，最好补一个真实例子：“我们线上是I/O密集型任务，核心线程数设为CPU核数的两倍左右，队列用有界ArrayBlockingQueue，拒绝策略用CallerRunsPolicy，防止任务无界堆积。” 面试官听到这个，会认为你是在用知识解决问题，而不是在复述课本。

第三，不会的题目不要硬编。有两类处理方式区别很大。一类是直接说“这个我没深入了解过”，然后就没下文了，这当然不好。另一类是换个角度说：“这个概念我没有生产实践，但凭我对JVM的理解，它的原理可能是这样……如果有偏差希望您指正。” 第二种回答即使不准确，也体现了你的推导能力和诚实。大多数面试官对这类回答是给正分的。

这里我还想单独提一下复习方法。不要用“刷题数量”来评判准备程度，而是用“能不能不看资料讲出逻辑链”来检验。你可以每天抽一到两个板块，拿一张白纸，画一下它的核心流程。比如今天就画“Spring Bean生命周期”，明天画“HashMap put流程”，后天画“线程池执行流程”。凡是画不出来的环节，就是对这块知识还有盲区。这种方法比反复看笔记有效得多，我试过，也用这个方法帮过不少人，反馈都很好。

另外，准备面试时不要只盯着知识点本身，也要顺手查一下相关版本的更新。比如你简历上写了“熟悉Java”，最好知道JDK当前最新LTS版本里有哪些改动能聊。这篇总结里的锁升级、ConcurrentHashMap实现等，都是跟版本演进强相关的，如果你在面试时能主动提到设计变化的原因，很容易给面试官留下“这人不是死背书”的印象。

复习这件事，其实没有捷径，但一定有路径。把每个考点从“看到答案认识”变成“合上资料能讲”是一层，再从“讲清楚是什么”变成“说清楚为什么这样设计”是更深的一层。这篇总结能做的，就是帮你把主干和逻辑铺好，剩下的，要靠你自己把这些内容变成自己的话，在面试现场从容地讲出来。