企业官网建设流程全解析

Java 面试的准备，说到底是拼两样东西：记忆的精确度和理解的深度。网上流传的“Java 八股文”满天飞，但很多同学拿着背诵版的答案去面试，一被追问底层原理就直接露馅。这篇文章不打算给你贴一份几千行的背诵提纲，而是把近期高频出现的考点整理成一份“带逻辑链”的清单，重点拆解每个知识点背后的考察意图、答题要点以及容易踩的坑。内容会覆盖 Java 基础、集合框架、并发编程、JVM、常见框架等核心模块，适合正在准备 Java 后端岗位面试的同学，尤其是工作 1 到 3 年、想冲击中级开发职位的人。看过之后你不需要死记硬背，只要能顺着每道题背后的逻辑把上下文串起来，面试现场自然就能答得稳。

1. 这份清单的定位与使用方式

在展开知识点之前，先聊点实际的：Java 技术栈本身已经很成熟，面试官出题基本不会跳出那几个经典模块。高频题之所以高频，是因为它们对应的恰好是日常开发中最容易出问题、也最能体现候选人基本功底的地方。比如集合里 HashMap 的底层原理、并发里线程池的参数设计、JVM 里内存区域的划分与 OOM 排查，这些知识点不是说背下来就能应付，而是面试官通过追问层层深入，想确认你是真的理解，还是仅仅记住了结论。

我整理这份清单的方式是按“面试问答链”来组织的。每道题下面会先给出最简版答案，再拆解面试官可能在追问中埋下的陷阱，最后补充一些实操层面的经验。这样做的原因是，面试本身就是一个非常典型的“追问链”：第一问是门槛，第二问开始筛选，第三问才是真正拉开差距的地方。你如果只准备到第一层，大概率会被压在“基础还行”的区间；如果你能顺着追问链提前准备好第二层、第三层的内容，那么同样一道题，你拿到的评价会完全不同。

使用这份清单时，我建议你不要按顺序从头记到尾，而是先快速浏览一遍，把所有题目都过目一次，标出你第一反应答不上来或者答不完整的题目，然后针对这些薄弱点单独展开复习。基础好的同学，重点看“追问链”和“避坑经验”；基础弱一点的同学，先把“最简答案”和“原理补充”吃透，再逐步往上够。下面我们就按模块逐个过。

2. Java 基础核心：从语法现象到底层原理

2.1 面向对象的三大特性，怎么答才不会像背课文

面向对象几乎是 Java 面试的第一道开胃菜，但恰恰是这道题最容易暴露问题。很多人的答案是脱口而出的“封装、继承、多态”，然后就没有然后了。面试官听到这种答案其实很无奈，因为这三个词已经重复了无数次，他希望听到的是你对这三个特性的理解，而不仅仅是名词。

先说封装。封装的核心不是“把属性设为 private”这种操作层面的事情，而是信息的隐藏与访问控制。你要点出，封装让你可以把对象内部状态的变化控制在自己手里，外部的调用者只需要通过公开的方法来操作对象，不需要也不应该关心内部实现。举个例子，一个订单类里有一个金额字段，如果允许外部随意修改，金额变成负数就出问题了；而通过 setter 方法，你可以在方法内部加上校验逻辑，这就是封装的意义。

继承的关键在于“复用”和“扩展”之间的平衡。Java 只支持单继承，这是语言层面的设计决策，是为了避免多重继承带来的复杂性问题。回答继承时，最好补充一句——继承容易造成耦合，所以现代开发更提倡组合优先于继承。这句话虽然简单，但它告诉面试官你在实际写代码时考虑过可维护性，而不只是教科书里的定义。

多态是这三个特性里最深的一个。你需要点出多态存在的三个必要条件：继承、方法重写、父类引用指向子类对象。但这还不够，面试官如果想深挖，他会继续追问“多态在 JVM 层面是如何实现的”，这时候你要能答出“方法表”或“虚方法表”的概念——每个类在方法区里都有一张虚方法表，里面存放着各个方法的实际入口地址。当调用一个重写方法时，JVM 会从对象的实际类型出发去查这张表，找到对应的实现来调用。能答到这里，多态这一题就稳了。

2.2 == 和 equals：一道送分题里的追问陷阱

这道题属于“人人都觉得自己会，但面试官总能找到人挂掉”的典型。最基础的说法是：== 比较的是引用地址或基本数据类型的值，equals 是 Object 类里的方法，默认行为等同于 ==，但 String、Integer 等类重写了它，改成了比较内容。这样答没有错，但太浅了，我可以负责任地说，面试官接下来一定会追问具体的场景题。

常见的追问一：String a = new String("abc") 和 String b = "abc"，a == b 返回什么？答案自然是 false，因为一个在堆上通过 new 创建，一个在字符串常量池中，两者的地址不同。但如果改成 String c = "abc" 和 String d = "abc"，c == d 就返回 true，因为都指向常量池里的同一块区域。这个知识点背后是 JVM 字符串常量池的工作机制，你在回答时可以展开解释 JVM 如何用常量池来缓存字符串对象，从而节省内存。

