简介这是一份专为Java后端开发者及求职者打造的面试核心知识精要整理聚焦JVM底层原理、多线程机制、集合框架与设计模式等高频考点直击大厂技术面试中的‘八股文’难点。资源以结构化PDF形式呈现内容覆盖JVM内存模型程序计数器、虚拟机栈、本地方法区、堆、方法区、运行时内存划分新生代Eden/Survivor、老年代、永久代/元空间、Minor GC执行流程等深度细节并预留Java语法、集合、多线程、设计模式等后续模块扩展空间。压缩包仅含1个PDF文件大小10.71MB排版清晰、目录层级分明含20二级标题与50三级要点便于快速定位与碎片化复习。目前已有648人学习下载适合作为面试前系统梳理、查漏补缺或校招/社招冲刺阶段的高效复盘资料。1. JVM 垃圾回收不是背概念是考你“能画出来、能讲清、能调参”八股文里最易翻车的3个致命点面试官翻到 JVM 这一页90% 不会问“什么是堆”而是直接甩一句“来画一下 G1 的 Region 划分标出 E、S、O 区再讲讲 Humongous Object 怎么触发 Mixed GC。”——这句话一出当场有三分之一的人笔停在纸上嘴张在半空。这不是考记忆力是考你有没有真正在线上调过 GC 日志、有没有在压测时盯着 jstat 输出发过呆、有没有因为 CMS 失败导致服务雪崩后连夜改参数。Java 八股文里JVM 占比超 35%其中 GC 相关题直接决定你能不能进二面它不考定义考路径对象从 new 到被回收的完整生命周期、考对比CMS vs G1 在什么场景下谁先跪、考实操-XX:MaxGCPauseMillis200 是调给谁听的。这份《Java核心知识整理常考八股文》PDF 共 283 页JVM 部分占 33 页但真正高频、高区分度、高失分率的就集中在 2.3.1 新生代结构、2.4.5 分代算法、2.7.7 G1 收集器这三块。适合两类人一类是刚刷完 LeetCode 却在 JVM 环节被连环追问到怀疑人生的后端新人另一类是写了 3 年 Spring Boot、但没亲手配过 -XX:UseG1GC 的业务开发——别慌这份资料不是让你背完 283 页而是帮你把这 33 页里“面试官必问、你必答错、答案必须带参数”的硬核点全拆成可复现、可默写、可现场画图的答题模块。2. JVM 内存结构与 GC 算法从线程私有区到堆分区每一块都藏着面试官的钩子2.1 线程私有区程序计数器、虚拟机栈、本地方法区为什么它们“不参与 GC”这三个区域之所以被划为“线程私有”根本原因在于其生命周期与线程强绑定线程启动时分配线程结束时自动释放。程序计数器只存下一条字节码指令地址虚拟机栈只存方法调用帧局部变量、操作数栈、动态链接、方法出口本地方法区只存 native 方法的 C/C 栈帧。它们不存 Java 对象实例自然不归 GC 管。但面试官爱在这里埋钩子——比如问“虚拟机栈会不会 OOM”答案是会但不是因为对象太多而是因为线程数过多-Xss 设置过小 无限递归导致栈空间耗尽抛StackOverflowError或OutOfMemoryError: unable to create new native thread。注意这不是堆内存溢出jmap -heap 看不到得用 jstack 查线程数。再比如“本地方法区在 JDK8 后去哪了”答案是被元空间Metaspace取代而元空间在本地内存Native Memory不受 -XX:MaxMetaspaceSize 限制时可能吃光系统内存——这正是线上服务突然被 OOMKilled 的常见黑匣子。提示当面试官问“哪些区域不参与 GC”别只答“程序计数器、虚拟机栈、本地方法区”必须补一句“因为它们不存储 Java 对象实例其内存由线程生命周期管理GC 只负责堆和方法区元空间中的对象和类元数据。”2.2 堆内存分区新生代三区Eden/S0/S1不是静态地图而是动态流转的“对象中转站”新生代不是三个固定大小的盒子而是一个按 Minor GC 触发条件动态重分配的流水线。关键参数是-XX:SurvivorRatio8默认值它表示 Eden : S0 : S1 8 : 1 : 1。假设新生代总大小为 1GB则 Eden 占 800MBS0 和 S1 各占 100MB。对象优先在 Eden 分配Eden 满时触发 Minor GC复制将 Eden 和 From Survivor即 S0中存活的对象复制到 To Survivor即 S1每复制一次对象年龄 1清空清空 Eden 和 S0互换S0 与 S1 角色互换下次 GC 时 S1 变 FromS0 变 To。这个过程看似简单但面试官常考两个反直觉点对象年龄阈值不是固定 15-XX:MaxTenuringThreshold默认是 15但实际晋升老年代的阈值由动态计算决定。当某次 Minor GC 后To Survivor 区放不下所有存活对象时JVM 会把年龄 ≥ 当前阈值的对象直接送入老年代这个阈值叫“动态年龄判定”。大对象直接进老年代-XX:PretenureSizeThreshold参数仅对 Serial/ParNew 有效可设置大对象阈值超过此值的对象如 byte[4MB]直接分配到老年代避免在 Eden 和 Survivor 之间来回复制。G1 中则用 Humongous Region 处理。// 演示大对象触发直接分配需配合 JVM 参数 public class LargeObjectTest { public static void main(String[] args) { // 创建一个 6MB 的 byte 数组假设 -Xms2g -Xmx2g -XX:NewRatio2 byte[] bigArray new byte[6 * 1024 * 1024]; // 6MB // 若未设 -XX:PretenureSizeThreshold 或值 6MB则该对象直接进老年代 System.gc(); // 强制触发 GC观察 GC 日志中是否出现 Promotion Failed } }这段代码本身不报错但配合jstat -gc pid或-Xlog:gc*日志你能清晰看到Eden 使用率几乎不变而老年代Old使用量突增——这就是大对象绕过新生代的铁证。很多候选人说“大对象进老年代”却答不出“怎么验证”更答不出“G1 里没有 PretenureSizeThreshold靠的是 Humongous Region 分配逻辑”。2.3 方法区演进从永久代到元空间不是名词替换而是内存管理权的移交JDK7 之前方法区 永久代PermGen是堆的一部分受-XX:MaxPermSize限制JDK8 开始方法区 元空间Metaspace使用本地内存Native Memory默认无上限。这个变化带来三个实操级考点OOM 场景迁移JDK7 时代java.lang.OutOfMemoryError: PermGen space常见于频繁加载/卸载类如热部署、OSGiJDK8 后变成java.lang.OutOfMemoryError: Metaspace但更隐蔽——它可能耗尽整个系统的物理内存或 swap导致进程被系统 OOM Killer 杀死。参数失效-XX:MaxPermSize在 JDK8 完全无效必须用-XX:MaxMetaspaceSize建议设为 256m~512m防失控-XX:PermSize同理。类卸载条件更严苛永久代时代类卸载需满足“该类所有实例已被回收 加载该类的 ClassLoader 已被回收 该类的 Class 对象无引用”。元空间时代ClassLoader 的回收更难因为应用服务器如 Tomcat常持有着 ClassLoader 的强引用导致元空间持续增长直至 OOM。注意面试官若问“为什么 JDK8 要废永久代”别只答“避免 OOM”要补一句“永久代是堆内存的一部分GC 时需扫描整个堆影响 Full GC 效率元空间独立于堆GC 不扫描它且可动态扩容更符合现代应用类加载频繁的特性。”3. 四种引用类型与 GC 触发时机软引用不是“软弱”虚引用不是“虚构”3.1 强、软、弱、虚引用的本质区别不是强度是 GC 时的“豁免权等级”很多人背口诀“强引用不回收、软引用内存不足时回收、弱引用每次 GC 都回收、虚引用必须配合 ReferenceQueue”但面试官要听的是触发条件与典型场景强引用StrongReferenceObject obj new Object()。只要obj还在作用域内GC 绝对不回收。这是唯一一种“不参与 GC 决策”的引用。软引用SoftReferenceSoftReferenceObject sf new SoftReference(new Object())。JVM 在发生 OOM 之前会尝试回收所有软引用指向的对象。典型场景实现内存敏感的缓存如SoftReferencebyte[]缓存图片当堆内存紧张时自动释放避免 OOM。弱引用WeakReferenceWeakReferenceObject wf new WeakReference(new Object())。只要发生 GC包括 Minor GC无论内存是否充足都会回收。典型场景ThreadLocal的 key 使用弱引用防止 ThreadLocalMap 持有 ThreadLocal 实例导致内存泄漏value 泄漏需手动 remove。虚引用PhantomReferencePhantomReferenceObject pf new PhantomReference(new Object(), queue)。它不能通过 get() 获取对象唯一作用是当对象被 GC 时JVM 会将该虚引用加入关联的ReferenceQueue通知程序“对象已不可达可以执行清理逻辑”。典型场景堆外内存DirectByteBuffer的清理——Cleaner类就是基于虚引用实现的。// 演示弱引用在 ThreadLocal 中的防泄漏设计 public class WeakReferenceDemo { static class MyThreadLocalT { private final ThreadLocalWeakReferenceT tl ThreadLocal.withInitial(() - new WeakReference(null)); public void set(T value) { tl.set(new WeakReference(value)); // key 是弱引用 } public T get() { WeakReferenceT ref tl.get(); return ref null ? null : ref.get(); // get() 返回实际对象 } } public static void main(String[] args) throws InterruptedException { MyThreadLocalString t1 new MyThreadLocal(); t1.set(Hello); System.gc(); // 弱引用对象会被回收 Thread.sleep(100); System.out.println(t1.get()); // 输出 null证明弱引用已失效 } }这段代码的关键在于tl.set(new WeakReference(value))中WeakReference作为 value 存入ThreadLocalMap其 key即MyThreadLocal实例是强引用但WeakReference自身持有的value是弱引用。当t1离开作用域t1实例可被回收WeakReference的get()返回 null从而避免ThreadLocalMap持有业务对象导致内存泄漏。这是面试官最爱挖的“原理代码场景”三位一体题。3.2 易错题四种引用在 GC 中的真实行为90% 的人答错这 3 点错在哪 → 为什么错 → 怎么答对错在哪认为“软引用在 Minor GC 时也会被回收”。为什么错软引用的回收时机由 JVM 内存压力决定Minor GC 只清理新生代不评估整个堆内存是否充足只有当 JVM 判断“即使触发 Full GC 也无法满足内存需求”时才会回收软引用。怎么答对软引用回收发生在 JVM 认为“即将 OOM”时通常伴随 Full GC但不是 Full GC 的必然结果可通过-XX:PrintGCDetails观察日志中SoftReference的cleared数量。错在哪认为“弱引用对象在 GC 后立即消失无法获取”。为什么错弱引用对象在 GC 后只是被标记为可回收实际回收动作可能延迟尤其在并发收集器中且WeakReference.get()在对象被回收前仍返回非 null。怎么答对弱引用对象在下一次 GC 周期开始前仍可能存活get()返回非 null 是正常现象判断是否回收应以ReferenceQueue为准或观察 GC 日志中WeakReference的cleared计数。错在哪认为“虚引用可以像软/弱引用一样通过 get() 获取对象”。为什么错PhantomReference.get()永远返回 null这是 JVM 强制设计——虚引用存在的唯一意义是接收 GC 通知而非访问对象。怎么答对虚引用必须与ReferenceQueue配合使用当queue.poll()返回该虚引用时说明对象已被 GC此时可安全执行清理如Unsafe.freeMemory()但绝不能试图get()它。4. GC 收集器实战对比CMS 已淘汰G1 是底线ZGC 是加分项4.1 CMS 收集器曾经的低延迟王者为何被 JDK14 正式移除CMSConcurrent Mark Sweep的设计哲学是“以 CPU 换时间”在老年代并发执行标记-清除避免长时间 STW。但它有三大硬伤浮动垃圾Floating Garbage并发标记阶段用户线程继续运行新产生的垃圾无法在本次 GC 清理只能等下次并发失败Concurrent Mode Failure并发标记未完成老年代就满了被迫退化为 Serial Old 的单线程标记-整理STW 时间长达数秒碎片化严重标记-清除算法不整理内存长期运行后老年代碎片化大对象无法分配触发 Full GC。JDK9 开始默认启用 G1JDK14 彻底移除 CMS。面试官若还问 CMS是在考你是否了解技术演进脉络。正确答法是“CMS 是 JDK8 及以前的低延迟方案但因并发失败和碎片问题在 JDK9 后被 G1 取代现在生产环境应默认选 G1ZGC/Shenandoah 用于超低延迟场景。”4.2 G1 收集器不是“全堆并发”而是“分区预测混合回收”的精密调度G1Garbage-First的核心突破在于将堆划分为多个大小相等的 Region默认 2048 个每个 Region 可扮演 Eden、Survivor 或 Old 角色。它不坚持分代但保留分代概念——通过 Remembered SetRSet记录跨 Region 引用实现部分 Region 的精准回收。G1 的 GC 分为三类Young GC回收所有 Eden 和部分 Survivor RegionSTW但时间可控目标-XX:MaxGCPauseMillisMixed GC在 Young GC 基础上加入若干老年代 Region由-XX:G1MixedGCCountTarget控制逐步清理老年代Full GC仅当 Mixed GC 无法跟上分配速度时触发单线程STW 极长必须避免。关键参数解读-XX:MaxGCPauseMillis200G1 的暂停时间目标不是保证值而是 JVM 尽力达成的软目标。G1 会动态调整 Young GC 的 Region 数量、Mixed GC 的老年代 Region 数量来逼近该值-XX:G1HeapRegionSize1MRegion 大小影响 Humongous Object 判定≥ 50% Region Size 即为大对象-XX:G1MixedGCCountTarget8Mixed GC 最多清理 8 轮之后强制 Young GC防老年代 Region 清理过慢。提示当面试官问“G1 如何解决 CMS 的碎片问题”答“G1 在 Mixed GC 阶段采用‘标记-整理’算法将存活对象复制到新的 Region原 Region 整块回收彻底消除碎片。”4.3 ZGC/Shenandoah毫秒级 GC 的代价是什么ZGCJDK11 引入和 ShenandoahJDK12 引入的目标是无论堆多大TB 级GC STW 时间 10ms。它们的共同技术是读屏障Load Barrier 颜色指针Colored Pointers对象引用中嵌入标记位ZGC或通过转发指针Shenandoah在对象访问时异步完成重定位。但代价明显CPU 开销增加 10%~15%每次对象访问都要走读屏障内存占用略高ZGC 的颜色指针需额外位宽64 位系统用 4 位存颜色功能限制ZGC 不支持类卸载Class UnloadingShenandoah 在 JDK12 时还不支持 JNI Critical。所以面试官若问“何时用 ZGC”标准答案是“堆内存 4GB 且业务对延迟极度敏感如高频交易、实时风控且能接受 CPU 开销上升普通 Web 应用G1 完全够用ZGC 是锦上添花不是雪中送炭。”5. Java 集合框架高频陷阱HashMap 的红黑树阈值、ConcurrentHashMap 的锁粒度、ArrayList 的扩容血泪史5.1 HashMap从 JDK7 头插法到 JDK8 尾插法一次扩容引发的线程安全灾难JDK7 的HashMap扩容采用头插法新链表的节点插入到链表头部。这在多线程环境下会导致环形链表——当两个线程同时触发 resize一个线程执行到一半被挂起另一个线程完成 resize前者恢复后继续执行可能将节点插入到错误位置形成环。后果是get()时死循环CPU 100%。JDK8 改为尾插法虽仍不线程安全但至少不会死循环。真正的线程安全方案是ConcurrentHashMap或Collections.synchronizedMap()。// JDK7 头插法伪代码危险 void transfer(Entry[] newTable, Entry[] src) { for (int j 0; j src.length; j) { EntryK,V e src[j]; if (e ! null) { src[j] null; do { EntryK,V next e.next; // 保存下一个节点 int i indexFor(e.hash, newTable.length); e.next newTable[i]; // 头插e 指向原链表头 newTable[i] e; // e 成为新链表头 e next; } while (e ! null); } } }这段伪代码的致命点在e.next newTable[i]如果newTable[i]已被另一线程修改e.next就可能指向自己形成环。JDK8 的尾插法通过last.next e避免了这个问题但put()本身仍非原子操作多线程写必须加锁。5.2 ConcurrentHashMapJDK7 的 Segment 锁 vs JDK8 的 CAS synchronizedJDK7 的ConcurrentHashMap采用Segment 分段锁将整个 HashTable 分为 16 个 Segment默认每个 Segment 是一个独立的 HashTable加ReentrantLock。优点是锁粒度比Hashtable全表锁细缺点是 Segment 数量固定扩容需锁全部 Segment且内存占用高每个 Segment 有独立的 HashEntry 数组。JDK8 彻底重构取消 Segment改用CAS synchronized。底层仍是数组 链表 红黑树但锁粒度降到单个桶bin级别put()时先 CAS 尝试插入头节点失败则synchronized住该 bin 的首节点再遍历链表/红黑树size()不再依赖全局计数而是用CounterCell数组分段计数最后汇总避免高并发下size()成为瓶颈。关键参数-Djdk.util.concurrent.ForkJoinPool.common.parallelism4可调computeIfAbsent的并行度但默认值已足够。5.3 ArrayList扩容不是 1.5 倍而是(oldCapacity 1) oldCapacityArrayList的扩容公式是newCapacity oldCapacity (oldCapacity 1)即 1.5 倍。但很多人忽略两点首次扩容空ArrayList第一次add()时elementData为DEFAULTCAPACITY_EMPTY_ELEMENTDATA扩容至DEFAULT_CAPACITY 10不是 1.5 倍大容量扩容当oldCapacity接近Integer.MAX_VALUE时(oldCapacity 1) oldCapacity可能溢出此时hugeCapacity()方法会返回Integer.MAX_VALUE或MAX_ARRAY_SIZEInteger.MAX_VALUE - 8。// ArrayList.ensureCapacityInternal() 关键逻辑 private void ensureCapacityInternal(int minCapacity) { if (elementData DEFAULTCAPACITY_EMPTY_ELEMENTDATA) { minCapacity Math.max(DEFAULT_CAPACITY, minCapacity); // 首次扩容到 10 } ensureExplicitCapacity(minCapacity); } private void ensureExplicitCapacity(int minCapacity) { modCount; if (minCapacity - elementData.length 0) grow(minCapacity); // 真正扩容 } private void grow(int minCapacity) { int oldCapacity elementData.length; int newCapacity oldCapacity (oldCapacity 1); // 1.5 倍 if (newCapacity - minCapacity 0) newCapacity minCapacity; if (newCapacity - MAX_ARRAY_SIZE 0) newCapacity hugeCapacity(minCapacity); // 溢出处理 elementData Arrays.copyOf(elementData, newCapacity); }这段源码揭示了扩容不是简单的乘法而是位运算优化1比/2快且有严格的溢出兜底。面试官若问“ArrayList 扩容机制”必须答出“首次扩容到 10、后续 1.5 倍、溢出时取 MAX_ARRAY_SIZE”。5.4 易错题集合框架里最常被误解的 3 个行为错在哪 → 为什么错 → 怎么答对错在哪认为HashSet的底层是HashMap所以HashSet.add()是线程安全的。为什么错HashSet确实是HashMap的包装map.put(e, PRESENT)但HashMap本身不线程安全HashSet也就不安全ConcurrentHashMap的线程安全不传递给HashSet。怎么答对HashSet线程安全需用Collections.synchronizedSet(new HashSet())或new CopyOnWriteArraySet()适用于读多写少。错在哪认为TreeSet的排序只支持Comparable不支持Comparator。为什么错TreeSet有两个构造函数TreeSet()要求元素实现Comparable和TreeSet(Comparator? super E comparator)传入比较器。后者更灵活可对无Comparable的类排序。怎么答对TreeSet排序逻辑由Comparator决定若未传入则调用元素的compareTo()面试中可举例new TreeSet(Comparator.comparing(String::length))。错在哪认为LinkedList的get(int index)时间复杂度是 O(1)。为什么错LinkedList是双向链表get()需从头或尾遍历到指定索引平均时间复杂度 O(n/2) O(n)只有addFirst()、addLast()、removeFirst()、removeLast()是 O(1)。怎么答对LinkedList适合频繁首尾增删不适合随机访问若需 O(1) 随机访问应选ArrayList。6. 答题心法从“背答案”到“建模型”我的三遍过题法面试不是知识复述是思维建模。我带过的 A同学第一次模拟面试被 JVM 问题打懵回来问我“老师G1 的 Mixed GC 是啥”我反问“你家小区有 100 个快递柜每天有 20 个柜子装满快递对应 Eden 满快递员GC 线程要清空它们。但有些柜子老年代 Region里有积压半年的旧快递长期存活对象他不可能一次清空全部 100 个柜子Full GC 太慢怎么办”A同学脱口而出“分批清今天清 20 个新柜子 5 个旧柜子明天再清 20 个新 5 个旧……”——那一刻他懂了 Mixed GC 的本质增量式清理用时间换响应。从此我教所有学员用“三遍过题法”第一遍画图建模5 分钟不翻资料拿白纸画JVM 内存结构标出线程私有区PC、栈、本地方法区和线程共享区堆、元空间用不同颜色区分G1 Region画 8×8 网格标出 E、S、O、HHumongous区域箭头标出 Young GCE→S、Mixed GCESO流向HashMap 扩容画两个数组标出头插法如何形成环JDK7vs 尾插法如何避免JDK8。画错没关系画的过程就是强制建立空间关系。第二遍参数锚定3 分钟针对每个模型写下 2 个关键参数G1-XX:MaxGCPauseMillis200目标、-XX:G1HeapRegionSize1MRegion 大小HashMap-Djdk.util.HashMap.capacity16初始容量、-Djdk.util.HashMap.loadFactor0.75负载因子ArrayList-Djdk.util.ArrayList.initialCapacity10首次扩容值。参数是面试官验证你是否真懂的“指纹”背概念不如记参数。第三遍场景反推2 分钟闭眼想一个线上故障“服务 RT 突增 500ms监控显示 Full GC 频繁” → 答“先jstat -gc pid看老年代使用率是否持续 90%若是检查是否有大对象直接进老年代-XX:PretenureSizeThreshold是否过小或 CMS 并发失败JDK8 前”“CPU 100%jstack显示大量线程 BLOCKED 在HashMap.get()” → 答“JDK7 的 HashMap 头插法导致环形链表应升级 JDK8 或改用ConcurrentHashMap”。场景是答案的“氧气”没场景的答案是尸体。从那以后我每次准备面试都强制走一遍这三遍画图 → 写参数 → 想故障。不是为了押中题而是让知识长成肌肉记忆——当面试官问“G1 如何避免碎片”我不用回忆定义手指已经在空中画出 Region 移动的轨迹嘴里自然说出“标记-整理算法存活对象复制到新 Region原 Region 整块回收”。希望帮到你。本文还有配套的精品资源点击获取