把“Java八股文”四个字说出口很多人的脸上都会浮出一种既恨又爱的表情。恨的是面试前背得昏天黑地爱的是背熟之后面试现场确实顺风顺水。我做Java开发这些年面过别人也被别人面过最大的体会是八股文不是单纯考记忆而是面试官拿来探测你知识体系深度的探针。这篇2026版Java面试八股文整理我把近几年高频出现的考点、标准答案、以及藏在答案背后的“为什么”都按自己的经验重写了一遍覆盖Java基础、JVM、并发、Spring、环境报错五大块适合准备校招和社招的Java开发尤其是1到3年经验、想系统性补基础的朋友。很多读者问过我面试八股文到底该背多细我的回答一直是先背高频再追底层最后一定要用自己的话讲出来。只背结论面试官多追问一层就露馅只追底层复习成本又太高。这篇文章就是按这个平衡点来写的每一段都能直接拿来当面试回答的底稿。1. 先搞清楚Java面试考什么再决定怎么背1.1 八股文是面试官探测知识体系的“探针”如果你以为面试官问HashMap就是想听“数组加链表加红黑树”这一句话那理解的层次就太浅了。面试官问HashMap通常是从底层结构开始一路追问什么时候链表转红黑树为什么阈值是8为什么容量是2的幂次负载因子为什么是0.75多线程环境下会有什么问题这一连串问题真正想看的不是你背了多少而是你有没有建立“一个知识点牵出一张知识网”的能力。这也是为什么我推荐用“关键词发散法”来复习八股文每看到一个高频考点不要只记标准答案逼着自己回答三个问题——它是什么、它为什么这么设计、它在实际项目中帮我解决过什么问题。比如看到volatile不能只答“可见性和禁止指令重排”还要能说出“双检锁单例为什么要加volatile因为new对象不是原子操作可能拿到半初始化对象”这种实际场景。面试说到底是一场“对方在探测你的知识边界”的对话。你回答得越有层次对方就越愿意往你熟悉的方向继续聊。反过来如果你只会背结论面试官随便换个角度问就会变成大型尴尬现场。所以我在这篇文章里每个考点都尽量把“结论 原因 场景”三层信息一起写进去。1.2 2026年Java面试的范围变化与复习节奏先说变化。2026年的主流生产环境已经从JDK8迁移到了JDK17甚至JDK21很多公司新项目直接要求LTS版本起步。这意味着面试中会出现一些“新八股”record类、switch表达式、文本块、虚拟线程Virtual Threads、ZGC等。但核心基础考点的地位没有变集合、并发、JVM、Spring依然是必问的内容。新特性更多是作为加分项面试官不会因为你没答上虚拟线程的原理就挂掉你但如果你能随口说出“JDK21的虚拟线程是基于ForkJoinPool的调度实现”这种层次印象分会提高不少。面试分层也很明显校招和初中级岗位更看重基础扎实度高频考点就是集合、并发、JVM、MySQL、Spring这些3年以上经验的岗位八股占比会下降项目深挖和系统设计占比上来但八股依然是敲门砖因为面试官需要快速确认你的技术底线。复习节奏上我给一个参考方案基础知识点花3天集合、异常、泛型、面向对象JVM花2天内存区域、GC、类加载、OOM排查并发花2天锁、线程池、AQS、CASSpring花2天生命周期、AOP、事务项目复盘花3天把自己做过的项目按“背景、方案、难点、结果”四段整理一遍。每天保持至少2小时的有效学习时间别追求一天看十几个知识点效果很差。宁可一个知识点吃透也不要囫囵吞枣过十遍。2. Java基础高频考点别让基础题变成丢分题2.1 面向对象三特性封装、继承、多态要答出层次面向对象是Java面试开场最常见的题目但很多人答得太平淡。封装、继承、多态这三个词谁都会说关键是能不能把这个答案说得有血有肉。封装本质是“隐藏实现细节暴露稳定接口”。这句话背后的工程意义是降低耦合、提高安全性。举个例子你写了一个用户类字段都是private对外只提供getter/setter这样以后内部逻辑改了外部调用方不受影响。这就是封装的价值而不只是一个语法层面的访问修饰符。继承关系是is-a核心是复用和扩展。但面试时如果只答“子类复用父类代码”是不够的最好补上一句“继承要谨慎使用因为继承会破坏封装父类的实现细节会暴露给子类而且耦合度很高。面向对象领域更推荐组合优先于继承”。这句话一出来面试官通常会认为你有工程经验而不只是背概念。多态分为编译时多态方法重载和运行时多态方法重写。运行时多态底层依赖动态绑定JVM在运行时根据对象的实际类型来决定调用哪一个方法而不是根据引用变量的声明类型。面试官经常追问一个经典例子父类引用指向子类对象调用一个子类重写的方法发生的是编译期还是运行期绑定答案是运行期绑定这也正是多态能够实现的核心机制。答到这里这个题目基本就过关了。2.2 集合框架HashMap、ArrayList、LinkedList的底层取舍集合框架是Java面试的“必考大户”HashMap又是重中之重。把HashMap讲透基本上可以串起一半Java基础面试题。HashMap在JDK1.8之后的底层是“数组 链表 红黑树”。put一个键值对时先通过hash算法算出在数组中的下标如果该位置没有元素就直接放入如果有元素就挂到链表后面当链表长度超过阈值8且数组容量大于等于64时链表会转成红黑树把查询时间复杂度从O(n)降到O(log n)。为什么阈值取8因为源码作者基于泊松分布计算过在负载因子0.75的情况下链表长度达到8的概率只有千万分之六绝大多数场景链表都很短不需要转树。为什么容量必须是2的幂次方因为计算数组下标用的是hash (n - 1)只有当n是2的幂次时n-1的低位全是1这个位运算才能等价于取模而且比取模更快。负载因子为什么是0.75这是空间和时间成本的折中。负载因子越大空间利用率越高但冲突概率也变大0.75是经过实验验证的较优平衡点。JDK1.7到1.8最大的变化之一是头插法改成了尾插法。头插法在并发扩容时会形成环形链表导致get操作死循环JDK1.8改成尾插法后这个问题从根本上被避免了但HashMap在多线程下依然不安全因为put操作可能导致数据覆盖。这就是为什么不建议在多线程场景使用HashMap而要用ConcurrentHashMap。ArrayList和LinkedList的差异也常被问到。ArrayList底层是Object数组默认容量是10扩容时按1.5倍增长新容量 旧容量 旧容量右移一位随机访问很快时间复杂度O(1)。LinkedList底层是双向链表适合频繁在头部或中间插入删除数据但真正做“按索引插入”时它还是要先遍历找到位置所以实际用起来性能未必比ArrayList好。我的习惯是95%的列表场景都用ArrayListLinkedList在面试题里出现频率远高于实际项目。2.3 equals与hashCode、String的不可变性、字符串拼接细节这是一个看起来简单、实际上坑很多的组合题。比较的是引用地址equals默认比较的也是引用地址但String类重写了equals改成比较字符内容。所以new String(a) new String(a)是falsenew String(a).equals(new String(a))是true。为什么重写equals必须重写hashCode因为HashMap、HashSet这类集合先用hashCode定位桶再用equals比较桶内元素。如果你只重写equals不重写hashCode两个内容相同的对象会得到不同的hashCode被放到不同的桶里HashSet就会把它们当成两个元素存进去。这违反了“相同对象必须拥有相同hashCode”的约定。String被设计成不可变类一直是高频追问点。不可变的好处至少有四个第一线程安全多个线程可以安全地共享同一个String对象第二支持字符串常量池相同内容的字符串可以复用堆内存节省资源第三hashCode可以缓存String对象第一次计算hashCode后就存下来了后续直接返回这也是String适合做HashMap key的原因第四安全类加载、网络传输等场景不会因为字符串内容被意外修改而出问题。字符串拼接也是面试官爱考的细节。单线程环境用StringBuilder多线程环境用StringBuffer它的方法加了synchronized。为什么不用String的“”拼接因为一旦超过几个字符串编译器虽然会优化成StringBuilder但在循环里反复拼接会反复创建StringBuilder对象效率很低。建议循环拼接的时候自己显式创建StringBuilder这是代码review时经常看到的优化点。2.4 Lambda、枚举、泛型和类关系容易被忽略的送分题Lambda在Java面试中很少单独出道大题但它嵌套在很多框架源码理解里。Lambda表达式的本质是函数式接口的实例。函数式接口就是只有一个抽象方法的接口比如Runnable、Comparator、Function。很多人以为Lambda是匿名内部类的语法糖这个说法并不严谨因为匿名内部类会生成独立的class文件而Lambda的底层实现是invokedynamic指令性能更好更省内存。枚举在面试中常被问“能不能用枚举实现单例”。答案是可以枚举本质是继承了Enum类的final class构造器私有天生线程安全还能防止反序列化破坏单例。这也是《Effective Java》推荐的单例实现方式之一。枚举还能携带字段和方法比普通常量类好用得多。泛型的核心考点是类型擦除。Java泛型只在编译期生效运行期会被擦除成原始类型。所以ListString和ListInteger在JVM眼里其实都是List它们的Class对象是同一个。这带来一个常见问题无法用instanceof判断一个list到底是String类型还是Integer类型。泛型还涉及协变与逆变面试中如果对方问到List? extends T和List? super T这就是进阶的加分考点生产环境里主要用于方法参数的只读/只写约束。类之间的关系也是基础面试题里容易忽略的部分。UML中常见五种关系依赖、关联、聚合、组合、继承。聚合和组合容易混淆聚合是has-a整体和部分可以分离比如班级和学生学生可以换班级组合是contains-a整体和部分不可分离比如人和心脏心脏没法独立于人存在。理解这些关系不只是为了答题写代码时判断该用继承还是组合、该不该暴露引用都从这里来。3. JVM内存与OOM排查面试分水岭和线上救火必备3.1 内存区域划分堆、栈、方法区、直接内存JVM内存区域可以说是一道明显的分水岭答得好面试官会默认你具备排查线上问题的基本能力答得含糊前面的基础分也会打折扣。先说线程共享的内存堆和方法区。堆Heap是Java对象的主要存储区几乎所有new出来的对象都存在这里。堆内存内部进一步划分成新生代Eden、Survivor From、Survivor To和老年代比例通常通过参数调整。方法区在JDK8之前叫永久代JDK8之后被替换成元空间Metaspace存放类元信息、常量、静态变量等。元空间使用的是本地内存不再占用堆内存所以默认大小只受本机物理内存限制。线程私有的内存包括虚拟机栈、本地方法栈和程序计数器。虚拟机栈对应Java方法执行每个方法被调用时JVM都会创建一个栈帧里面存储局部变量表、操作数栈、动态链接、方法出口。栈帧过大或者递归过深就会抛出StackOverflowError。程序计数器用来记录当前线程执行到哪条字节码指令线程切换后能恢复状态。本地方法栈是为native方法服务的。直接内存Direct Memory不是JVM运行时数据区的一部分但经常被提起因为NIO使用堆外内存可以通过参数-XX:MaxDirectMemorySize来控制上限。直接内存的优点是减少堆内数据拷贝提升IO性能缺点是如果忘记显式释放通常通过Unsafe或DirectByteBuffer内部的Cleaner容易造成本机内存耗尽。面试中主动提到直接内存往往能体现你真的做过高性能网络编程。一个常考的追问是一个Java字符串、一个int、一个对象引用分别存在哪里这个得拆开说int这种基本类型如果它是方法内的局部变量存在虚拟机栈的局部变量表如果它是实例字段存在堆里的对象内部。String对象本身存在堆里但字符串字面量在JDK8之后存放在堆中的字符串常量池里JDK7之前是放在方法区/永久代。对象引用如果是局部变量存在栈里如果是成员变量存在堆里的对象头里。3.2 类加载过程与双亲委派模型类加载机制是JVM模块的核心题目。类从被加载到卸载生命周期包括加载、验证、准备、解析、初始化、使用、卸载七个阶段。面试主要考前五个阶段。加载阶段JVM通过类的全限定名获取二进制字节流并将字节流代表的静态存储结构转换为方法区的运行时数据结构然后在堆中生成Class对象。验证阶段会做文件格式验证、元数据验证、字节码验证、符号引用验证防止恶意字节码破坏JVM。准备阶段为类变量分配内存并设置默认值这一步真正开始分配内存但注意这时候的赋值是默认值比如int是0对象是null代码里写的“显式赋值”要到初始化阶段才会执行。解析阶段把常量池里的符号引用替换为直接引用。初始化阶段才真正执行类构造器clinit方法执行静态变量的显式赋值和静态代码块。双亲委派模型也经常考。它的工作流程是一个类加载器收到类加载请求后先不自己加载而是把请求委派给父类加载器逐级向上直到最顶层的启动类加载器。只有父加载器反馈无法完成加载时子加载器才自己尝试加载。这样做最大的好处有两个防止核心API被篡改比如你写一个java.lang.String由于加载String时被委派给启动类加载器JVM加载的还是JDK自带的String安全性有保障二是避免类重复加载父子加载器加载过同一个类子加载器就不必再加载一次。双亲委派也不是铁板一块。JDBC里的ServiceLoader、Tomcat容器、热部署框架都需要打破双亲委派。很多公司面试喜欢问“为什么要打破双亲委派”核心答案就是基础类是由启动类加载器加载的但基础类可能需要调用用户代码比如JDBC的DriverManager要调用各个数据库厂商的实现类只能通过线程上下文类加载器来让父加载器反向委托给子加载器。能把这一点讲清楚说明你对类加载机制不是死记硬背。3.3 GC算法与常见收集器不用背通篇抓住关键差异垃圾回收是JVM面试的重头戏但不建议把各种收集器的细节全背下来那样效率太低而且面试官也未必能问到那么细。关键是掌握两条主线判死逻辑和回收算法。判断对象是否存活目前主流是可达性分析算法。从一组称为GC Roots的对象出发沿着引用链向下搜索不可达的对象就是可以被回收的。GC Roots包括虚拟机栈中引用的对象、方法区中静态属性引用的对象、常量引用的对象、本地方法栈中JNI引用的对象。早期还有引用计数算法但因为循环引用问题已经被主流JVM抛弃这个可以作为知识背景提一句。常见的回收算法就三种对比着记标记-清除算法最基础先标记出垃圾对象再统一清除缺点是产生大量内存碎片后续分配大对象容易触发再次GC标记-复制算法把内存分成两块只用其中一块回收时把存活对象复制到另一块然后清空整块代价是浪费一半空间新生代由于存活对象少适合用这种算法标记-整理算法在标记后把存活对象向一端移动再清理掉边界以外的区域不再有碎片但移动对象成本较高老年代存活率高适合用这种算法。收集器这部分重点讲三四个就够了。Parallel Scavenge关注高吞吐量适合后台计算任务CMS并发标记清除是最早以“最短停顿”为目标的收集器它实现了并发收集但会带来碎片问题G1是JDK9之后的服务端默认收集器它把堆划分为一个个Region跟踪每个Region的垃圾堆积价值优先回收价值最大的Region停顿时间可预测到JDK21ZGC已经成为低延迟场景的明星它基于着色指针和读屏障能让停顿时间控制在几毫秒甚至更低。回答时把G1和ZGC按“目标是什么、核心思路是什么”讲清楚已经超过大部分候选人了。3.4 OOM的常见类型和排查思路热词里有一条“java: outofmemoryerror: insufficient memory”这其实是JVM报错里最常见也最让人头疼的一类。面试官问OOM通常不是在问定义而是想看你怎么排查。先背熟几种常见的OOM类型。第一种java.lang.OutOfMemoryError: Java heap space堆内存不足一般是因为对象太多或者存在内存泄漏比如缓存只增不减、大集合没有被释放。第二种GC overhead limit exceededGC一直在执行但回收效果很差JVM判断已经“救不回来”了于是主动抛出这个异常本质还是堆空间不够。第三种unable to create new native thread操作系统的线程数被耗尽通常是线程被无限制创建排查时要同时看应用层线程池和操作系统的ulimit限制。第四种Metaspace溢出元空间里的类元数据太多典型场景是运行时不断生成代理类或者CGLIB类。排查思路按四步走第一步启动参数加上-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath路径让JVM在OOM时自动导出一份堆转储文件第二步用MAT或者VisualVM打开堆转储先看占用最大的对象再看引用链找出“谁在一直持有这些对象”第三步区分到底是内存泄漏还是单纯内存溢出。泄漏的特征是GC后内存占用依然持续升高溢出的特征是一次大请求直接把内存打爆第四步调整参数或者修复代码。如果要修复代码重点排查全局缓存、静态集合、连接池未释放这些常见泄漏点。这里补充一条实战经验JVM参数里的Xmx不要盲目调大尤其是服务器内存有限的情况下调大堆内存反而可能触发操作系统的内存交换导致GC停顿更长。我见过很多团队遇到OOM第一反应就是加内存结果问题依旧最后发现是有个本地缓存Map没有设置淘汰策略数据量一上来就爆。先查代码再调参数才是正确顺序。4. 并发编程高频题synchronized、volatile、线程池一次说透4.1 并发三大特性与volatile并发编程出现的频率在Java面试里数一数二。要理解它先要把并发三大特性背清楚原子性、可见性、有序性。原子性是指一个操作要么全部执行要么全部不执行中间不能被线程调度打断。可见性是指一个线程修改了共享变量后其他线程要能立刻看到这个修改。有序性是指程序执行顺序要按代码逻辑来但由于编译器和CPU为了优化可能重排指令实际执行顺序可能不同。这三种问题处理不好就会出现各种诡异的并发bug。volatile关键字是解决可见性和有序性的利器。它有两个核心语义保证volatile修饰的变量对所有线程的可见性一个线程修改后其他线程立即可见禁止指令重排序JMM会在volatile变量的读写前后插入内存屏障。但volatile不保证原子性比如count这种“读-改-写”操作即使count被volatile修饰并发下依然会丢数据因为volatile管不了多条指令之间的中断。面试官最喜欢问volatile的场景是双检锁单例。为什么instance字段除了加volatile之外还要加volatile因为instance new Singleton()在字节码层面不是原子操作它会经历三个步骤分配内存、初始化对象、将引用指向内存。如果这三个步骤被重排成“分配内存、将引用指向内存、初始化对象”线程A执行到第二步时线程B判断instance已经不为null就直接返回了一个还没有初始化完成的对象于是调用对象方法时就会空指针。加上volatile之后禁止了指令重排这个问题就解决了。这个例子建议你能自己完整地讲一遍非常加印象分。4.2 synchronized的锁升级与Lock的选择synchronized从JDK6之后引入了锁升级机制性能已经大不一样。锁升级的路径是无锁 - 偏向锁 - 轻量级锁 - 重量级锁。偏向锁只有一个线程竞争锁时锁会偏向这个线程记录线程ID后续该线程再次获取锁时几乎不需要任何同步开销。轻度竞争时如果另一个线程也来抢锁偏向锁会撤销并升级为轻量级锁。轻量级锁多个线程交替进入临界区竞争并不激烈通过CAS自旋来获取锁避免线程阻塞切换如果自旋超过一定次数或者竞争加剧就升级为重量级锁。重量级锁依赖操作系统的互斥量Monitor实现获取不到锁的线程会进入阻塞状态涉及用户态和内核态切换开销最大。JDK15开始偏向锁被逐步废弃JDK18中默认禁用这个细节如果答上会显得你一直在跟进新版本。那synchronized和Lock接口怎么选synchronized的使用更简单Java语言层面自带出现异常时JVM会自动释放锁Lock需要手动lock/unlock通常要配合try-finally使用。Lock的优势是支持超时获取锁tryLock、支持中断响应、支持公平锁、可以创建多个条件队列Condition在复杂的并发场景下更灵活。日常代码里能用synchronized就用synchronized简单、可靠、可读性好只有需要超时或公平策略时再考虑ReentrantLock。4.3 CAS与AQS理解JUC的底层逻辑如果只背synchronized和volatile并发这块只能算及格。想再进一步要把CAS和AQS这两个底层机制讲清楚。CAS全称Compare And Swap是一种无锁算法。它的操作逻辑是比较内存中的值是否等于预期值如果相等就更新成新值如果不相等就重新读取再试。CAS是一种乐观锁思想不需要加锁靠的是CPU原子指令支持。在Java里AtomicInteger、ConcurrentHashMap、LongAdder的底层都用到了CAS。CAS有个经典问题叫ABA问题线程A读到值是1线程B把值改成2又改回1线程A再来执行CAS时发现值还是1就认为没有变化继续操作但实际上这个值已经被动过了。解决方式是加版本号比如AtomicStampedReference每次修改都附带一个版本戳就可以发现“被改过”的情况。AQS是AbstractQueuedSynchronizer的缩写它是几乎整个JUC并发包的基石。AQS维护了一个volatile的state变量和一个FIFO双向等待队列。ReentrantLock、CountDownLatch、Semaphore的核心逻辑都是在AQS上封装出来的。以ReentrantLock为例它的state表示锁被重入的次数持有锁的线程在state上做累加获取不到锁的线程进入等待队列被同步阻塞。面试时说清楚“state表示状态队列表示等待者”AQS这题基本就够了。4.4 线程池参数、流程、拒绝策略、核心线程数设置线程池在Java并发面试中的出现频率极高因为它既考基础又考实际应用。先背清楚线程池的七个核心参数核心线程数即使空闲也保留的线程数量。最大线程数线程池允许创建的最大线程数量。空闲存活时间线程数超过核心线程数时多余线程空闲多久后被回收。时间单位存活时间的单位。工作队列存放等待执行的任务比如LinkedBlockingQueue、ArrayBlockingQueue、SynchronousQueue。线程工厂创建新线程的工厂建议设置有意义的名字便于排查。拒绝策略队列和最大线程数都满了时新任务怎么处理。任务执行的完整流程是提交任务后如果当前线程数小于核心线程数创建新线程执行如果等于核心线程数任务进入工作队列如果队列也满了且线程数还能继续增加就创建新线程直到最大线程数如果线程数已经到最大值队列也满了就触发拒绝策略。四种拒绝策略要能区分AbortPolicy默认策略直接抛RejectedExecutionExceptionCallerRunsPolicy不丢弃任务也不抛异常而是让提交任务的调用者线程自己执行这个任务起到背压作用DiscardPolicy静默丢弃任务DiscardOldestPolicy丢弃队列里最老的任务再尝试提交新任务。核心线程数怎么设置是面试里最常追问的实战题。CPU密集型任务设置成CPU核数1比较合理因为每个线程都占着CPU跑多了反而增加切换开销。IO密集型任务线程大部分时间在等待IO可以设置成CPU核数*2或者用公式最佳线程数 CPU核数 * (1 线程等待时间 / 线程计算时间)。实际项目里我一般先按“CPU密集型 核数 1IO密集型 核数 * 2”起步再用压测调整。最后一定要会“吐槽Executors工具类”。Executors.newFixedThreadPool用的是无界队列队列无限堆积时会撑爆内存Executors.newCachedThreadPool最大线程数是Integer.MAX_VALUE任务多时会创建海量线程导致资源耗尽。所以正规团队都约定线程池要手动通过ThreadPoolExecutor创建参数可视化配置方便调优。这个点几乎是面试必考一定要说。5. Spring核心考点生命周期、AOP与事务失效5.1 Bean生命周期面试爱问、源码里也绕不开Spring框架在Java后端面试里的地位不用多说Bean生命周期又是Spring最经典的考点。很多人把生命周期背得很长结果现场一紧张就忘。其实只要抓住四个主阶段再向里补充细节就不会乱。四个主阶段是实例化 - 属性填充 - 初始化 - 销毁。实例化就是通过构造器或工厂方法创建Bean对象。属性填充就是把配置文件里或注解里定义的依赖注入进去对应Autowired、Resource的处理。初始化阶段会调用各种回调BeanNameAware、BeanFactoryAware、ApplicationContextAware等Aware接口BeanPostProcessor的before和after方法以及PostConstruct注解标记的方法或者初始化回调方法。销毁阶段则执行PreDestroy注解方法或者destroy-method。回答时如果能把BeanPostProcessor单独拎出来讲会很加分。因为AOP的动态代理就是通过BeanPostProcessor在初始化阶段后置插手实现的常见的是AbstractAutoProxyCreatorSpring找到需要被代理的Bean之后在这里返回代理对象而不是原始对象。这说明一个知识点Spring AOP不只是“切面表达式的配置”它是在Bean生命周期中通过后置处理器把目标Bean替换成代理Bean的过程。5.2 AOP代理机制JDK动态代理与CGLIBSpring AOP底层依赖代理模式具体有两种实现方式JDK动态代理和CGLIB。JDK动态代理要求目标类必须实现至少一个接口它在运行时通过Proxy.newProxyInstance生成一个实现同样接口的代理类所有方法调用都会经过InvocationHandler的invoke方法在真正执行目标方法之前或之后插入切面逻辑。CGLIB则不需要接口它通过生成目标类的子类来实现代理在子类中重写父类方法所以目标类不能被final修饰方法也不能是final。Spring Boot 2.x 之后的默认行为是使用CGLIB而不是JDK动态代理。原因是很多情况下业务类没有设计接口Spring Boot为了开箱即用把spring.aop.proxy-target-class默认改为true。这个变化面试中很常考记住它。AOP的一个高频坑是自调用失效。如果类内部通过this.methodA()调用同类里的Transactional方法事务会失效。因为this拿到的是原始对象不是Spring容器里的代理对象事务切面根本没有机会拦截。解决方法是注入自己的代理对象或者把方法拆分到另一个Bean里。这种“事务失效 自调用”组合题面试现场能主动讲出来的人不多属于性价比很高的加分点。5.3 事务失效的几种典型场景Spring事务失效是很多初级程序员线上事故的根源也是面试官很爱挖的题。第一种方法内部自调用。也就是上面说的同一个类中一个方法调用另一个带Transactional的方法事务切面无法生效。第二种方法或类不是public的。Spring声明式事务默认使用CGLIB或JDK代理private和protected方法无法被代理事务直接失效。这就是为什么规范要求Transactional只能放在public方法上。第三种异常被吞了。Transactional默认只回滚RuntimeException和Error如果业务代码里catch住了异常没有继续往外抛事务就不会回滚。如果想修改回滚策略需要手动指定rollbackFor Exception.class并且把异常重新抛出。第四种数据库不支持事务。比如MySQL的MyISAM引擎就不支持事务InnoDB才支持。这个问题比较冷门但答出来会显得你底层功底扎实。第五种传播行为或隔离级别设置不当。比如REQUIRES_NEW会挂起当前事务并开启新事务内层事务回滚不会影响外层NOT_SUPPORTED会挂起当前事务以非事务方式执行。如果对这个概念不熟很容易在写分布式事务逻辑时出错。这几种场景我建议整理成自己的话面试时按“场景 - 原因 - 解决方案”讲。比如自调用失效先说场景“一个方法在类内部通过this调用另一个Transactional方法”再说原因“this是原始对象不走代理”最后说方案“把调用拆到另一个Bean或者通过代理对象调用”。这样讲逻辑清清楚楚。6. 新手最容易踩的JDK环境与编译报错6.1 环境变量配置JAVA_HOME、PATH与版本验证很多新手在准备面试题之前先被本地的环境配置劝退了。Java开发环境问题虽然不算严格意义的“八股”但热词里堆了大量环境变量、编译报错相关搜索说明这是群体性痛点。配置JDK环境变量核心思路就两点设置JAVA_HOME把JDK安装目录交给系统把JDK的bin目录加入PATH让命令行能定位到 java 和 javac 命令。Windows上的操作是新建系统变量JAVA_HOME值填JDK安装路径比如C:\Program Files\Java\jdk-17再编辑PATH新增一项%JAVA_HOME%\bin。Linux/macOS上则在/etc/profile或~/.bashrc里加上export JAVA_HOME/usr/local/jdk-17和export PATH$JAVA_HOME/bin:$PATH然后source一下。配置完成后命令行执行java -version能显示版本信息就说明成功了。顺便提一句CLASSPATH现在基本不需要手动配置了。JDK9之后模块化加上IDE普遍管理依赖老教程里让配CLASSPATH的做法已经过时盯着这点配置反而容易踩坑。6.2 “源发行版17需要目标发行版17”到底在说什么热词里有一条是“java: 警告: 源发行版 17 需要目标发行版 17”。翻译成人话就是代码是用Java 17的语法写的但当前编译环境用的目标版本target不是17导致编译时无法确定该怎么生成字节码。最常见的触发场景是本机装了JDK 17IDE里也选了JDK 17但是Maven的pom.xml里没有配置maven.compiler.source和maven.compiler.target结果Maven用了默认的Java版本源版本和目标版本不一致就会报这个警告严重时直接编译失败。解决办法分三步确认本机的JDK版本java -version在IDE的Project Structure里把Project SDK设为17Language Level也设为17在pom.xml里加上插件配置properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target /properties也可以用maven-compiler-plugin精确指定但properties的写法更简洁实际项目中我用得最多。如果这还不行十有八九是IDE进程没重启重启之后再重新build一次就好了。6.3 Lombok报错与注解处理问题热词里有一条Lombok的经典报错“you arent using a compiler supported by lombok”。这里的根因通常是Lombok版本太老不支持当前版本的JDK。Lombok是通过注解处理器在编译期修改抽象语法树来实现“自动生成getter/setter”的JDK每次大版本更新编译器内部API一变老版本Lombok就会失效。解决办法不复杂把Lombok升级到支持当前JDK的版本。比如JDK17至少使用Lombok 1.18.20以上JDK21建议使用1.18.30以上。另外检查IDE里是否启用了Annotation Processing注解处理IDEA里在Settings - Build - Compiler - Annotation Processors里勾选Enable annotation processing。这个开关如果没开Lombok会处于“看起来加了依赖但不起作用”的尴尬状态。还有一种情况是IDE内置编译器版本和项目JDK不一致比如IDE用的内置编译器是Java 8但项目是Java 17Lombok也可能报错。检查Maven项目里pom.xml的lombok版本和IDE的SDK把两边统一到同一套JDK上问题基本就消失了。这种环境类报错我在实际工作中遇到不下十次几乎全是版本不匹配不是Lombok本身的BUG。6.4 VSCode乱码与编译期“internal error”的排查热词里的“vscode运行java报错乱码”和“java: internal error in the mapping processor”都是IDE相关的典型问题。VSCode跑Java输出中文乱码的原因通常是控制台终端编码与控制台字符集不一致。Windows上默认GBK项目文件是UTF-8一旦读取中文就得错乱。解决方法是把终端编码改成UTF-8或者反过来统一项目文件编码。在.vscode/launch.json里给Java程序加上console: internalConsole选项并调整encoding: UTF-8更通用的做法是在VSCode设置里搜索“files.encoding”把文件编码设置为UTF-8。“internal error in the mapping processor: java.lang.nullpointerexception”这种诡异错误多半发生在使用MapStruct或Lombok组合的项目里。mapping processor指的是MapStruct的注解处理器当MapStruct版本、Lombok版本、JDK版本三者不兼容时内部处理映射方法时会抛NullPointerException。排查思路很直接先升级MapStruct到最新版本检查Lombok版本是否匹配JDK在Maven里执行mvn clean后重新编译排除掉旧的编译缓存。这类错误报错信息看着吓人但绝大部分是版本冲突不要被长长的异常栈吓到抓前两行就能定位。6.5 构建工具和IDE版本不统一引发的问题环境问题里最后一大类是构建工具和IDE版本不一致。最常见的是项目里pom.xml指定了maven.compiler.source17但IDE里默认SDK是JDK8或者IDE内置的Maven版本过旧导致编译行为和在命令行用Maven编译结果不一样。我的排查习惯是先在命令行跑一次mvn clean compile -DskipTests看能不能通过。命令行能通过而IDE报错那问题在IDE配置命令行也报错问题在项目的Maven配置或依赖本身。这条“二分定位”的思路可以解决一大半环境问题。如果项目里多个模块用了不同Java版本还可以在父pom里统一设置java.version属性配合Spring Boot的maven.compiler.source/target保持一致。还有就是本机装了多个JDK版本时要特别注意PATH和JAVA_HOME指向的是哪一个。我见过一个朋友下载了JDK21但PATH里依然是JDK8的路径命令行执行java -version显示8IDE却能跑到21最后花了一个小时排查版本错乱。强烈建议在命令行先用where java或which java确认实际生效的路径再看JAVA_HOME环境变量两步就能把版本问题理清。7. 复习优先级与表达训练面试前的最后一步7.1 从高频到低频把有限时间花在刀刃上八股文复习最怕“什么都想背什么都背不精”。我给身边朋友的建议是按优先级把内容分三层。第一优先级几乎必考点集合HashMap、ArrayList、HashSet、并发线程池、synchronized、volatile、锁、JVM内存与GC、SpringBean生命周期、事务、AOP、MySQL索引与事务隔离级别。这些内容占Java后端面试的六成以上必须做到张口就来且能应对连续追问。第二优先级项目加分项Redis缓存穿透、击穿、雪崩、消息队列为什么用MQ、如何保证可靠性、分布式理论CAP、BASE、分布式事务方案。这些通常结合项目经历来问纯背理论容易被揭穿要准备一两个真实场景例子。第三优先级新版本和冷门内容虚拟线程、ZGC、GraalVM、新语法特性。这些是区分度较高的加分内容。面试官问到你能答出基本原理就很出彩但如果第一优先级还没准备好就不要先啃这块。7.2 练习把答案“讲出来”而不是“背出来”最后分享一个最实用的经验八股文复习一定要开口练。我自己在面试别人时最常见的情况是候选人心里有答案但表达出来没有逻辑先说结论再说原因让面试官自己猜场面特别尴尬。正确的回答结构是先给结论一句话再展开原因最后给一个场景例子。拿“为什么HashMap线程不安全”来说先答“因为并发put时多个线程同时修改同一个数组下标位置可能导致数据覆盖或者扩容时互相竞争导致元素丢失。”接着补原因“两个线程同时检查出同一个位置为空都往里放头节点后放的那个会覆盖前一个。”最后说场景“所以多线程场景要用ConcurrentHashMap。”这样三段式的回答信息密度高逻辑清晰比倒豆子般背一遍源码要强得多。我自己复习时习惯把每个考点写成一页PPT式的笔记顶部一句结论中间两到三条关键原理底部一个实际案例。面试前几天把笔记拿出来开着手机录音对着空房间讲一遍回放听哪里卡壳、哪里表达绕改完再讲一遍。一轮下来基本所有高频题都能流畅表达。这个方法适用于刚毕业找工作的人也适用于工作几年打算跳槽的人效果非常稳定。把八股吃透不是为了面试背答案而是为了线上问题来临时心里真的不慌。因为你会发现面试官当场追问的那些“为什么”其实就是生产环境里真正要面对的问题。