常见的追问二：Integer x = 127，Integer y = 127，x == y 返回什么？如果你记住了缓存机制，会答 true。但面试官马上会加一句——改成 128 呢？由于 Integer 的缓存范围默认是 -128 到 127，超出这个范围就会新建对象，所以 128 的结果是 false。追问到这里还不算完，你再想想如果两个 Integer 是用 new 创建的，比如 new Integer(1) 和 new Integer(1)，那 == 的结果必然是 false，因为它们是堆上的两个不同对象。

我自己的经验是，回答这类题目时不要只给结论，顺手把底层的缓存类（比如 IntegerCache）或者常量池机制带一句，面试官会觉得你对语言本身的了解是有深度的。另外提醒一点，写业务代码时如果你真的需要比较两个对象的内容是否相等，记得一定要重写 equals，同时配套重写 hashCode，这是后面还会被追问到的一个点。

2.3 String、StringBuilder、StringBuffer 到底怎么选

这个考点几乎逢面必问，因为它牵涉到“不可变”、“线程安全”和“性能”三者之间的权衡。你先要明确 String 是不可变类，底层基于 final 修饰的 char 数组（在 JDK 9 之后换成了 byte 数组）。不可变带来的好处是安全、可缓存哈希值、适合作为 HashMap 的键，但也意味着任何拼接操作都会产生新的对象。

StringBuilder 和 StringBuffer 都继承自 AbstractStringBuilder，它们内部的 char 数组是可变的。两者的区别只有一个：StringBuffer 的关键方法都加了 synchronized 修饰，所以是线程安全的，但性能比 StringBuilder 差一些。在实际开发中，字符串的拼接操作绝大多数发生在方法内部这样的单线程环境里，所以默认应该选择 StringBuilder。

面试官在这个题上的进阶追问通常集中在“效率”上。他会问：String 用 + 拼接字符串，底层是怎么实现的？你要答出，在编译阶段，Java 编译器会进行优化，比如 String a = "a" + "b" 会被直接编译成字符串常量 “ab”；但如果拼接中有变量，比如 str + i，编译器会转换成类似 new StringBuilder().append(str).append(i).toString() 的形式。紧接着他会追问：既然如此，在循环里用 + 拼接还有问题吗？这就正好踩中了一个大坑——循环里每次 + 都会在循环体内创建一个新的 StringBuilder 对象，导致大量的临时对象和频繁的垃圾回收，正确作法是循环外面创建 StringBuilder。

2.4 深拷贝与浅拷贝：从热词“java 对象深度拷贝”说起

对象拷贝这个话题在面试里不算最高频，但搜索热词里出现了“java对象深度拷贝”，说明关注的人不少。核心要分清楚三个概念：直接赋值、浅拷贝、深拷贝。直接赋值不说了，只是把引用复制了一份，两个变量指向同一个对象。浅拷贝需要对象实现 Cloneable 接口并重写 clone 方法，默认的 Object.clone() 就是浅拷贝——它会把当前对象内部的各个字段值复制到新对象里，但如果字段是引用类型，那么复制的是引用，而不是引用指向的那个对象本身。也就是说，新对象和原对象内的嵌套对象仍然是同一份。

深拷贝要求把对象内部的引用类型字段也递归地复制出一个新对象，这样新对象和原对象在内存中完全独立，互不影响。实现深拷贝的方式有几种：重写 clone 方法并手动克隆每一个引用字段（麻烦且容易漏）、通过对象流序列化反序列化实现（要求所有层级字段都可序列化）、或者使用 JSON 工具进行序列化和反序列化（比如 Jackson、Gson）。我自己在实际项目中比较推荐用 JSON 的方式做深拷贝，因为实现成本低，而且结构变化时不需要频繁改代码。

这块很容易被追问的问题是“为什么重写 clone 方法前必须实现 Cloneable 接口”。原因是 Object.clone() 在 JVM 层面会检查当前对象所属的类是否实现了 Cloneable 接口，没实现就直接抛 CloneNotSupportedException。这个检查是 JVM 做的，不是编译器强制，所以你漏掉实现接口时，编译器不会报错，但运行时会抛异常。回答时能把这个机制点出来，会显得你对 JVM 层面的约束有真实的理解。

3. 集合框架：HashMap 一题能问出三种水平

3.1 先理清两个高频对比：ArrayList vs LinkedList

面试官问你 ArrayList 和 LinkedList 的区别时，他其实想确认你有没有真正学过数据结构和理解日常开发的场景。基础的对比当然是：ArrayList 底层是动态数组，LinkedList 底层是双向链表。接着说性能：ArrayList 随机访问是 O(1)，插入和删除在中间位置需要移动元素，复杂度是 O(n)；LinkedList 随机访问是 O(n)，但头尾插入删除是 O(1)。到这里属于及格线，但更关键的是，你要知道在实际开发中 ArrayList 的使用频率远高于 LinkedList，因为绝大多数场景是遍历和随机访问优先。

