2024年的Java面试市场说白了就是“八股文定生死”。很多朋友一听到“八股文”三个字就皱眉觉得这是死记硬背、毫无技术含量。但以我这些年面试别人和被别人面试的经验来看八股文恰恰是Java技术栈里最核心、最浓缩的知识沉淀它考察的是一个程序员的基础扎不扎实、有没有系统性地学过底层原理。这篇东西就是我在2024年秋招和社招高峰期把高频问到的Java面试八股文重新梳理了一遍从Java基础、集合框架、并发编程、JVM到Spring、MySQL、Redis、Kafka能整理的都整理进去了适合马上要面试的朋友快速过一遍也适合刚入行不久、想系统补基础的同学慢慢啃。我会尽量把每个问题背后的原理讲清楚而不是只甩一个标准答案。毕竟面试官问八股文不是真的想让你背课文他是想通过这个问题验证你有没有深入思考过。你答出“是什么”只是及格能讲出“为什么”才是加分项。1. 八股文到底是什么Java面试为什么绕不开它1.1 八股文的真实含义和常见误解先说点实在的。很多人觉得八股文就是面试官拿着题库一个一个问你背得越熟越好。这个理解对了一半。实际上Java后端面试问的八股文本质上是计算机科学里那些不随框架迭代而变化的基础知识JVM内存模型、并发编程的锁机制、集合类的底层数据结构、MySQL索引的实现、Redis的线程模型。这些东西十年二十年都不会大变你学会了就是长期资产。我见过太多简历上写“熟练掌握Java”结果问HashMap底层原理只能答出“数组加链表”再往下问“为什么链表长度到8才转红黑树”就卡住了。这种就是典型的只背了开头没理解全貌。真正有效的八股文复习是每个知识点都能用一条逻辑链串起来是什么、为什么这样设计、解决了什么问题、可能会踩什么坑。把这四个点串完你才能算彻底掌握一个考点。1.2 八股文和项目经验是什么关系这里必须澄清一个误区八股文和项目经验不是对立的。很多准备面试的朋友把大部分时间花在写项目上觉得只要项目牛基础差一点无所谓。但实际面试流程里技术面第一轮大概率就是基础题这一轮过不了项目再亮眼也到不了后面的综合面。反过来基础扎实的人在讲项目的时候也会讲得更有深度因为他能把项目里的功能设计对应到底层原理上。比如说你在项目里用Redis做了缓存面试官问你“为什么用Redis不用本地缓存”你要能答出Redis是单线程模型、基于内存操作、I/O多路复用这些就是八股文里的内容。所以说八股文是项目的说明书项目是八股文的验证场两者是互补关系。我整理这份2024新版八股文就是希望你把地基打牢再去考虑楼盖多高。2. Java基础高频考点这些题必须张口就来2.1 String、StringBuilder、StringBuffer三兄弟的区别这是Java基础面试里出现频率最高的一组题几乎每场面试开场热身都会碰到。String是final修饰的不可变类每次拼接字符串都会创建新对象所以循环拼接场景下性能极差。StringBuffer是线程安全的它的方法加了synchronized关键字但代价是性能偏低。StringBuilder是JDK 1.5引入的线程不安全但性能最好。日常开发中方法内部拼接字符串单线程环境直接用StringBuilder就对了。但这里有个细节很多人不知道如果在方法内部new的StringBuilder即使它是线程不安全的也不会出问题因为方法栈是线程私有的。面试官问“为什么局部变量不会有线程安全问题”你如果能主动答出这一层会非常加分。另外字符串常量池也是一个常考的延伸点比如问“String s1 new String(abc)创建了几个对象”正确答案是两个一个在堆里一个在常量池里。这种细节题最容易拉开差距。2.2 equals和hashCode这对好基友到底怎么回事equals和hashCode的约定是Java面试里的经典老演员了。第一如果两个对象equals相等那它们的hashCode必须相等。第二如果两个对象hashCode相等equals不一定相等这就是哈希碰撞。第三重写equals一定要重写hashCode否则在HashSet、HashMap这些集合里就会出Bug。我拿实际场景给你解释你往HashSet里存对象HashSet先算对象的hashCode定位到桶再用equals判断桶里有没有相同的对象。假如你只重写了equals没重写hashCode两个业务上相等的对象hashCode不同就会跑到不同的桶里HashSet就会把它们当成两个不同的对象存进去去重功能直接失效。这个坑我在真实项目里踩过排查的时候特别隐蔽。复习的时候建议配合HashMap的put流程一起理解因为这套逻辑在HashMap里体现得最完整。2.3 HashMap底层原理从put流程到红黑树HashMap绝对是Java集合面试里的重量级选手几乎每一场后端面试都会问。它的底层结构是数组加链表加红黑树JDK 1.8之后引入了红黑树。当你调用put(key, value)时流程是这样的先对key的hashCode做一次扰动计算然后通过(n - 1) hash找到数组下标如果这个位置是空的就直接放进去如果已经有元素了就判断key是否相等相等就覆盖值不相等就以链表的方式往后追加当链表长度超过8并且数组长度大于等于64时链表会转成红黑树。面试官通常会在这里追加几个问题。为什么链表长度阈值是8因为源码注释里有一张泊松分布的概率表在负载因子0.75的情况下链表长度到达8的概率已经降到千万分之一级别这时候转红黑树是性价比最高的选择。为什么数组长度要大于64才转树因为如果数组太小hash碰撞严重转树并不能根本解决问题应该先扩容来分散元素。还有一个经典问题是为什么HashMap的容量必须是2的n次方因为这样能用位运算(n - 1) hash代替取模运算效率更高而且只有2的n次方减1的二进制才是全1这样得到的下标分布更均匀。2.4 ArrayList和LinkedList的对比别只会背八股ArrayList和LinkedList的区别属于那种“人人都知道但很少有人能答好”的题。基础的答法是ArrayList底层是Object数组查询快、增删慢LinkedList底层是双向链表增删快、查询慢。但你要真这么答在一些资深面试官那里是过不了关的。原因在于ArrayList的增删慢指的是在指定位置插入或删除因为需要System.arraycopy移动后续元素但如果是在末尾追加元素ArrayList并不慢因为正常情况下它只需要O(1)的复杂度只有触发扩容才会复制整个数组到新数组。LinkedList的增删快说的是在已知节点前后增删是O(1)如果你需要先遍历找到那个位置那复杂度还是O(n)。另外ArrayList还有个值得一提的细节就是它的默认容量是10扩容时是1.5倍扩容扩完会用Arrays.copyOf复制元素到新数组。如果面试官问你“怎么提前知道ArrayList大概需要多少数据量避免频繁扩容”答案是用带初始容量的构造函数new ArrayList(expectedSize)这算是一个性能优化点。2.5 Java异常体系finally里到底能不能写return异常相关的题在Java基础里属于中等热度但答好了很能体现功底。先记住大结构Throwable是所有错误和异常的父类下面分Error和Exception。Error是JVM层面的严重问题比如OutOfMemoryError、StackOverflowError程序不该也不能处理。Exception又分受检异常和非受检异常受检异常是编译器强制要求捕获或抛出的比如IOException非受检异常是RuntimeException及其子类比如NullPointerException、ClassCastException。关于finally块里写return这个话题我明确告诉你能写但强烈不建议写。因为如果try或catch里有returnfinally会在return之前执行如果finally又return了一个值它会覆盖掉try或catch里的返回值而且这种覆盖极其隐蔽看代码的时候很容易忽略。更关键的是finally里写return会吞掉异常如果try块里抛了个异常finally的return返回后这个异常就彻底丢失了排错的时候会欲哭无泪。我的建议是finally只做资源清理永远不要写return也尽量不要写会抛出异常的代码。3. 并发编程难点锁和内存模型必须吃透3.1 Java内存模型和volatile的可见性原理并发编程是Java面试的分水岭也是很多人最头疼的部分。Java内存模型也就是JMM它规定所有变量都存主内存每个线程还有自己的工作内存线程对变量的操作必须先拷贝到工作内存再写回主内存。这就带来了可见性问题线程A改了变量的值线程B可能看不到。volatile关键字解决的就是这个可见性问题它保证一个线程修改volatile变量后这个修改会立即刷新到主内存同时其他线程读到这个变量时会强制从主内存重新读取而不是用工作内存里的旧值。在JDK 1.5之后volatile还有了更强的语义那就是禁止指令重排序它能保证volatile变量前后的读写操作不会被编译器或CPU乱序执行。经典的double-checked locking单例写法就依赖volatile这个语义防止对象在初始化未完成时被其他线程读取到半成品状态。3.2 synchronized锁升级过程从偏向锁到重量级锁synchronized在JDK 1.6之后做了大量优化从原来的重量级锁变成了一个状态机。锁一共有四种状态按升级顺序排分别是无锁、偏向锁、轻量级锁、重量级锁。偏向锁的逻辑是同一个线程第一次进入同步块时JVM会在对象头的Mark Word里记录这个线程的ID之后这个线程再次进入时就不用做任何同步操作直接执行适合锁被同一个线程反复获取的场景。一旦有另一个线程来竞争偏向锁就会被撤销升级为轻量级锁。轻量级锁的实现是CAS自旋就是线程在循环里不断尝试获取锁不会立刻阻塞。CAS全称是Compare And Swap意思是先比较目标内存的当前值如果等于预期值就替换成新值整个操作是原子的。JDK里大量使用CAS从AtomicInteger到ConcurrentHashMap都离不开它。自旋的好处是省去了线程阻塞和唤醒的开销但如果自旋时间太长CPU就被白白浪费了。所以当自旋达到一定次数仍然抢不到锁轻量级锁就会升级为重量级锁线程进入阻塞状态由操作系统来调度。3.3 AQS是什么线程池的核心参数怎么记AQS全称AbstractQueuedSynchronizer它是Java并发包里的地基。ReentrantLock、Semaphore、CountDownLatch、ReentrantReadWriteLock这些工具类的底层实现全部依赖于AQS。AQS的核心是一个状态位state和一个双向等待队列。拿ReentrantLock举例lock()方法会尝试用CAS把state从0改成1改成功了就拿到锁没成功线程就进队列等着前一个节点释放锁后会唤醒后一个节点。线程池这块一定要把几个核心参数背熟再结合场景去理解。corePoolSize是核心线程数maximumPoolSize是最大线程数keepAliveTime是空闲线程存活时间workQueue是任务队列threadFactory是线程工厂handler是拒绝策略。当提交一个任务时执行流程是这样的线程数小于corePoolSize就新建线程执行大于等于corePoolSize就把任务塞进队列队列满了线程数小于maximumPoolSize就再新建线程执行线程数已经等于maximumPoolSize了就执行拒绝策略。这里有面试官常问的两个点。第一JDK内置的拒绝策略有四种AbortPolicy直接抛异常、CallerRunsPolicy用调用者线程执行、DiscardPolicy静默丢弃、DiscardOldestPolicy丢弃最老的任务。第二如果问你Executors工厂方法为什么在生产环境不推荐答案是因为它返回的线程池要么是无界队列比如newFixedThreadPool用的是LinkedBlockingQueue任务堆积会导致OOM要么是最大线程数Integer.MAX_VALUE比如newCachedThreadPool线程数过多也会导致OOM。3.4 线程池核心参数如何计算IO密集型和CPU密集型关于线程池参数的计算网上有很多公式但实际项目中不能完全照搬需要根据业务类型调优。IO密集型任务的特点是线程大部分时间在等待网络或磁盘真正占CPU的时间很少所以可以多开线程一般设置为核心数乘2或者核心数除以(1 - 阻塞系数)阻塞系数可以取0.8到0.9。CPU密集型任务线程基本全程占用CPU线程数建议设为核心数加1多出来的那个线程是为了防止某个线程因意外被阻塞时CPU还能保持繁忙。要注意一点这些数字只是启动值不是一成不变的。项目上线后要通过压测来调整观察CPU利用率、任务队列积压量和线程阻塞比例逐步找到最合适的线程数。面试时你可以把这个思路讲给面试官听这是在告诉他我不仅会背公式还知道公式怎么落地。这通常会比你默背一个网上的参数更有说服力。4. JVM相关核心考点垃圾回收和类加载机制4.1 运行时数据区哪些区域会OOMJVM的运行时数据区按线程共享还是私有可以分成两大类。线程私有的有虚拟机栈、本地方法栈、程序计数器线程共享的有堆和方法区。程序计数器记录当前线程执行的字节码行号它是唯一一个不会发生OutOfMemoryError的区域。虚拟机栈就是Java方法执行时的内存模型每个方法调用会生成一个栈帧栈帧里有局部变量表、操作数栈、动态链接和方法出口栈深度超过限制就会抛StackOverflowError。堆是Java对象的主要存放区域几乎所有对象实例都在这里分配JVM规范里说堆可以处于物理上不连续但逻辑上连续的空间堆溢出是面试里最常见的内存溢出类型一般报java.lang.OutOfMemoryError: Java heap space。方法区在JDK 1.8之后被移到了元空间元空间使用本地内存不再受JVM堆大小限制。这里有个常见面试题JDK 1.8为什么要用元空间替代永久代主要原因是永久代的内存大小难以调整且经常出现PermGen OOM把字符串常量池等移出后用本地内存来存类的元数据能有效避免这类问题。字符串常量池在JDK 1.7时被移到了堆里这个位置变化也是一个高频考点。4.2 判断对象是否已死的两种方法GC Roots有哪些JVM垃圾回收的第一步是先判断哪些对象可以回收。判断方法有两种引用计数法和可达性分析算法。引用计数法的思路是每个对象有一个计数器被引用就加1引用失效就减1减到0就回收。这个方案简单高效但解决不了循环引用的问题比如A引用B、B引用A这两个对象都没有外部引用了但它们的计数器都不是0就永远不会被回收。所以主流的HotSpot虚拟机采用的是可达性分析算法。可达性分析算法的思路是从一组称为GC Roots的根节点出发沿着引用链向下搜索凡是没被引用链连接到的对象就判定为可回收。GC Roots在Java里有几类虚拟机栈中引用的对象、方法区中类静态属性引用的对象、方法区中常量引用的对象、本地方法栈中JNI引用的对象以及Java虚拟机内部的引用。这个知识点面试官经常会延伸问一下比如Thread对象可以作为GC Roots吗可以因为正在运行的线程可以被看作GC Roots。这题能答上来的人不多你可以作为亮点准备。4.3 垃圾回收算法和常见收集器对比垃圾回收算法是JVM面试的核心。标记-清除算法是最基础的算法分两阶段先标记出所有需要回收的对象再统一回收。缺点是会产生大量不连续的内存碎片后续分配大对象时可能因为找不到连续空间而提前触发GC。复制算法把内存分成两块相等的区域每次只使用其中一块垃圾回收时把存活对象复制到另一块然后整块清空既没有碎片效率也高缺点就是内存利用率低。标记-整理算法在标记后不直接清除而是让所有存活对象向一端移动然后清理掉边界以外的内存适合老年代。HotSpot的分代收集策略正是结合了这三种算法的优点。新生代对象存活率低用复制算法把Eden区和Survivor区搭配使用默认比例是8:1:1。老年代对象存活率高用标记-清除或标记-整理。收集器方面面试常问的有CMS和G1。CMS是JDK 8时代老年代的主流收集器它的特点是并发收集、停顿时间短但它有两个明显的缺点一是使用标记-清除算法会产生内存碎片二是并发阶段会占用CPU资源导致应用吞吐量下降。G1从JDK 9开始成为默认垃圾收集器它把堆划分成一个个Region可以预测停顿时间并且只在部分Region上回收避免了全堆扫描。4.4 类加载过程和双亲委派模型类加载机制属于JVM里偏原理的题面试中中等频率但答好了容易让面试官眼前一亮。类从被加载到内存开始到卸载出内存为止整个生命周期包括加载、验证、准备、解析、初始化、使用、卸载七个阶段。其中加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的而解析阶段可以发生在初始化之后这是为了支持Java的动态绑定。面试官最关心的环节通常是加载阶段的三个动作通过类的全限定名获取二进制字节流、把字节流中的静态存储结构转化为方法区的运行时数据结构、在内存中生成代表这个类的Class对象作为访问入口。另一个必考点是双亲委派模型。它的工作过程是一个类加载器收到类加载请求后不会自己先加载而是先把请求委派给父加载器每一层都是如此所以所有的加载请求最终都会传到最顶层的启动类加载器。只有当父加载器反馈无法完成加载时子加载器才会尝试自己加载。这么做的最核心目的是为了防止核心类库被篡改比如你自定义一个java.lang.String类由于双亲委派机制它永远不会被加载用的还是JDK里的原始String。5. Spring、MySQL和Redis这些重头戏5.1 Spring Bean的生命周期和循环依赖Spring框架的八股文问得最密集的就是Bean生命周期。我把完整流程给你捋一遍实例化bean对象这通常是通过构造器完成的属性填充就是注入各个依赖的属性初始化之前会调用BeanPostProcessor的postProcessBeforeInitialization方法执行InitializingBean的afterPropertiesSet方法或者配置的init-method初始化之后调用BeanPostProcessor的postProcessAfterInitialization方法到这一个Bean就可以使用了容器关闭时调用DisposableBean的destroy方法或配置的destroy-method。循环依赖这道题是Spring面试的压轴题问的是A依赖B、B依赖A怎么解决。Spring使用三级缓存来解决三个缓存分别存放一级缓存存放完整的单例Bean二级缓存存放早期暴露的半成品Bean三级缓存存放ObjectFactory对象工厂。当A创建时发现依赖B就去创建BB创建时发现依赖A这时A虽然还没初始化完但三级缓存里已经有了A的工厂方法B就可以通过工厂方法拿到A的早期引用完成自己对A的注入B完成创建后A再拿B的引用完成注入。注意这个机制只能解决setter注入的循环依赖构造器注入的循环依赖解决不了因为构造器阶段Bean还没实例化出来缓存里根本没有可供引用的东西。5.2 Spring事务的传播行为和失效场景事务传播行为是Spring事务考点里最让人头疼的一块因为概念多、场景乱。最重要的是要记住PROPAGATION_REQUIRED它表示如果当前没有事务就新建一个如果有就加入当前事务这是Spring的默认传播行为也是90%的业务场景需要的。其次是PROPAGATION_REQUIRES_NEW它表示无论如何都会挂起当前事务、新建一个独立事务适用于日志记录这种即使主逻辑失败也不能回滚的场景。再记一下PROPAGATION_NESTED它表示嵌套事务回滚时只回滚到保存点。事务失效的问题在实际工作中经常碰到面试也常问。最常见的原因有几个方法不是public的类内部方法自调用比如同一个类里方法A调方法BA加了事务注解B没加B实际上是普通方法调用事务不起作用方法被final修饰因为动态代理无法代理final类注解所在的方法异常被吞掉了比如try-catch捕获异常后没抛出去事务感知不到异常自然就不会回滚数据库引擎不支持事务比如MySQL的MyISAM引擎。你把这几个场景背下来面试官往往还会追问“内部方法自调用怎么解决”答案是注入自己或者用AopContext.currentProxy获取代理对象再或者拆成两个类。5.3 MySQL索引为什么用B树索引失效场景有哪些MySQL索引的底层原理是数据库面试里最核心的内容没有之一。为什么MySQL的InnoDB引擎选择B树而不是B树、红黑树或者哈希表每个选择背后都有理由。哈希表支持等值查询比如select * from user where id 1这种查询确实快但哈希表不支持范围查询做不了order by和like所以实际存储引擎用的是树结构。红黑树是二叉平衡树数据量大时树的高度会很高比如1000万条数据树高大约是20多层每次查找都要多次磁盘I/O。B树是多叉树一个节点可以存很多子节点树高大大降低。但B树相比B树还有个关键优势所有数据都在叶子节点非叶子节点只存索引键值所以一个非叶子节点能存更多索引项树更矮同时叶子节点之间用双向链表串联起来范围查询可以直接在链表上顺序扫描不用回溯到父节点。这就是MySQL索引选B树的核心逻辑。索引失效场景也值得专门整理对索引列使用函数、隐式类型转换、like查询以%开头、联合索引不满足最左前缀原则。面试时能把这几种场景答全再解释一下为什么会失效就已经超过大多数候选人了。5.4 Redis为什么快缓存三大问题的解决办法Redis作为缓存中间件几乎是Java后端岗位的必问内容。第一个必考问题是Redis为什么这么快答案可以拆成四点基于内存操作数据都放在内存里读写速度自然远高于磁盘单线程模型避免了多线程上下文切换和锁竞争的开销I/O多路复用机制用单个线程处理多个客户端连接通过epoll监听多个文件描述符有事件才处理高效的数据结构比如跳表用于有序集合。注意Redis 6.0之后引入了多线程I/O但默认只用于网络读写核心的命令执行仍然是单线程的这个细节别搞混了。缓存三大问题是面试里的老三样。缓存穿透是指查一个不存在的key缓存和数据库都没有请求直接打到数据库解决方法是缓存空对象或者用布隆过滤器先过滤掉不存在的key。缓存击穿是指某个热点的key刚好过期了同时有大量请求打过来全部打到数据库解决方法是互斥锁只让一个线程去查数据库并重建缓存其他线程等待。缓存雪崩是指大量key同时过期或者Redis直接宕机解决方法是给过期时间加随机数、做高可用部署、加多级缓存。我建议你把这三个问题的区分记到骨子里穿透是数据不存在击穿是单个热点key过期雪崩是大面积key同时过期。6. Kafka为什么能支撑百万并发面试怎么答6.1 Kafka的架构组件和核心设计Kafka的题近几年在Java后端面试里的出现频率越来越高尤其是招聘要求里有“高并发、消息队列”经验的岗位。Kafka的架构可以这样理解Producer把消息发到Broker上的某个TopicTopic又被分成多个Partition每个Partition是一个有序的消息日志Consumer通过Consumer Group订阅Topic进行消费。这里有一个关键设计Partition内的消息是有序的但Partition之间的消息不保证全局有序所以如果你需要全局顺序消费要么用单个Partition要么在消息里带上全局序号由消费者自己排序。Kafka为什么能支撑百万级并发这个问题是Kafka面试里最有含金量的一道题。核心答案可以拆成几个关键词。顺序写磁盘Kafka虽然用的是磁盘存储但它只在日志尾部追加消息避免随机写顺序写的速度接近内存。页缓存Kafka利用了操作系统自身的页缓存机制读写直接操作Page Cache减少了用户态与内核态之间的数据拷贝。零拷贝消费者读取数据时通过sendfile系统调用数据从磁盘到网卡直接复制中间不经过用户程序缓冲区大幅降低了CPU消耗。批量处理生产者可以批量发送消息消费者可以批量拉取消息通过批量化降低网络I/O开销。6.2 消息可靠性和重复消费问题消息队列面试里可靠性这条线一定会被问到经典问法是“如何保证消息不丢失”。拆分来看需要从三个环节分别保证。生产者的消息不丢失要设置acksall并且开启重试机制如果发送失败就重试。Broker的消息不丢失要设置副本因子replication.factor不少于3并且最小同步副本min.insync.replicas配置为2这样即使有一个副本宕机消息也不会丢。消费者的消息不丢失核心是先消费后提交offset也就是说业务逻辑处理成功之后才提交位移避免消息还没消费完就提交了offset导致重启后消息被跳过。重复消费这个问题和消息不丢失是互补的。要做到不丢消费端就可能会重复消费要做到不重就需要引入幂等性设计。最常用的做法是给每条消息一个唯一业务ID消费者在本地记录哪些ID已经处理过处理前先查一下或者利用数据库的唯一约束重复插入直接报错捕获从而实现幂等。还有个细节是Kafka消费者的提交方式默认是自动提交即enable.auto.committrue它会在每次poll之后自动提交本次拉取的最大offset但可能会在消息还没处理完时就提交所以生产环境建议手动提交offset在消息处理成功后再提交这样语义更可控。7. 算法手写题面试现场最容易翻车的地方7.1 排序算法必须会背会写冒泡和快排是底线Java面试到了二面或三面经常会有手写算法的环节排序算法是最常见的出题方向。冒泡排序是最基础的排序算法思路是每一轮把相邻的两个元素比较并交换把最大的元素冒到最后面时间复杂度是O(n²)。它本身性能不好但因为代码简单经常被用来考察候选人基础扎实不扎实。快速排序的出场率比冒泡高得多它是实际生产中应用最广的排序算法之一平均时间复杂度O(nlogn)核心思想是分治选一个基准值pivot把数组分成左边小于等于基准、右边大于基准两块再对左右两块递归排序。手写快排的时候有几个容易写错的地方递归的退出条件是low high分区函数里循环移动指针时要先移动高位指针再移动低位指针或者反过来只要保证逻辑一致就行每次交换后要正确处理指针移动防止死循环。我建议你背一个自己习惯的模板面试时直接默写比临时想更稳。7.2 手写单例模式双重检查锁是标准答案之一单例模式是手写题的常客它本身不难但考察的细节很多。最简单的写法是饿汉式类加载时就创建实例天生线程安全缺点是可能造成资源浪费。懒汉式是第一次调用时才创建实例但需要处理线程安全问题。双重检查锁是比较标准的写法代码逻辑是第一次判断instance是否为null不是就直接返回是null才进入同步块进入后再次判断instance是否为null双重判断保证只有一个线程能创建实例。这里必须要用volatile修饰instance原因是防止指令重排序因为instance new Singleton()这行代码在JVM层面不是原子操作它分三步分配内存空间、初始化对象、把引用指向内存地址。如果发生指令重排序第三步可能先于第二步执行另一个线程就会拿到一个还没初始化完成的对象使用时直接NullPointerException。静态内部类方式也是一种推荐方案它利用类加载机制天然实现了懒加载和线程安全代码也更简洁。7.3 手写LRU缓存用LinkedHashMap还是自己写LRU缓存算法即最近最少使用策略是高频考察的数据结构题。实现思路理解起来很简单每次数据被访问就把这个数据移到最前面缓存满了就把最后面的数据淘汰掉。这个场景天然适合用HashMap加双向链表来实现HashMap负责O(1)的查询双向链表负责维护访问顺序。JDK里自带了一个神器LinkedHashMap它内部维护了一个双向链表并且支持访问顺序模式直接把accessOrder设为true重写removeEldestEntry方法在返回true时移除最老的元素就能实现一个LRU缓存。但面试官有时候会追问一句“你不准用LinkedHashMap自己动手实现一个”这时候你就要手写双向链表加HashMap的结构了。核心思路是定义Node节点包含key、value、prev、next指针定义一个dummy head和dummy tail方便在头部插入和尾部删除HashMap存key到Node的映射get时如果节点存在就把节点移到头部put时如果key已存在更新value并移到头部如果key不存在新建节点插入头部并检查容量如果超过限制就删除尾节点并移除HashMap里的对应key。8. 面试准备阶段的常见问题和心态调整8.1 八股文背了忘、忘了背到底怎么对抗遗忘复习Java八股文最大的困扰就是内容太多、遗忘太快。以我的经验对抗遗忘最好的办法不是一遍一遍刷题而是建立知识图谱。你可以把所有考点按照Java基础、集合、并发、JVM、Spring、MySQL、Redis、Kafka、分布式这些模块分类每个模块下面再用思维导图画出知识点之间的关联。比如你把HashMap的put流程画出来就会自然延伸到哈希碰撞、红黑树、扩容机制、线程安全问题一个知识点能带出五六个知识点复习效率比零散地刷题高很多。另外一个方法是用“费曼学习法”也就是把你学到的知识点用最通俗的话讲给别人听。你可以在复习时打开手机录音假装自己在面试讲一遍HashMap的原理回放时你就能发现自己哪里讲不清、哪里记忆模糊针对性地补强。这个方式虽然听着有点笨但效果非常显著尤其是对JVM和并发这种抽象概念讲一遍比读五遍有用得多。8.2 面试官问的题不会怎么办如何体面地应对面试现场遇到不会的题是必然的关键是怎么应对。最要不得的是不懂装懂硬着头皮瞎编面试官基本都是老江湖你编没编一眼就能看穿而且一旦被认定为不诚实其他答得再好也没用。正确的姿势是坦诚地说自己对这个问题了解不深入然后尝试基于已有的知识做推理比如“这个点我没有实际用过但根据我对相关原理的理解它可能和XXX机制有关我猜测原因是XXX”。这种方式的好处在于你向面试官传递了几个积极信号第一你很诚实不会编造答案第二你有逻辑推理能力即使不会也能分析第三你愿意学习。很多时候面试官更看重的是你面对未知问题的态度和思考方式而不是那个标准答案本身。还有个小技巧面试结束后立刻把不会的问题记下来回去查资料补充然后想清楚如果下次再被问到要怎么回答。这样每一次面试都能变成一次学习机会越面越强。8.3 简历项目经历怎么包装才能和八股文呼应上最后说一个很现实的问题你为什么背了那么多八股文面试官依然觉得你项目很空洞因为项目经历和八股文知识点脱节了。写简历项目时不要只写业务功能要把对应的技术难点和解决方案写进去。比如你在项目里用过Redis缓存就写“使用Redis缓存热点数据降低数据库压力通过设置随机过期时间解决缓存雪崩问题”你做过秒杀系统就写“使用RabbitMQ异步削峰通过Redis预减库存解决超卖问题”。每个技术点都连带写出它背后解决的问题面试官顺着这个问下去自然就能问到你在八股文里复习过的知识点。我个人在筛选简历和面试候选人时最怕看到的是那种纯功能的描述比如“负责用户管理模块、订单模块的开发”这让人根本没法提问。反倒是那些带技术亮点的描述比如“通过线程池异步处理批量消息线程数按CPU密集型和IO密集型混合场景配置为核心数的2倍”既体现你懂并发又体现你懂线程池参数计算面试官一句话就能导入到你最擅长的知识点。所以背八股文和写项目经历从来不是两件事是一件事的两面。复习到最后我想提醒你一点这份2024版八股文整理得再全也只是地图不是目的地。面试本质上考察的是你平时的积累和思考习惯八股文能帮你通过面试但长期的技术成长还得靠源码阅读、实际项目打磨和持续复盘。祝看到这里的每一位朋友都能拿到心仪的offer。