1. 聊一聊Java八股文面试题被吐槽这么多年为什么还是绕不开每年一到招聘季Java八股文面试题的搜索量就会突然涨起来。我自己做过面试官也作为候选人被面过对这种题的感情很复杂。一方面我见过太多把八股文背得滚瓜烂熟、但让他排查一个线上OOM就完全没头绪的候选人另一方面我也不得不承认在有限的面试时间里八股题是效率最高的基础能力过滤器。这篇内容就是想把面试中真正高频、且值得深挖的Java题目重新梳理一遍给出我从面试官和候选人两个角度总结出来的答题思路。先说清楚这篇文章适合谁。准备校招的应届生、想跳槽的初中级Java开发都能从中找到自己需要的东西。我不会只丢结论会尽量把为什么是这个答案讲明白。因为这些题目之所以被反复问不是因为面试官懒而是因为它们的背后连接着JVM、并发、数据结构和工程实践——这些恰恰是区分背题选手和真懂原理的分水岭。1.1 八股文到底在考什么能力很多人把八股文等同于死记硬背其实不完全对。面试官问HashMap的时候他不是真的在乎那个链表转红黑树的阈值是8还是16他在乎的是三件事第一你的基础有没有系统性。Java开发者每天在用的集合、并发、JVM底层是怎么回事这决定了他能不能给你安排更有挑战的活。第二你能不能把复杂概念讲清楚。一个能把volatile怎么禁止指令重排用大白话讲明白的人通常也能把需求跟产品讲明白。第三你的知识边界在哪里。八股题最好的地方是它有标准答案答得越深越能看出你是背的还是懂的——我经常在候选人答完标准答案后追问一句为什么是0.75这一句话能淘汰掉一半人。所以我自己在准备这类问题时从来不会只看一版答案而是把每个知识点当作一个入口往里挖两三层。比如HashMap不只是数组加链表它背后的泊松分布、扩容时机、树化条件每一个分支都能延伸出一连串问题。准备面试的过程其实就是在给自己做知识体检把平时写代码时凑合能用的部分全部暴露出来。1.2 面试官问八股时心里到底在想什么站在面试官的角度我个人的体会是问八股不是目的是手段。一个候选人如果连synchronized和ReentrantLock的区别都要想半天我很难相信他能独立处理一个有并发问题的线上故障。反过来说如果一个候选人能答出锁升级的过程还能顺带提一句JDK 6之后synchronized做过大量优化和ReentrantLock的性能差距已经很小选哪个主要看场景那这道题的目的就达到了——我要看到的不只是知识点而是他对技术演进的理解。常见的低分回答我也总结了几类。第一类是只背结论不解释原因比如知道负载因子是0.75但说不清为什么第二类是只背当前版本不理解演进过程比如对JDK 8的HashMap一脸懵却以为它生来就有红黑树第三类是答非所问面试官问原理他开始背源码行号。这些都是准备面试时容易踩的坑后面每个专题我会针对性地提醒。另外想说一句面试其实是双向的。你在被考察基础的同时也在判断这家团队的技术氛围。如果一个团队只会互相比谁背得熟那就算拿到offer进去了大概率也是复制粘贴式的开发。真正好的面试题目是固定的但沟通是开放的面试官会通过追问来观察你的思考过程而不是单纯对答案。2. Java 基础高频题HashMap、集合选型与异常机制的标准答案这一章聊的是面试中出现频率最高的几道基础题。它们看起来简单但恰恰是区分背过和理解的重灾区。我面试过的候选人里很多人在简历上写着熟练掌握Java集合框架可一旦问到扩容机制或者并发场景下的行为就开始含糊其辞。基础题的考察从来不是背出定义而是看你有没有在平时的代码里想过这些问题。2.1 HashMap 底层原理数组、链表与红黑树HashMap大概是Java面试中出场率第一的题没有之一。标准答法是HashMap底层是数组加链表JDK 8之后在链表长度超过8且数组长度达到64时链表会转成红黑树目的是把查询时间复杂度从O(n)降到O(log n)。存储时先对key的hashCode做一次扰动计算也就是(h key.hashCode()) ^ (h 16)然后通过(n - 1) hash计算桶下标。扰动函数的意义在于让高位信息也参与低位的计算降低hash冲突的概率因为数组长度是2的幂次直接用原始hash值参与下标计算时高位信息会丢失。但面试官通常不会让你停在这里追问会接踵而来。最经典的一个就是为什么负载因子是0.75。这其实是一个偏源码和概率的问题。0.75是时间和空间成本的一个折中太小了数组会频繁扩容浪费空间太大了冲突概率明显上升查询性能下降。HashMap源码的作者在注释里提到0.75的负载因子下桶内的节点数量服从泊松分布链表长度达到8的概率已经小于千万分之一这也是树化阈值选8的原因之一。如果你能把这个概率分布的背景说出来面试官基本就会往下一个话题走了。第二个必问的是扩容的时候发生了什么。默认容量是16扩容时容量翻倍。JDK 8做了一些优化因为扩容是2的幂次所以元素在新数组中的位置要么不变要么在原位置加旧容量。判断依据就是看key的hash值新增的那个bit是0还是1。这样做的好处是不用重新计算hash只需要看高位那一位效率高而且能避免rehash带来的性能开销。这里顺便可以提一句扩容是一个相对昂贵的操作所以如果能预估数据规模最好在初始化时指定容量避免频繁扩容。还有一类追问是HashMap为什么线程不安全。要说明白两个点一是JDK 7及之前并发扩容时可能出现环形链表导致get时死循环二是JDK 8之后虽然解决了环形链表的问题改成尾插法但并发put仍可能出现数据覆盖、size计算不准等问题。如果要线程安全建议用ConcurrentHashMap而不是在外部加synchronized了事。为什么会提ConcurrentHashMap因为它的锁分段或者CAS加synchronized的实现比直接锁整个Map要精细得多这个问题答到这儿面试官就知道你对并发集合也有概念。2.2 ArrayList 与 LinkedList别只背数组 vs 链表这道题就算面试官不问也大概率会在聊集合的时候带到。基础答案是ArrayList基于动态数组随机访问是O(1)中间插入和删除是O(n)因为要移动元素LinkedList基于双向链表头部尾部插入删除是O(1)但访问中间节点需要遍历所以随机访问是O(n)内存占用上每个节点还要额外存前后指针。问题是很多人卡在到底什么时候用LinkedList上。我个人的结论是在实际业务开发里LinkedList的多数优势都是理论上的。它的每个节点都是一个独立对象占用内存更大还会破坏CPU缓存的局部性而ArrayList扩容时虽然有数组拷贝的开销但由于内存连续遍历时缓存命中率高得多。所以很多场景下ArrayList的实际表现反而更好。LinkedList真正适合的场景是中段频繁插入删除且不需要随机访问但在Java里这类需求如果涉及队列通常直接用ArrayDeque更合适。ArrayList的扩容机制也是常考的细节默认容量是10扩容时新容量是旧容量的1.5倍通过oldCapacity (oldCapacity 1)计算。这里可以顺带谈一个实践细节如果你事先知道元素规模就用带初始容量的构造方法减少扩容次数。还有一个冷门考点是Arrays.asList返回的列表并不是java.util.ArrayList而是Arrays内部的一个私有类它不支持add和remove操作很多人在代码里踩过这个坑。面试时候能顺嘴提一句这种实际开发中的细节比单纯背效率对比要加分很多。2.3 异常机制与 try-with-resources 考点异常类题目经常出现在初级面试里问得最多的是checked exception和unchecked exception的区别。标准答案很清晰checked exception是编译期必须处理的异常比如IOExceptionunchecked exception包括RuntimeException和Error编译期不强制处理。但我会建议候选人补一句自己的理解在现代框架里这种区分的重要性正在被弱化很多框架会倾向于把异常包装成unchecked exception抛出去由全局异常处理统一兜底比如Spring的RestControllerAdvice。因为业务代码里到处catch受检异常会让代码变得非常啰嗦而且容易漏处理。另一个高频考点是try-with-resources。这道题考的是JDK 7引入的资源自动关闭机制要求资源实现AutoCloseable接口。常见的追问是如果try块和关闭资源时都抛了异常会怎样这里涉及suppressed exception的概念try块中的异常是主异常关闭时的异常会被附加为被抑制异常而不是覆盖主异常。这个细节能答出来的人不多属于加分项。还有一层的考点是为什么推荐用try-with-resources而不是在finally里手动close——因为finally里的close如果抛异常会吞掉try块里原始的异常给排查问题制造巨大障碍。异常这块还有一个容易被追问的实践问题线上日志里看到一堆重复的堆栈怎么快速的找到根因。我会先看最底层Caused by因为上层异常多半是包装出来的。一个合格的Java开发者要对异常链条有直觉而这种直觉恰恰是在平时写代码时认真处理异常积累出来的。3. 并发编程四板斧synchronized、volatile、ThreadLocal 与线程池并发几乎是Java面试必考的重头戏它直接关系到一个开发者能不能写出高并发下正确的代码。这一章的四个题目不只是高频它们之间还有很强的联动性建议放在一起理解。面试官往往从synchronized切入一路问到线程池中间穿插volatile和ThreadLocal整个过程就是一次完整的并发知识摸底。3.1 synchronized 与 ReentrantLock锁升级的关键细节synchronized和ReentrantLock的区别这道题我给的标准答法是分三层用法层、特性层、原理层。用法上synchronized是关键字自动加锁解锁ReentrantLock是API需要手动lock/unlock并且通常配合finally释放。特性上ReentrantLock支持可中断获取锁、支持超时等待、支持公平锁、可以用多个Condition实现精确唤醒synchronized在这几方面都比较弱。原理上synchronized在JDK 6之后引入了偏向锁、轻量级锁、重量级锁的升级路径而ReentrantLock是基于AQSAbstractQueuedSynchronizer实现的。如果要体现深度建议主动补充锁升级的过程无锁状态一个线程反复进入同步块时偏向锁会偏向这个线程一旦出现竞争偏向锁撤销并升级为轻量级锁通过CAS自旋获取锁竞争再加剧自旋失败的线程会阻塞锁升级为重量级锁依赖操作系统的互斥量。这里有一个很加分的细节——自旋次数JVM会自适应调节而不是固定的数字。所以回答时说JDK 6之前默认自旋10次之后改成了自适应自旋能明显体现出你跟踪过技术演进。ReentrantLock的公平与非公平也常被追问。公平锁是线程按请求顺序获取锁非公平锁允许插队。非公平锁的性能通常更好因为避免了线程唤醒带来的上下文切换开销ReentrantLock默认就是非公平的。我建议候选人答到这里时加一句公平锁在高并发下不一定更公平因为线程频繁被唤醒又阻塞吞吐量反而可能下降。这种辩证的看法比单纯背结论要有说服力得多。说到AQS通常会被追问原理。可以这样讲AQS维护了一个volatile的state变量和一个FIFO双向队列线程获取锁失败就封装成Node进入队列等待当持有锁的线程释放时会唤醒队头节点。ReentrantLock的公平性、可重入性、Condition这些能力都是基于这套框架实现的。不需要把AQS源码背下来但把state、CLH队列、加锁解锁的大致流程讲清楚面试就已经很加分了。3.2 volatile 怎么保证可见性和有序性volatile是面试中最容易讲得云里雾里的题目之一。很多人只会背保证可见性不保证原子性这个太浅了。正确答法是volatile通过内存屏障实现两个能力。一是可见性一个线程修改了volatile变量的值会强制刷新到主内存其他线程读取时能看到最新值这一点底层依赖缓存一致性协议比如MESI。二是有序性编译器和CPU为了性能会做指令重排而volatile变量的读写前后会插入内存屏障禁止相关指令重排。最经典的应用就是单例模式的DCL写法。为什么双重检查锁的单例要用volatile修饰instance因为instance new Singleton()不是原子操作它分为分配内存、初始化对象、把引用赋值给变量三步如果不加volatile编译器可能把后两步重排导致另一个线程拿到一个尚未初始化完成的对象。这个例子把可见性、有序性、重排三个概念全串起来了我个人认为这是这道题最好的答法建议候选人一定要把这段逻辑完整讲一遍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不能保证复合操作的原子性。经典的count问题本质是读改写三步多线程下即使加了volatile也会丢更新。要解决得用AtomicInteger、synchronized或LongAdder。这里可以补充一句AtomicInteger底层用的是CASCAS本身依赖的是硬件层面的原子指令所以在面试官追问AtomicInteger为什么能保证原子性时不会卡住。3.3 ThreadLocal 为什么会有内存泄漏风险ThreadLocal在面试中出现频率极高因为它不仅考原理还考工程意识。标准答法是ThreadLocal本身不存储数据每个Thread内部都有一个ThreadLocalMapMap的key是ThreadLocal的弱引用value是真正的数据。我们平时调用threadLocal.set(value)实际上是把数据放到了当前线程的ThreadLocalMap里。正因为它把数据绑定在线程上所以能做到线程间的数据隔离这也是它在事务管理、链路追踪里被广泛使用的原因。接下来是重点为什么会有内存泄漏因为key是弱引用当外部没有强引用指向ThreadLocal对象时GC会把key回收掉但value是强引用依然挂在线程的ThreadLocalMap上。如果这个线程长期存活比如线程池里的线程那么value就永远无法被回收这就是内存泄漏。正确的使用习惯是用完调用remove()清除尤其在try-finally或try-with-resources中做ThreadLocalContext threadLocal new ThreadLocal(); try { threadLocal.set(context); // 业务逻辑 } finally { threadLocal.remove(); }很多线上OOM排查到最后就是代码里用了ThreadLocal没remove线程池复用线程导致数据累积。我在面试里也会追问为什么不把key改成强引用答案是如果key是强引用即使外部不再使用ThreadLocal它也无法被GC回收反而扩大了泄漏范围弱引用加remove的组合是相对最安全的设计。另外还有一个细节ThreadLocalMap在set时会对key为null的Entry做清理但这种被动清理不可靠所以主动remove才是正解。3.4 线程池参数核心线程数和最大线程数怎么定线程池是并发章节的收尾题高频到几乎必问。第一问通常是ThreadPoolExecutor有哪些核心参数这个好答corePoolSize核心线程数、maximumPoolSize最大线程数、keepAliveTime空闲存活时间、workQueue任务队列、threadFactory线程工厂、handler拒绝策略。注意keepAliveTime默认只对非核心线程生效如果allowCoreThreadTimeOut为true核心线程也会回收这是一个容易忽略的细节。第二问是任务提交时是怎么流转的这是理解线程池的关键。流程是提交任务时如果当前线程数小于核心线程数直接创建线程执行如果核心线程已满任务进入阻塞队列如果队列也满了且线程数还没到最大线程数创建新线程执行如果线程数已经达到最大且队列也满了就执行拒绝策略。这个流程建议自己画在纸上理解一下面试时用自己的话讲一遍比背定义有用得多。第三问通常是拒绝策略有哪几种答案是四种AbortPolicy直接抛异常、CallerRunsPolicy让提交任务的线程自己执行、DiscardPolicy静默丢弃、DiscardOldestPolicy丢弃队列里最老的任务。工程上CallerRunsPolicy用得多一些因为它至少能让任务不丢失还能通过让调用线程执行任务来实现天然的背压。第四问就开始谈实际了核心线程数怎么定。这类问题没有标准答案我一般给的参考是CPU密集型任务核心线程数设置为CPU核数加1IO密集型任务设置为CPU核数的两倍左右或者用CPU核数 / (1 - 阻塞系数)估算。重点不是说这个数字而是说你理解为什么要区分——CPU密集任务把线程数压到和核数接近减少上下文切换IO密集任务大部分线程在等待IO可以适当多开。如果候选人能补一句线上一般还是靠压测来调整配合监控动态修改核心线程数那这道题基本就满分了。4. JVM 面试重灾区内存区域、类加载与垃圾回收的答法JVM相关的八股题是所有Java面试里最让候选人头疼的因为内容多、术语多而且面试官普遍爱追问。这一章我挑三个最核心的考点来拆每个都给出记忆框架和答题层次。4.1 JVM 运行时内存区域划分这道题的标准答法是按线程共享和私有来分。线程私有的有程序计数器、虚拟机栈、本地方法栈线程共享的有堆和方法区。JDK 8之后方法区被元空间Metaspace取代使用的是本地内存不再占用JVM堆内存。程序计数器是当前线程执行字节码的行号指示器如果执行的是本地方法程序计数器的值是Undefined这部分几乎不会抛OOM。虚拟机栈保存栈帧每个方法调用对应一个栈帧里面包含局部变量表、操作数栈、动态链接和方法返回地址栈深度不够时会抛StackOverflowError。堆是对象分配的主要区域分新生代和老年代新生代又分为Eden区、S0、S1两个幸存区默认比例通常是8:1:1。这里常见追问是为什么要分代不同类型对象的生命周期不一样绝大多数对象朝生夕灭分代后可以针对不同区域使用不同垃圾回收算法。比如新生代用复制算法因为存活对象少复制成本低老年代用标记整理或标记清除因为对象存活率高不适合频繁复制。面试中常考的OOM类型我整理了一个表方便记忆和对比OOM类型触发场景java.lang.OutOfMemoryError: Java heap space堆中对象太多比如大对象频繁分配、内存泄漏java.lang.OutOfMemoryError: Metaspace元空间不足常见于动态生成大量类的框架java.lang.OutOfMemoryError: GC overhead limit exceededGC回收效果差98%的时间在GC却回收不了2%的堆java.lang.OutOfMemoryError: Unable to create new native thread操作系统线程数受限或栈内存占用过高被问到线上OOM怎么排查时我的做法是先判断OOM类型然后通过jmap dump堆快照用MAT或者jvisualvm分析。如果堆正常但还OOM就要看是不是线程数超限或者DirectByteBuffer这类堆外内存的问题。这里真正考察的是你有没有成体系的排查思路而不是会背几个参数。4.2 类加载过程与双亲委派模型类加载的三阶段是加载、链接、初始化链接内部又分验证、准备、解析。加载阶段是把class文件字节码读入内存生成Class对象验证是检查字节码合法性准备阶段会为静态变量分配内存并设置默认值解析阶段把符号引用替换为直接引用初始化阶段执行静态变量赋值和静态代码块。这里有个容易答错的点准备阶段给静态变量分配的是默认值比如int是0真正的赋值发生在初始化阶段。只有final修饰的常量在准备阶段就会赋值。双亲委派模型的回答要点是流程加意义。一个类加载器收到加载请求时先不自己加载而是把请求委托给父加载器一直向上委托到Bootstrap ClassLoader父加载器加载不了才会回到子加载器。三个默认加载器分别是启动类加载器Bootstrap、平台类加载器Platform ClassLoaderJDK 9之前的扩展类加载器、应用类加载器AppClassLoader。为什么要双亲委派答案有两个核心一是安全避免用户自定义的java.lang.String替换掉核心类库二是保证类的唯一性避免同一个类被不同的类加载器重复加载出现两个不同Class对象。双亲委派被破坏也是一个加分考点。典型场景是JDBC的SPI机制java.sql.DriverManager在启动类加载器加载的类里它要调用由应用类加载器加载的驱动实现类双亲委派是做不到的所以引入了线程上下文类加载器来打破。Tomcat也是每个Web应用都有自己的类加载器是为了实现应用间类隔离。能讲到这个层次说明你是真的理解类加载机制而不只是背了结论。4.3 垃圾回收算法与收集器选择GC相关题目的核心是怎么判断对象可以回收和用什么算法回收。判断阶段主流方案是可达性分析从GC Roots出发遍历不可达的对象会被标记。GC Roots包括虚拟机栈中引用的对象、静态变量引用的对象、常量引用的对象、本地方法栈中引用的对象等。这里有一个经典追问两个对象互相引用没有其他引用会被回收吗答案是可以因为可达性分析从GC Roots出发互相引用但整体不可达的对象一样会被标记回收。这个例子能很好地检验候选人是不是真的理解了可达性分析而不是只知道引用计数法的概念。算法层面记住三种标记-清除先标记再直接清除缺点是会产生内存碎片标记-复制把内存分成两块把存活对象复制到另一块解决了碎片但浪费空间新生代用的就是这种思想的优化版只不过不需要按1:1分而是用Eden加两个幸存区来实现标记-整理标记后把所有存活对象向一端移动然后清理掉边界以外的内存适合老年代但移动对象需要STW。回答时可以提一下HotSpot新生代的8:1:1其实就是基于复制算法的优化设计。收集器部分JDK 8默认的Parallel Scavenge加Parallel Old侧重吞吐量适合后台计算类任务CMS追求低停顿但会有内存碎片和Concurrent Mode Failure问题JDK 9开始被废弃JDK 14被移除G1是JDK 9之后的默认收集器把堆划分成多个Region可以设定预期停顿时间兼顾吞吐和停顿。再往后还有ZGC主打超低停顿但一般面试问到G1打底就够用了。我自己的建议是这部分不要死背每个收集器的参数重点理解G1的Region式内存布局和在可预期的停顿时间内尽量多回收的设计思路这是目前最常见也是最容易出追问的点。5. Spring 家族高频考点IoC、AOP 与事务别只会背概念Spring是Java后端开发的事实标准面试不会再问Spring是什么而是直接问原理。这几个题背答案的痕迹最重也最容易被识破因为面试官稍微追问一个细节你真的理解还是背的马上就能看出来。5.1 Bean 的生命周期与三级缓存Bean生命周期是Spring面试的保留节目。我推荐的记忆框架是两条线容器管理线和扩展点线。容器管理线是实例化、属性填充、初始化、使用、销毁扩展点线是BeanNameAware、BeanFactoryAware、ApplicationContextAware这些Aware回调然后是BeanPostProcessor的postProcessBeforeInitialization、PostConstruct、InitializingBean的afterPropertiesSet、自定义initMethod最后是postProcessAfterInitialization。很多候选人分不清这些扩展点的顺序我建议记一个口诀式的顺序Aware回调 - before初始化 - PostConstruct - afterPropertiesSet - init-method - after初始化。接下来是被问得越来越多的循环依赖。为什么Spring能解决构造器注入之外的循环依赖因为它用了三级缓存一级缓存singletonObjects保存完整单例二级缓存earlySingletonObjects保存提前暴露的早期对象三级缓存singletonFactories保存创建对象的工厂。A依赖B、B依赖A时A先实例化但还没完成属性填充就把ObjectFactory放进三级缓存然后去填充属性发现需要B于是创建BB填充属性时发现需要A从三级缓存拿到A的早期引用B创建完成后再回填给A。这个机制能成立的前提是对象实例化已经完成所以构造器注入的循环依赖是解决不了的——这也是面试官最爱挖的坑因为你只要说Spring能解决循环依赖他立刻就会追问构造器注入的循环依赖能解决吗。还有一个值得提的点是二级缓存有没有可能省掉。理论上如果三级缓存里的ObjectFactory生成的代理对象可以直接回填那二级缓存看起来多余。但实际上代理对象的创建时机和暴露时机需要被控制二级缓存用来缓存已经显式暴露的早期对象确保同一个Bean只产生一个代理。这种源码层面的设计问题属于超纲题但如果候选人能接得住面试官会留下非常深的印象。5.2 AOP 动态代理与 JDK/CGLIB 的选择AOP的原理题其实就考代理。Spring AOP默认在运行时通过动态代理生成增强后的代理对象有两种方式JDK动态代理基于接口通过实现接口的方式生成代理类CGLIB基于继承通过生成目标类的子类来代理。Spring Boot 2.x及之后默认使用CGLIB因为随着时代变化很多场景类不再实现接口JDK代理就无能为力了。这里经常出现的追问是JDK动态代理和CGLIB有什么区别。可以从三方面答实现方式上JDK代理要求目标类至少实现一个接口CGLIB要求目标类不能被final修饰性能上CGLIB创建代理时因为要生成字节码开销略高但一旦创建完成方法调用的性能并不差使用限制上JDK代理只能代理接口方法CGLIB可以代理非final的公开方法。再往深一点可以提一句CGLIB基于ASM字节码生成技术这也是很多面试官想听到的词。AOP失效场景也是加分点同一个类内部方法自调用时走的不是代理对象而是this引用所以增强不生效。解决办法是注入自身代理对象或者把方法拆到另一个Bean里或者编程式调用代理。我实际在项目里遇到过事务不生效的问题最后定位到就是自调用导致的。面试的时候把这个真实案例讲出来比背十个失效场景都有说服力。还有一个常被问到的问题是AOP能拦截到private方法吗。答案是不能因为代理类通过继承或接口实现只能覆盖public方法private方法连子类都看不到。但更准确的说法是JDK动态代理根本不会包含private方法CGLIB虽然不是绝对不行但Spring的AOP设计上不会去代理private方法这一点从使用层面记住就够了。5.3 Spring 事务传播行为与失效场景事务相关的问题初级考传播行为中级考失效场景高级考底层原理。传播行为我按使用频率排个序REQUIRED是默认行为如果没有事务就新建有就加入REQUIRES_NEW永远新建一个独立事务外层事务不会影响它NESTED是嵌套事务基于保存点机制内层回滚不影响外层SUPPORTS是有事务就加入没有就以非事务方式执行其余几个MANDATORY、NOT_SUPPORTED、NEVER用到的场景极少理解概念即可。面试时把REQUIRED和REQUIRES_NEW的区别讲透再举一个实际场景就足够应付大部分问题了。事务失效是面试官真正想听的。常见的失效场景包括方法不是public的Spring AOP无法代理非public方法类内部自调用绕过代理方法内自己捕获了异常没有抛出去事务感知不到抛出的异常类型不对默认只回滚RuntimeException和Error受检异常不会触发回滚除非在rollbackFor里显式指定Bean没有被Spring管理比如new出来的对象数据库引擎不支持事务比如MySQL的MyISAM。把这些场景列全再配一个你在项目里实际踩过的例子这道题就很稳了。底层原理方面Transactional是基于AOP实现的本质上是对方法调用做了增强所以在事务执行期间拿到的connection是绑定在线程上的这又回到了ThreadLocal的考点。Spring的事务管理器会把数据库连接保存在ThreadLocal里保证同一个事务内多次操作用的是同一个连接因此事务的传播行为才能成立。一个并发题和一个框架题在这里奇妙地串起来了这也是面试官喜欢这种跨知识点追问的原因。6. 数据层必答题MySQL 索引失效与 Redis 缓存三兄弟到了中间件和数据层这一块面试题开始从背概念转向考经验因为这里的坑都是真实业务里踩出来的。连问几个问题就能看出候选人有没有真正优化过SQL、有没有处理过缓存问题还是只是看了几篇博客。6.1 索引失效场景与 EXPLAIN 实战MySQL索引的底层是B树这道题答得好不好直接决定面试官对你数据库功底的判断。标准答法B树是多路平衡查找树非叶子节点只存索引不存数据数据都挂在叶子节点并且叶子节点用链表串起来。相比B树B树的非叶子节点能存更多索引树更矮磁盘IO更少相比红黑树B树的扇出更大层数更低相比哈希索引B树天然有序支持范围和排序查询。这几种树的对比是面试官常要求的最好能自己画一遍再讲出来。然后是索引失效场景这个最常考也最实用。我把高频的整理成表格场景说明违反最左前缀原则联合索引(a,b,c)查询条件里没有a索引基本失效对索引列使用函数where date(create_time) ...索引列参与运算或函数后失效隐式类型转换索引是varchar查询条件用数字MySQL会做函数转换LIKE以通配符开头like %abc无法走索引like abc%可以OR连接非索引列优化器发现需要全表扫描才能满足条件时会放弃索引光背场景还不够面试官大概率会问你怎么定位慢SQL这时候要答EXPLAIN。重点看几个字段type从好到差至少知道const、ref、range、index、ALL这几种出现ALL说明是全表扫描需要警惕key实际使用的索引rows预估扫描行数Extra看到Using filesort和Using temporary基本是优化重点看到Using index说明命中了覆盖索引是加分项。我平时排查慢SQL的顺序就是先看rows再看type最后看Extra三个字段能定位大部分问题。这里再补充一个实际经验覆盖索引是解决排序和回表问题的利器。比如 select id, name from user where age 20 order by name如果有一个(age, name)的联合索引那么排序就可以直接用到索引不需要filesort。同样的道理select的字段尽量都在索引里就能避免回表这也是为什么大厂面试喜欢问覆盖索引的原因它直接关系到查询性能。6.2 Redis 穿透、击穿、雪崩的应对Redis的高频题里缓存穿透、缓存击穿、缓存雪崩这三兄弟必须分清楚很多候选人背串了。我提供一个记忆方法看病的位置。穿透是查询的数据在缓存和数据库里都不存在问题出在数据源头击穿是单个热点key在失效瞬间被打爆问题出在热点key雪崩是大量key同时失效问题出在批量过期。穿透的应对方式有三种缓存空结果并设置较短的过期时间布隆过滤器把所有可能存在的数据hash到一个bitmap里查不到直接返回还有一种偏实战的对恶意参数做参数校验把明显不合理的请求挡在入口。布隆过滤器有一个特点它说不存在一定不存在说存在可能误判所以适合用来拦截那些数据库中根本不存在的key把压力挡在缓存层之前。击穿和雪崩经常被搞混。击穿是某个热点key失效瞬间大量请求涌入常见应对是互斥锁重建缓存时只允许一个线程去查库其他的线程等锁或者返回兜底数据或者逻辑过期数据不过期但用额外的过期标记字段异步刷新。雪崩是大量key同时过期应对方式包括过期时间加随机数、热点数据不设置过期、多级缓存以及服务层面做限流降级。面试时我会追问互斥锁加锁后其他线程怎么办标准答案是其他线程等待一段时间后重新查缓存或者直接返回默认值而不是也在傻傻等锁释放。我面试时最看重的是候选人能不能说清楚这三者场景的区别以及有没有真正写过代码实现过其中一种方案。背概念的答案太容易被追问识破了。比如你说用互斥锁解决击穿我马上问锁的粒度怎么控制是用一个全局锁还是一把key维度的锁这里能答出分布式锁或者本地锁配合key维度设计的人说明是真的在项目里写过。6.3 Redis 分布式锁的实现与问题分布式锁是Java中高级面试的高频题因为它涉及Redis、并发和工程权衡。基础版答案是用SETNX加锁设置过期时间防止锁忘记释放用UUID作为value标识持有者释放时先判断是不是自己再删用Lua脚本保证判断加删除的原子性。这个答案能覆盖加锁、过期、释放、防误删四个基本要素已经超过很多人了。进阶问题随之而来如果业务执行时间超过锁过期时间怎么办这就引出了Redisson看门狗机制它会在锁快过期时自动续期默认看门狗的续期时间是锁超时时间的三分之一。更进阶的问题是RedLock它要求在多个独立的Redis节点上加锁超过半数成功才算获取成功用来解决主从切换导致的锁丢失问题。不过RedLock在业界一直有争议有的大牛认为它在分布式环境下依然不是绝对安全的还专门写过文章分析它的痛点。面试中如果被问到建议如实说出它的思路和争议点这比盲目背书要显得可信得多。还有一个容易忽略的点是锁的粒度。很多人一上来就用一个全局锁锁住所有订单操作其实分布式锁最理想的设计是尽量把锁的粒度缩小到具体资源上比如key设计成lock:order:userId:orderId这种细粒度形式。这样能最大化并发能力而不是把系统串行化。这其实是考察候选人有没有真实的设计经验而不是只会说用Redisson做分布式锁。7. 从背题到会答面试官真正想听的答题框架把高频题过了一遍之后最后想聊的是怎么答这件事。同一道题不同的人回答给面试官的观感可能天差地别。这一章既是总结也是方法是我自己从面试和复盘里沉淀下来的经验。7.1 回答技术题的三段式结构我自己面试时比较欣赏的回答结构是结论先行、原理展开、场景收尾。先说结论比如HashMap底层是数组加链表JDK 8之后加了红黑树让面试官知道你清楚核心然后展开原理讲扰动函数、扩容、树化条件展示深度最后落到场景比如我上次线上遇到一个频繁扩容的问题后来通过设置初始容量解决了。这样一条答案下来深度和实战都有了。还有一个技巧是学会主动抛出可追问的点。你在回答中埋几个细节面试官顺着追问你又能答出来整个面试就会往你熟悉的方向走。比如回答ThreadLocal时主动提一句在线程池里要特别注意remove面试官大概率会顺着问为什么这就是你准备好的射程。反过来不要一次性把所有东西都倒出来那样反而显得像在背课文。有节奏、有留白面试官才有参与感沟通才会顺畅。关于篇幅控制我的经验是一个核心问题的完整回答控制在两到三分钟比较合适。太短显得内容单薄太长面试官容易失去耐心。两分钟大概能讲清楚结论加一个原理层次如果面试官有兴趣自然会追问追问就是你展示深度的时候。7.2 遇到不会的题怎么处理没人能答对所有题遇到不会的怎么办我见过最差的做法是硬编现场瞎扯这比直接说不会扣分更多因为面试官很快就能核实。相对好的做法是分三步先坦诚这块我了解得不多然后说出你知道的相关部分把话题拉到你熟悉的领域最后表明如果给我一点时间我可以基于已有经验给出分析思路。比如被问到一种你没用过的中间件你可以说这个中间件我没实际用过但我了解分布式的通用问题比如一致性和可用性的权衡您能告诉我它在这个场景下主要解决什么问题吗。大多数面试官愿意接受这种回应因为真实的业务里没有人是万能的。还有一点容易被忽略面试也是一次学习机会。遇到不会的题记下来面试结束后马上去查。我见过很多候选人面试完就完事了白白浪费了一次收集真实考题和知识盲区的机会。我自己的习惯是每次面试后花半小时复盘把没答上的题整理进文档标注当时的卡壳点下一次面试前重点复习。这样做几轮之后你的盲区会越来越小。7.3 怎么让八股文成为持续迭代的知识库回到标题里持续更新四个字。我的做法是每次面试结束或看到一条高质量的面经后把题目按主题分类记到一个文档里每个题目包含三部分标准答案、我的理解、实际踩过的坑。查漏补缺的时候重点看我的理解和实际踩过的坑这两栏因为标准答案到处都能搜到真正有价值的是你自己的思考。学习顺序上我建议先把基础打牢再往框架和中间件扩展。Java基础、并发、JVM这三个是根Spring和MySQL/Redis是主干分布式和微服务是枝叶。网上有很多学习路线图但最终检验标准只有一个你能不能不看资料把每个知识点的原理讲给一个初学者听。讲不明白的地方就是你要回去补的地方。我常用的方法是给自己录语音讲一遍或者用费曼学习法假装在教别人讲着讲着就知道哪里卡壳了。最后分享一个我个人的习惯技术问答背一百遍不如自己动手跑一遍。遇到不确定的结论比如HashMap树化的阈值、synchronized锁升级的条件写个demo验证一下或者用JFR、Arthas这些工具到真实环境里看一眼印象会深刻得多。八股文的终点不是背完所有的题而是当你再也不用背的时候自然就过了。