面试官最喜欢追加的问题是“ArrayList 扩容机制是怎样的”。你要能准确说出，ArrayList 初始容量是 10（如果没有指定的话），当元素个数快要超过容量时，会进行扩容；新容量是旧容量的 1.5 倍，具体的计算是 int newCapacity = oldCapacity + (oldCapacity >> 1)，也就是右移一位相当于除以 2，再加上原值。扩容的本质是新建一个更大的数组，用 Arrays.copyOf 把原数组内容搬过去，旧数组被回收。频繁扩容会带来性能损耗，所以如果你预判数据量很大，最好在创建 ArrayList 时就指定初始容量。

针对 LinkedList，面试官也喜欢追问它实现了哪些接口。你需要提到它同时实现了 List 接口和 Deque 接口，因此它可以当队列用。但从实践角度，Java 工程师日常写代码，队列首选 ArrayDeque，它不需要维护节点之间的指针，内存更紧凑，性能更好。能答出这种“实践优先级”，会让面试官觉得你不仅仅是背书，而是真的在工程里选过型。

3.2 HashMap 的底层结构、扩容与红黑树化

HashMap 是整个 Java 集合框架里最重要的一个类，没有之一。面试官只要看到简历里出现了“熟悉 Java 集合”，十有八九都会从 HashMap 开始考。你需要掌握的内容可以按层次拆开来看。

第一层，底层数据结构。JDK 8 以后，HashMap 的数据结构是数组加链表加红黑树。数组用来做散列碰撞的桶位，链表用于挂在同一个桶位上的多个元素，当链表长度超过 8 且数组长度达到 64 时，链表会转换成红黑树。这段描述中的两个数字必须记住，而且最好理解它的设计原因——红黑树的查询复杂度是 O(log n)，而链表是 O(n)，之所以不直接用红黑树，是因为红黑树的节点占用空间大约是普通节点的两倍，为了在时间和空间之间找平衡，只在链表过长时才做转换。

第二层，put 的流程。计算 key 的 hashCode，然后用扰动函数处理之后再求模。这里的细节是：HashMap 用 (n - 1) & hash 来代替取模运算，前提是数组长度必须是 2 的指数幂。所以面试官通常还会追问——为什么 HashMap 的容量要求是 2 的指数幂？答案要从两方面说：一是 (n - 1) & hash 的运算比 % 高效，二是当 n 是 2 的指数幂时，n - 1 的低位全为 1，哈希值参与位运算后能更充分地保留散列性。如果你能还能提一句“扰动函数里右移 16 位是为了让高位也参与运算，减少碰撞”，分位就拿到了。

第三层，扩容机制。默认加载因子是 0.75，最大容量是 2 的 30 次方。扩容时，数组长度翻倍，所有元素需要重新计算桶位，这一过程称为 rehash。面试官经常会问“JDK 8 的扩容做了哪些优化”，答案是 JDK 8 不需要每个元素都调用 indexFor 重新计算，而是通过判断原哈希值的某个新增 bit 位是 0 还是 1，来确定元素是留在原位置还是移动到“原位置加旧容量”的位置。这个优化在高并发或大量元素场景下能明显降低扩容耗时。

3.3 面试官追问：HashMap 线程安全吗，那 ConcurrentHashMap 呢

HashMap 线程不安全，这个结论人人都知道，但你要能说出它为什么线程不安全——JDK 8 之前，多线程并发 put 可能导致链表形成环，从而在下一次 get 时出现死循环；JDK 8 之后死循环问题得到了一定改善，但多线程并发 put 仍然会出现覆盖问题，以及并发扩容时数据丢失的问题。所以在并发环境下，你不能用 HashMap。

面试官会顺势引出 ConcurrentHashMap。你需要先区分版本：JDK 8 之前，ConcurrentHashMap 用的是分段锁机制，默认分为 16 个 Segment，每个 Segment 内部是一个小的 HashMap，锁的粒度是 Segment 级别；JDK 8 之后，它放弃了分段锁，改用 CAS 加 synchronized，把锁粒度缩小到单个桶位。put 流程中，如果桶位为空，直接用 CAS 写入；如果桶位不空，则对这个桶的头节点加 synchronized 锁再操作。这样做的优势是并发度大大提升，不同桶位的操作可以并行进行。

如果你还想进一步拉开差距，可以说自己知道 ConcurrentHashMap 的 size 统计逻辑——它采用 counterCells 来避免对所有桶位加锁统计。这个层次能答出来，面试官基本就知道你对并发容器确实有研究。

3.4 从数组越界异常说到集合使用规范

搜索热词里有“java 中数组越界异常”，这个点经常出现在笔试环节中的代码阅读题中。ArrayIndexOutOfBoundsException 本身很简单，但面试官更喜欢考察的是你在遍历时候的注意事项。比如 for 循环遍历集合时，如果循环体内调用了 remove 方法，直接报 ConcurrentModificationException——这个异常的底层原因是 modCount 在迭代过程中发生变化，迭代器内部的 expectedModCount 核验不通过。解决方法有三个：使用迭代器自带的 remove 方法、使用 CopyOnWriteArrayList、或者倒着遍历用普通 for 加 remove。

这段内容的面试价值不是让你背结论，而是告诉你“集合操作规范”也是考点分支。日常用集合时，建议随手掌握几个安全操作套路：频繁增删且需要随机访问时优先考虑 LinkedList；需要线程安全时根据读写比例选择加锁策略还是 CopyOnWrite 容器；遍历时避免在循环体里直接改结构。这属于经验层面，虽然面试未必直接问，但面试官如果出场景题考你代码设计的合理性，这些就是你的答题素材。

4. 并发编程：从八股到实战的桥

4.1 synchronized 与 ReentrantLock：锁的层级你理解到哪一层了

并发编程是 Java 面试的硬骨头，每年挂人最多的就在这里。先从最经典的对比说起：synchronized 是 JVM 层面通过 monitorenter 和 monitorexit 指令实现的隐式锁，而 ReentrantLock 是 JDK 层面的 Lock 接口实现类。synchronized 使用简单，出了异常自动释放锁；ReentrantLock 需要手动加锁和释放，并要求在 finally 块中释放，否则容易造成死锁。

追问的重点通常在“synchronized 在 JDK 6 之后做了什么优化”。你要能答出偏向锁、轻量级锁、重量级锁这个升级路径：无锁状态时，JVM 会先尝试偏向锁（记录持有线程的 ID）；一旦有竞争，升级为轻量级锁（用 CAS 尝试获取）；竞争进一步激烈，膨胀为重量级锁（依赖操作系统互斥量）。这个设计是为了减少用户态和内核态的切换开销。能讲到这个层级，说明你对锁原理有系统性认识。

ReentrantLock 的特点则要从三个关键词展开。一是可重入，同一线程可以重复获取同一把锁，底层通过状态计数来实现；二是公平性，构造函数传入 true 表示公平锁，按照线程等待的顺序分配锁；三是可中断，lockInterruptibly 方法允许等待锁的线程被打断。这些能力都是 synchronized 在功能上的短板。面试官如果继续追问“公平锁和非公平锁的性能差异”，你可以说非公平锁吞吐量更高，因为它减少了线程挂起和唤醒的上下文切换，但公平锁避免了线程饥饿，具体选型要看业务对公平性的要求。

4.2 volatile 的两重语义：可见性与有序性

volatile 是最容易被轻视的考点，因为它的语法很简单，但背后的原理很深。它有两重核心语义：可见性，即一个线程修改了 volatile 变量的值，其他线程可以立即看到；有序性，即禁止指令重排序优化。它不能保证原子性，这是最关键的一句——很多人把 volatile 和原子操作混为一谈，面试官特别爱抓这个点。

为什么 volatile 能保证可见性？这就得说到 Java 内存模型（JMM）了。JMM 规定每个线程有独立的工作内存，线程对共享变量的读写都在工作内存中发生，不能直接操作主内存。被 volatile 修饰的变量，在写操作之后会强制把工作内存中的副本刷新回主内存；在读操作之前，会强制从主内存重新读取。这样就打破了普通变量在各线程工作内存中的“隔离”状态。

为什么不保证原子性？最经典的例子是 i++。i++ 在字节码层面实际上要经历“读取 i、计算 i+1、写回 i”三个步骤。volatile 虽然保证了读取和写入的可见性，但 A 线程读到的 i=5 还没写回，B 线程可能已经读到了 i=5 并计算完写回了 6，A 线程再写回时把结果覆盖成了 6——这一步是“读改写”整体上不原子导致的。如果面试官追问“那怎么保证 i++ 原子性”，你可以说用 synchronized 或 AtomicInteger，也可以说在 JDK 8 中可以用 LongAdder 在高并发下获得更好的性能。

4.3 线程池的 7 个参数和“选手策略”

线程池是并发模块里最能联系实际的一个考点。为什么不用裸线程，而用线程池？因为线程池实现了线程的复用、避免了频繁创建销毁线程的开销，同时还可以控制并发度，避免资源耗尽。这个基础道理要讲清楚。

核心的问题是 ThreadPoolExecutor 的 7 个构造参数，面试官会让你一个一个列出来并解释。核心线程数、最大线程数、空闲存活时间、存活时间单位、工作队列、线程工厂、拒绝策略，这 7 个缺一不可。你需要准确说出它们的含义，但更重要的是要理解“线程池的执行流程”：提交任务时，先判断核心线程是否已满；没满就创建线程执行；满了就把任务放入队列；队列满了再看线程数是否达到最大值；还没到就创建额外线程；到了最大值就执行拒绝策略。

拒绝策略有四种：AbortPolicy 直接抛异常、CallerRunsPolicy 调用者线程自己执行任务、DiscardPolicy 丢弃任务、DiscardOldestPolicy 丢弃队列中最早的任务。这里有一个很容易被问到的坑——实际开发中你选哪种？答案是如果你丢任务会影响业务，那都不该选，应该考虑调整线程池参数或者用带缓冲的消息队列来削峰。能答出“拒绝策略不是用来处理正常流量，而是用来保护系统不被打垮的”这个层面，你就已经从“背参数”上升到“理解设计”了。

线程池参数如何设置，也是个常见追问。我给你的建议是分场景：CPU 密集型任务，线程数设为 CPU 核心数加 1，目的是多一个线程来补偿偶尔的线程阻塞；IO 密集型任务，线程数可以设为 CPU 核心数的两倍，或者采用“核心线程数 = CPU 核数 / (1 - 阻塞系数)”这种公式来计算。但说实话，纯靠公式并不完全可靠，更务实的做法是先给定一个初始值，然后通过压测观察 CPU 使用率、队列积压情况和响应时间，迭代调整。

4.4 ThreadLocal 的原理与内存泄漏问题

ThreadLocal 是并发模块里容易让人迷糊的一个点，也是面试官喜欢深挖的题目。它的作用是让每个线程拥有自己的变量副本，从而实现线程间的数据隔离。底层实现是每个 Thread 内部有一个 ThreadLocalMap，这个 Map 的 key 是当前的 ThreadLocal 对象，value 是你存入的数据。看起来是一个 Map 在存数据，但实际这个 Map 是挂在 Thread 上的，所以不同线程的 ThreadLocalMap 天然隔离，互相访问不到。

为什么说 ThreadLocal 容易内存泄漏？因为 ThreadLocalMap 的 key 用的是 ThreadLocal 的弱引用。弱引用的意思是，只要没有其他强引用指向这个 ThreadLocal 对象，下一次 GC 时它就可能被回收，此时 Map 里就留下了一个 key 为 null、value 还存在的 Entry。如果线程存活时间很长（比如线程池里的线程），这些 value 就永远无法被回收，从而造成内存泄漏。正确的释放姿势是在使用结束后调用 remove 方法清理，而不是依赖 GC——这也是阿里开发规范里明文要求的。

面试追问有一个变形：ThreadLocal 在父子线程之间能传递数据吗？答案是不能，除非用 InheritableThreadLocal 或者引入第三方工具类比如 TransmittableThreadLocal。这个点虽然不是最高频，但如果你能主动展开，会显得你理解得比较全面。以我个人经验，在面试中说清 ThreadLocal 的弱引用设计是加分项，但一定要点到“如果用完不 remove，在线程池这种复用线程的场景下会出大问题”，面试官基本就会在这一题上给你高分。

4.5 CAS 与 ABA：再深入一点就是面试加分项

CAS，即比较并交换，是乐观锁的核心实现方式。它的逻辑很简洁：将主内存中的值与期望值做比较，如果相同，则更新为新的值；如果不相同，则重试或放弃。JDK 中的 atomic 包、AQS 框架以及 ConcurrentHashMap 的很多操作底层都依赖 CAS。面试时你要能说出它是 CPU 层面通过一条原子指令来保证的，没有加锁的开销。

CAS 最大的问题是 ABA 问题。假设变量初始值 A，线程 1 计划把它改成 C，在读取到 A 之后被挂起；线程 2 将 A 改成 B 又改回 A；线程 1 恢复后执行 CAS，发现主内存值还是 A，于是更新成功。但这个更新结果可能掩盖了中间状态发生过的变化。解决方案是用带版本号的 AtomicStampedReference，每次修改时版本号 +1，比较时同时比较引用和版本号，避免“值相同但已被修改过”的场景。

从面试策略上，CAS 和 volatile 经常放在一起考，面试官想看到的逻辑链是：volatile 解决可见性和有序性，但不解决原子性；原子性可以通过 synchronized 或 CAS 来保证；CAS 有 ABA 问题，某些场景需要用版本号来解决。这条链路能完整复述，并发模块的基础分基本就拿到了。

5. JVM 与排查：面试最爱问的“内存”与“类”

5.1 JVM 内存区域：哪些是线程私有，哪些是共享

JVM 内存模型是面试中绝对不能回避的内容。运行时的内存区域可以分成两大块：线程私有区域和线程共享区域。线程私有的包括程序计数器、虚拟机栈、本地方法栈；线程共享的包括堆和方法区。这里的关键不是背出每个区域的名字，而是搞清楚它们各自的作用。

程序计数器用来记录当前线程执行的字节码行号，用于分支、循环、跳转和异常处理等操作；虚拟机栈以栈帧为单位，每个方法调用对应一个栈帧的入栈和出栈，栈帧里包含局部变量表、操作数栈、动态链接、方法出口等。如果你听到“StackOverflowError 是怎么来的”，多半就是因为虚拟机栈的深度超出了系统允许的范围；而“OutOfMemoryError: Java heap space”则是因为堆中无法再分配新对象。

堆是所有线程共享的区域，也是 GC 最主要的战场。对象实例基本都分配在堆上，堆又可以细分为新生代和老年代，新生代再细分为 Eden 区和两个 Survivor 区。方法区在 JDK 8 之后被移除，改为元空间（Metaspace），它使用的是本地内存而不是 JVM 堆内存。这里面试官有很高的概率追问“为什么 JDK 8 要把永久代换成元空间”，答案是字符串常量池迁移到了堆中，且元空间使用本地内存，不受 JVM 最大堆内存的限制，从而降低 OOM 的可能性，同时方便开发者通过设置 -XX:MaxMetaspaceSize 来控制大小。

5.2 类加载过程与双亲委派

类加载机制是 JVM 部分最容易考“底层理解”的题目。类的生命周期包含加载、验证、准备、解析、初始化、使用、卸载七个阶段，其中前五个是面试重点。加载阶段是查找字节流、生成 Class 对象；验证阶段是校验 Class 文件的格式、字节码语义等；准备阶段是为静态变量分配内存并设置初始值；解析阶段是将符号引用替换为直接引用；初始化阶段是执行类构造器方法，给静态变量赋代码中指定的值。

双亲委派机制是这个知识点的核心。它的意思是，当一个类加载器需要加载类时，它不会自己先尝试，而是把请求委派给父加载器，逐级向上，直到最顶层的启动类加载器；只有父加载器无法完成加载时，子加载器才会尝试自己加载。各个类加载器各司其职：启动类加载器加载 JDK 核心类（rt.jar 中的类）、扩展类加载器加载扩展目录下的类、应用类加载器加载 classpath 下的类。

为什么要设计双亲委派？关键在于保证核心类的唯一性和安全性。举个典型的例子，如果你自己写了一个 java.lang.String 类并放到 classpath 中，如果没有双亲委派机制，应用类加载器就会加载这个自定义的 String 类，导致 JVM 中出现两个同名的核心类，整个类体系崩塌。而有了双亲委派，String 类始终由启动类加载器加载，你写的那份永远没有机会被加载。面试官如果继续追问“能不能破坏双亲委派”，你可以回答可以，比如实现 ClassLoader 时重写 loadClass 方法而不经过父类加载，Tomcat 为了实现多个应用的独立类加载，就打破了双亲委派机制。

5.3 GC 算法与可达性分析

垃圾回收算法的题目，考察的就是你对内存回收策略的理解。先是最基础的问题：哪些对象可以被回收？主流方案是可达性分析。它从一组称为 GC Roots 的根对象出发，顺着引用关系向下遍历，能够到达的对象就是存活的，不可达的对象则需要被回收。GC Roots 通常包括虚拟机栈中引用的对象、静态属性引用的对象、常量引用的对象、JNI 引用等。

接下来是三个经典回收算法。标记-清除算法分两步走：标记所有可回收对象，然后统一回收。缺点有两个：效率不稳定，以及产生大量不连续的内存碎片。标记-复制算法把内存分成两块，每次只用一块，垃圾回收时把存活的对象复制到另一块，再一次性清理当前块。它避免了内存碎片，但代价是空间的浪费。标记-整理算法在标记阶段后让存活对象往一端移动，然后直接清理边界外的内存，解决了碎片问题但移动对象会增加开销。

现代商用虚拟机的分代收集策略正是建立在对这些算法的组合使用之上。新生代对象存活率低，适合复制算法，于是新生代被分为 Eden 和两个 Survivor 区，默认比例是 8:1:1；每次 Minor GC 把 Eden 和一个 Survivor 中的存活对象复制到另一个 Survivor，并清空另外两个区域。老年代对象存活率高，适合标记-整理或标记-清除算法。如果你能顺带说出几款垃圾收集器的名字和适用场景，比如 G1 面向大堆且追求可预测停顿时间，ZGC 的目标是把停顿时间控制在极低的水平，面试官对你的评价还能再上一个台阶。

5.4 线上 OOM 排查：一个实战案例

这部分内容在面试中越来越常出现，因为它直接关系到一个后端工程师能否独立排查线上故障。面试官常会给一个虚构场景：某天线上应用报出 OutOfMemoryError，你如何排查？我的习惯分成四步。

第一步，保留现场。在 JVM 启动参数中加上 -XX:+HeapDumpOnOutOfMemoryError，这样系统抛 OOM 时会自动生成堆转储文件，这是最重要的证据。第二步，获取基本信息。用 jps 找到进程 ID，用 jstat -gcutil 观察各个内存区域的使用情况和 GC 次数；如果发现老年代持续增长且 Full GC 频繁，基本可以断定是对象无法释放。第三步，分析堆转储文件。用 Eclipse MAT 或 jhat 打开 dump 文件，查看最大的对象是什么，找出持有它的引用链。大多数情况下你能定位到某个全局集合类在无限增长，或者某个线程池的队列里堆积了没有被消费的任务。第四步，根据根因修复。如果是代码忘了 remove 导致缓存集合一直膨胀，就把代码改掉；如果是并发量超出预期导致队列堆积，就要评估是否需要扩容或增加消费者。

回答这种场景题，面试官最看重的是排查思路是否清晰，以及是否知道常用的 JVM 工具。哪怕你说不出特别高深的调优参数，能把 jps、jstat、jmap、jstack 这几个工具说清楚，再配上一次完整的 dump 分析流程，就已经是一个非常合格的答案。顺便提一句，平时开发时就可以时不时看一眼内存和 GC 日志，尽早养成看监控的习惯，比临时抱佛脚强太多。

6. 框架与生态：Spring、SpringBoot、MyBatis 必问点

6.1 Spring Bean 的生命周期

框架部分考 Spring 比例极高，而 Bean 生命周期又是 Spring 最经典的考点。完整流程可以概括为：实例化、属性填充、各种 Aware 回调、BeanPostProcessor 的前置处理、初始化方法、BeanPostProcessor 的后置处理、销毁。简化记忆的话，可以抓主线：实例化 -> 属性填充 -> 初始化 -> 使用 -> 销毁。

实例化阶段，Spring 通过无参构造器或工厂方法创建 Bean 实例；属性填充阶段，Spring 会把配置文件或注解中定义的属性值注入到 Bean 中。接下来是各种 Aware 回调，比如 BeanNameAware 用来让 Bean 感知自己在容器中的名字，ApplicationContextAware 用来让 Bean 获取容器上下文。再往后是 BeanPostProcessor 的 postProcessBeforeInitialization，然后执行 init-method 或 @PostConstruct 标注的初始化方法，最后是 postProcessAfterInitialization。

这里有一个容易被追问的坑——InitializingBean 接口和 @PostConstruct 注解和其他初始化方式的执行顺序是什么。准确的顺序是：@PostConstruct 方法最先执行，然后是 InitializingBean 的 afterPropertiesSet 方法，最后才是 init-method 指定的方法。这个顺序很多面试者记不清楚，你如果能在回答中信手拈来，会立刻和普通候选人拉开差距。顺带一提，Spring 能识别 @PostConstruct 是因为调用了 CommonAnnotationBeanPostProcessor 这个 BeanPostProcessor，能说一句这个底层实现，比你只背顺序要有说服力得多。

6.2 Spring 事务传播行为

事务是后端业务里逃不掉的话题，Spring 事务传播行为更是常客。Spring 中定义了 7 种传播行为，但面试核心通常聚焦在三种：REQUIRED、REQUIRES_NEW、NESTED。REQUIRED 是默认值，如果当前没有事务就新建一个，如果当前已有事务就加入当前事务；REQUIRES_NEW 是无论如何都挂起当前事务并新建一个独立事务，两个事务互不影响；NESTED 是嵌套事务，它依赖外层事务，但在内层做了 savepoint，如果内层回滚但外层仍可提交部分内容。

面试官特别喜欢出一个场景题：方法 A 调用方法 B，B 抛了异常，在什么情况下 A 的事务会回滚回滚，在什么情况下不会？答案的关键在于事务的边界是由代理对象控制的。如果你是在 A 的内部直接调用 B（也就是 this.b() 这种形式），B 上的事务注解根本不会生效，因为调用没有经过 Spring 的代理对象，而是直接走的目标对象——这是经典的“事务自调用失效问题”。如果 B 是独立 Bean 的实例，A 注入的是代理对象，那 B 的事务才会正常生效。

顺着这个知识点，面试官还会问“Spring 事务在什么情况下会失效”。我可以给你列几个高频场景：方法不是 public 修饰的，事务不生效；类没有被 Spring 管理，事务不生效；异常被 try-catch 吞掉了，事务探测不到异常，不回滚；抛出的是检查异常但事务配置里没指定 rollbackFor，也不回滚。回答这些场景时，最好都能附带解释原因，而不是单纯报菜名，这样面试官才知道你是理解过还是背过的。

6.3 SpringBoot 自动配置原理

SpringBoot 的自动配置几乎是必考题，因为它太核心了。首先你要明确几个要素：@SpringBootApplication 是组合注解，由 @SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan 组成。自动配置的核心在 @EnableAutoConfiguration 这个注解上，它通过 @Import 引入了一个叫 AutoConfigurationImportSelector 的类。

AutoConfigurationImportSelector 的作用是从 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件中读取所有候选的自动配置类。加载之后，这些配置类会按条件注解进行筛选。比如 @ConditionalOnClass 要求类路径下存在指定类才生效，@ConditionalOnMissingBean 表示容器中没有某个 Bean 时才创建默认实现。所以你引入 spring-boot-starter-web 依赖之后，SpringBoot 会检测到类路径下有 DispatcherServlet 等类，然后自动创建一个 Web 应用环境下的默认配置。

提到这里，面试官很容易追问“自定义一个 starter 需要怎么做”。答题步骤简单归纳为：新建一个 autoconfigure 模块，编写配置类，在配置类中创建需要的 Bean，在 META-INF 下的 imports 文件中注册这个配置类，最后封装成一个 starter 依赖供其他模块引用。这个题目能答完整的人不多，因为大多数人只是用过 starter，没有自己写过 starter；一旦你能说出完整流程，面试官通常会很欣赏。

6.4 MyBatis 井号和美元符号的区别

MyBatis 是很多项目里使用的持久层框架，它的高频考点集中在动态 SQL 和参数绑定上。最经典的题是 #{} 和 ${} 的区别。简单说，#{} 是预编译处理的占位符，MyBatis 会把它替换成 ?，然后通过 PreparedStatement 传入参数值；而 ${} 是做字符串拼接，直接替换到 SQL 语句中。前者可以防止 SQL 注入，后者存在注入风险。

继续追问的话，面试官会想知道什么时候必须用 ${}。典型场景是动态表名或列名，比如按月份分表 select * from ${month}_table，或者排序语句 order by ${column}。因为表名和列名不能作为占位符参数传入 PreparedStatement，所以只能通过字符串拼接。此时你就要格外小心传入值的来源，必须做白名单校验，避免用户直接控制这段内容。

日常开发中，MyBatis 最容易遇到的坑之一是“参数为 null 导致的动态 SQL 问题”。推荐在写动态 SQL 时留意 if test 的判断是否覆盖了所有可能的分支。还有一个常见的坑是 DAO 层方法参数过多时没有用 @Param 注解，导致 MyBatis 绑定时报错。这种细节虽然不起眼，但面试官把它做成代码题时，很多人还真答不出来。

7. 面试答题技巧与避坑经验

7.1 答题的“三层结构”

知识点聊完了，我想花点篇幅分享一些面试答题的方法论。我发现很多候选人并不是不会，而是表达方式有硬伤。要么只给结论不展开，要么上来就背一大堆细节，面试官根本找不到重点。比较推荐的方式是三层结构：先给结论，再解释原理，最后补例子或场景。

比如你被问到“什么是线程池”，不要开口就从 ThreadPoolExecutor 的参数开始罗列。你先说结论——线程池是一套线程复用和管理机制，能控制并发度、降低资源开销。然后解释原理——线程池内部维护了一组 worker 线程和一个阻塞队列，任务提交后由线程按流程处理。最后落地到例子——比如我们的支付系统用线程池处理回调通知，核心线程 8，最大线程 16，队列长度 200，超出后走告警而不是直接丢弃。这样的回答层次分明，面试官顺着你的结构就能判断你的水平。

另外要养成一个习惯：每一道题回答完之后说一句“总之，它的核心是xxx”，用一句话收束。这样做有两个作用，一是帮助面试官记忆你的关键结论，二是给自己一个喘息机会，同时避免把回答无限拖长。学会这种“三层结构”的答题方式，比你多背五十道题都管用。

7.2 常见踩坑盘点

面试中有些坑属于共性的，我在这里盘点几个最常见的，帮大家避一避。第一个坑是“不懂装懂”。比如面试官问一个你只听说过名字的概念，你觉得不回答太丢面子，于是硬着头皮编了一套。这时候面试官只要追问一个细节，你立刻穿帮。我的建议是遇到不熟悉的问题，可以直接说“这个方面我了解得不够深，但我对与之相关的xxx是比较熟悉的”，然后主动把话题引向你擅长的方向。诚实的态度反而能留下好印象。

第二个坑是“只看概念不看数字”。很多同学能说出 HashMap 默认大小是 16，但问加载因子为什么是 0.75 时，就沉默不语。面试官不是要你背所有参数，而是要你理解这些参数为什么这样设计。所以在复习时，尽量把每个结论背后的原因也看一下，哪怕只是一两句话，也会让你的答案更有说服力。

第三个坑是“不会用工具”。你哪怕理论背得滚瓜烂熟，面试官问你线上 OOM 排查步骤时，你说不出 jmap 怎么用，那背书痕迹就太明显了。我强烈建议在笔试前花几天时间，亲手在本地环境跑一个模拟内存溢出的程序，然后用工具完成一次完整的排查，这个实操经验会让你在面试时比别人从容很多。

7.3 临场策略

最后聊点心态层面的东西。面试时遇到难题很常见，不要因为一道题没答上来就慌乱甚至放弃后面的表现。面试官通常会从多个维度评估候选人，一个知识点不会，不等于整体水平不够。你完全可以说“这块我目前还没有深入了解，如果能给我一点提示，我愿意现场尝试推导”，这种态度在很多面试官眼里比背答案更值钱。

另外我建议大家在面试前自己做一张“追问链”卡片，把高频题可能出现的追问列出来。比如 HashMap 的追问链是“底层结构 -> put 流程 -> 扩容机制 -> 线程安全性 -> ConcurrentHashMap 的演进”，你把这条链吃透了，面试时就能顺着面试官的思路走，而不是被动地挤牙膏。准备的维度和深度决定了你能在面试中走多远。

我自己见过很多候选人，基础扎实但表达松散，也有不少人会背很多题目但缺乏关联能力。这两类人都可以通过“追问链法”来补足——以高频题为锚点，把相关的 downstream 知识全部串起来。这个练习做两到三周，效果会非常明显。面试不是考试，它更像一场技术深度的对话；你的目标不是答对每一道题，而是让面试官相信你具备独立思考和解决问题的能力。把这些高频题背后的逻辑链想明白，剩下的交给临场发挥就好。