简介这份PDF资料面向Java后端开发者与求职面试人群系统梳理Java核心知识中的高频考点帮助读者在面试前快速回顾JVM、集合、多线程、设计模式等常考内容。资源为单个PDF文件压缩包约10.71MB内容以文字与目录结构为主便于按章节检索和打印复习。目录从JVM展开涵盖线程、JVM内存区域程序计数器、虚拟机栈、本地方法区、堆、方法区、JVM运行时内存新生代Eden区、ServivorFrom、ServivorTo、MinorGC复制清空互换流程、老年代、永久代及Java8元数据等模块并延伸至Java语法、集合框架、多线程与设计模式等后续知识点。已有646人学习下载适合需要集中突破八股文、构建知识框架的初中级开发者对照查漏补缺。1. Java核心知识整理为什么面试官总在JVM和并发这两块反复追问工作五年以上的Java工程师简历上写“精通Java”的不少但真到面试环节被问到JVM内存模型和并发编程细节时能答利索的比例并不高。这不是知识储备不够而是大多数人的知识是“用出来的”——平时写业务代码Spring帮你管了对象生命周期线程池帮你管了线程调度你很少需要直接面对OutOfMemoryError或者死锁。但面试官恰恰喜欢在这些“你平时不直接碰、但出了问题就是大问题”的地方深挖因为这里能区分出“会用Java”和“懂Java”的人。这份整理面向两类人一是准备跳槽、需要系统梳理Java核心知识点的开发者二是工作几年后发现自己对Java底层机制理解模糊、想补课的一线工程师。内容覆盖JVM内存结构与垃圾回收、并发编程核心机制、集合框架源码要点、以及高频“八股文”背后的真实原理。不堆砌概念每个知识点都落到“面试怎么问、代码怎么写、参数怎么调、坑在哪”这四个维度上。2. JVM内存结构与垃圾回收从对象分配到GC调优的完整链路2.1 运行时数据区到底怎么划分哪些区域会OOMJVM运行时数据区分为线程私有和线程共享两大部分。线程私有的包括程序计数器、虚拟机栈、本地方法栈线程共享的包括堆和方法区JDK 8之后方法区的实现叫元空间Metaspace。程序计数器是唯一不会抛OutOfMemoryError的区域它记录当前线程执行的字节码行号。虚拟机栈描述的是Java方法执行的内存模型每个方法执行时创建一个栈帧栈帧里存局部变量表、操作数栈、动态链接、方法出口等信息。栈深度超限抛StackOverflowError常见于递归调用没有正确终止条件。堆和方法区内存不足则抛OutOfMemoryError。JDK 8之后永久代被元空间取代元空间使用本地内存默认不限制大小但可以通过-XX:MaxMetaspaceSize控制。这意味着以前永久代OOM的场景比如动态生成大量类现在变成了元空间OOM排查思路类似但参数不同。// 模拟栈溢出递归没有终止条件 public class StackOverflowDemo { private static int depth 0; public static void recursive() { depth; recursive(); // 无限递归最终抛StackOverflowError } public static void main(String[] args) { try { recursive(); } catch (StackOverflowError e) { System.out.println(栈深度: depth); // 输出实际达到的深度 } } }这段代码用来观察栈深度。默认栈大小通常是512KB到1MB取决于平台和JVM版本可以通过-Xss调整。每个栈帧的大小取决于局部变量表大小和操作数栈深度。实际面试中常问“栈帧里有什么”答出局部变量表、操作数栈、动态链接、返回地址这四个核心部分就够了。堆是GC的主战场。对象优先在Eden区分配当Eden区没有足够空间时触发Minor GC。大对象直接进入老年代可以通过-XX:PretenureSizeThreshold设置阈值但这个参数只对Serial和ParNew收集器有效。长期存活的对象晋升到老年代晋升年龄阈值由-XX:MaxTenuringThreshold控制默认15。动态年龄判定规则是如果Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半年龄大于或等于该年龄的对象直接进入老年代。2.2 垃圾回收算法与收集器选型CMS、G1、ZGC怎么选标记-清除、标记-复制、标记-整理是三种基础算法。标记-清除产生内存碎片标记-复制浪费一半空间但效率高标记-整理没有碎片但移动对象成本高。实际JVM实现是这三种算法的组合。Serial收集器是单线程的进行GC时必须暂停所有用户线程Stop The World。ParNew是Serial的多线程版本主要配合CMS使用。Parallel Scavenge关注吞吐量适合后台计算型任务。CMS以最短停顿时间为目标使用标记-清除算法会产生内存碎片当碎片过多时退化为Serial Old造成长时间停顿。G1把堆分成多个Region整体是标记-整理局部是标记-复制可以预测停顿时间。ZGC和Shenandoah追求极低停顿10ms以内使用染色指针和读屏障实现并发整理。选型建议堆内存小于4G、追求低延迟可以用CMS堆内存大于6G、希望可控停顿用G1对停顿极其敏感比如实时交易系统考虑ZGC。但ZGC在JDK 15之前是实验特性生产环境使用需要评估版本。# 常用GC参数组合示例 # 使用G1收集器目标最大停顿200ms堆大小4G java -XX:UseG1GC -XX:MaxGCPauseMillis200 -Xms4g -Xmx4g -jar app.jar # 使用CMS收集器老年代使用CMS新生代使用ParNew java -XX:UseConcMarkSweepGC -XX:UseParNewGC -Xms2g -Xmx2g -jar app.jar # 打印GC日志JDK 9之前 java -XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:gc.log -jar app.jar # JDK 9统一日志格式 java -Xlog:gc*:filegc.log:time,uptime,level,tags -jar app.jar参数说明-XX:MaxGCPauseMillis是G1的目标停顿时间不是硬性保证G1会尽量达成但可能失败。-Xms和-Xmx设为相同值可以避免堆动态扩容带来的额外开销。GC日志分析时重点关注Full GC频率和耗时如果Full GC频繁且每次回收效果差可能是内存泄漏。2.3 一个内存泄漏排查的完整过程内存泄漏的典型表现是老年代占用持续上升Full GC后回收效果不明显。排查步骤先用jps找到进程ID然后用jstat -gcutil pid 1000观察GC频率和各区域使用率。如果老年代使用率在Full GC后仍然很高用jmap -dump:formatb,fileheap.bin pid导出堆快照再用MAT或JVisualVM分析支配树找到占用最大的对象和引用链。// 一个典型的内存泄漏场景静态集合持有对象引用 public class MemoryLeakDemo { private static final Listbyte[] CACHE new ArrayList(); public void addToCache() { while (true) { CACHE.add(new byte[1024 * 1024]); // 每次添加1MB永不释放 } } }这段代码模拟静态集合导致的内存泄漏。静态变量的生命周期与类相同如果集合只增不减对象永远无法被回收。解决方法是使用WeakHashMap或者定期清理或者改用Guava Cache并设置过期时间。面试中常问“ThreadLocal为什么会内存泄漏”原理类似ThreadLocalMap的key是弱引用但value是强引用如果线程池中的线程长期存活且没有调用remove()value就会一直存在。3. 并发编程核心机制从synchronized到AQS的底层逻辑3.1 synchronized锁升级过程与Monitor机制synchronized的锁状态分为无锁、偏向锁、轻量级锁、重量级锁。偏向锁在JDK 15之后默认禁用JDK 18之后移除所以面试中如果问偏向锁可以提一下这个变化。轻量级锁通过CAS自旋尝试获取锁适合竞争不激烈的场景。重量级锁依赖操作系统的互斥量线程阻塞和唤醒需要用户态到内核态切换开销大。Monitor是synchronized的底层实现每个对象都有一个Monitor与之关联。当线程进入同步代码块时执行monitorenter指令尝试获取Monitor的所有权退出时执行monitorexit释放。Monitor内部有EntryList、WaitSet、Owner等结构。竞争失败的线程进入EntryList阻塞调用wait()的线程进入WaitSet等待被notify()唤醒。public class SynchronizedDemo { private final Object lock new Object(); private int count 0; public void increment() { synchronized (lock) { // monitorenter count; } // monitorexit } // 等价写法同步方法 public synchronized void decrement() { count--; } }字节码层面同步代码块编译出monitorenter和monitorexit指令同步方法通过方法访问标志ACC_SYNCHRONIZED实现。面试中常问“synchronized和ReentrantLock的区别”核心区别是synchronized是JVM层面实现自动释放锁ReentrantLock是JDK层面实现需要手动释放但支持公平锁、可中断、超时获取、条件变量等高级功能。3.2 AQS原理与ReentrantLock源码要点AQSAbstractQueuedSynchronizer是并发包的核心基础类ReentrantLock、Semaphore、CountDownLatch都基于它实现。AQS内部维护一个volatile int类型的state变量和一个FIFO双向队列。state的含义由子类定义ReentrantLock中state表示重入次数Semaphore中state表示可用许可数。ReentrantLock的公平锁和非公平锁区别在tryAcquire的实现。非公平锁直接CAS尝试修改state失败才进入队列公平锁先检查队列中是否有前驱节点有则直接排队。非公平锁吞吐量更高但可能导致线程饥饿。// 用AQS实现一个简单的不可重入锁 public class SimpleLock extends AbstractQueuedSynchronizer { Override protected boolean tryAcquire(int arg) { // CAS将state从0改为1 if (compareAndSetState(0, 1)) { setExclusiveOwnerThread(Thread.currentThread()); return true; } return false; } Override protected boolean tryRelease(int arg) { if (getState() 0) throw new IllegalMonitorStateException(); setExclusiveOwnerThread(null); setState(0); // 释放锁 return true; } public void lock() { acquire(1); } public void unlock() { release(1); } }这段代码展示了AQS的核心用法继承并重写tryAcquire和tryRelease用acquire和release作为对外接口。acquire方法会先调用tryAcquire失败后把线程包装成Node加入队列并阻塞。release成功后会唤醒队列中的后继节点。面试中常问“AQS的队列是双向还是单向”答案是双向链表因为需要从尾部添加节点、从头部唤醒节点同时节点需要知道前驱节点来判断是否应该阻塞。3.3 线程池参数设置与拒绝策略选择ThreadPoolExecutor的七个核心参数corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。执行流程是任务提交时如果当前线程数小于corePoolSize直接创建新线程执行如果线程数达到corePoolSize任务进入workQueue如果队列满了且线程数小于maximumPoolSize创建新线程如果队列满了且线程数达到maximumPoolSize执行拒绝策略。// 一个适合IO密集型任务的线程池配置 ThreadPoolExecutor executor new ThreadPoolExecutor( 8, // corePoolSize: CPU核数 * 2 16, // maximumPoolSize: 峰值扩容 60L, TimeUnit.SECONDS, // 空闲线程存活时间 new LinkedBlockingQueue(200), // 有界队列避免OOM new ThreadFactory() { private final AtomicInteger counter new AtomicInteger(1); Override public Thread newThread(Runnable r) { Thread t new Thread(r, biz-pool- counter.getAndIncrement()); t.setDaemon(false); return t; } }, new ThreadPoolExecutor.CallerRunsPolicy() // 调用者执行起到背压作用 );参数说明IO密集型任务corePoolSize可以设为CPU核数乘以2因为IO等待时CPU可以切换执行其他线程。队列必须用有界队列LinkedBlockingQueue不指定容量时默认是Integer.MAX_VALUE任务积压会导致OOM。拒绝策略中CallerRunsPolicy让提交任务的线程自己执行能减缓任务提交速度。AbortPolicy直接抛异常适合需要感知拒绝的场景。DiscardOldestPolicy丢弃最老的任务适合允许丢弃的场景。4. 集合框架与高频八股HashMap、ConcurrentHashMap的源码细节4.1 HashMap的put流程与扩容机制HashMap的底层结构是数组链表红黑树。put流程计算key的hash值(h key.hashCode()) ^ (h 16)然后(n - 1) hash得到数组下标。如果该位置为空直接插入如果不为空遍历链表或红黑树找到相同key则覆盖否则尾插。当链表长度达到8且数组长度达到64时链表转为红黑树当红黑树节点数降到6时退化为链表。扩容机制当元素数量超过阈值容量乘以负载因子默认0.75时容量翻倍。扩容时重新计算每个元素的位置JDK 8之后采用高低位拆分不需要重新计算hash效率更高。// HashMap的hash计算和下标定位 static final int hash(Object key) { int h; return (key null) ? 0 : (h key.hashCode()) ^ (h 16); } // 下标计算n是数组长度必须是2的幂 // index (n - 1) hashhash方法把高16位和低16位异或是为了让高位也参与运算减少碰撞。数组长度必须是2的幂这样(n-1) hash等价于hash % n但位运算效率更高。面试中常问“为什么负载因子是0.75”这是空间和时间成本的折中太高容易碰撞太低浪费空间。4.2 ConcurrentHashMap的线程安全实现JDK 7的ConcurrentHashMap使用分段锁把整个Map分成多个Segment每个Segment独立加锁。JDK 8之后改为CASsynchronized锁粒度细化到每个数组槽。put操作时如果槽为空用CAS插入如果不为空用synchronized锁住头节点然后遍历插入。// ConcurrentHashMap的putVal核心逻辑简化 final V putVal(K key, V value, boolean onlyIfAbsent) { if (key null || value null) throw new NullPointerException(); int hash spread(key.hashCode()); for (NodeK,V[] tab table;;) { NodeK,V f; int n, i, fh; if (tab null || (n tab.length) 0) tab initTable(); // 懒初始化 else if ((f tabAt(tab, i (n - 1) hash)) null) { if (casTabAt(tab, i, null, new NodeK,V(hash, key, value))) break; // CAS成功插入完成 } else if ((fh f.hash) MOVED) tab helpTransfer(tab, f); // 协助扩容 else { synchronized (f) { // 锁住头节点 // 遍历链表或红黑树插入 } } } addCount(1L, binCount); // 更新计数可能触发扩容 return null; }关键点ConcurrentHashMap不允许null键和null值因为无法区分“不存在”和“值为null”。size()方法返回的是估计值因为并发环境下精确计数代价太高。扩容时支持多线程协助迁移每个线程负责一部分槽位。4.3 ArrayList与LinkedList的选型边界ArrayList基于数组支持随机访问尾部插入效率高中间插入需要移动元素。LinkedList基于双向链表头尾插入效率高随机访问需要遍历。大多数场景下ArrayList更优因为CPU缓存对数组更友好。只有在频繁在头部插入且数据量大的场景LinkedList才有优势。// ArrayList扩容每次扩容为原来的1.5倍 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); }面试中常问“ArrayList的默认容量是多少”答案是10但注意这个容量是在第一次add时才分配的不是构造时。ensureCapacity可以在批量添加前手动扩容减少多次扩容的开销。5. 避坑与排查Java核心知识面试中的五个高频翻车点5.1 把“String不可变”答成“final修饰”现象面试官问String为什么不可变回答“因为String类被final修饰”。原因final修饰类只表示不能被继承不代表对象状态不可变。String的不可变性来自内部private final char[] valueJDK 9之后是byte[]以及所有修改方法都返回新对象。解决答出“final类final数组不提供修改数组元素的方法”三个层面。5.2 线程池用了无界队列导致OOM现象线上服务运行一段时间后频繁Full GC最终OOM。原因创建线程池时用了new LinkedBlockingQueue()默认容量是Integer.MAX_VALUE任务积压导致内存耗尽。解决改用有界队列并设置合理容量配合CallerRunsPolicy或自定义拒绝策略。排查时用jstack看线程池状态用jmap看队列中积压的任务对象。5.3 HashMap并发扩容导致死循环JDK 7现象多线程环境下HashMap的CPU使用率飙升到100%。原因JDK 7的HashMap在扩容时采用头插法多线程同时扩容可能导致链表形成环。解决并发场景使用ConcurrentHashMap。JDK 8之后改为尾插法死循环问题不再出现但并发下仍可能丢失数据。5.4 ThreadLocal没有remove导致内存泄漏现象线程池中的线程复用ThreadLocal中存储的大对象一直不释放。原因ThreadLocalMap的key是弱引用但value是强引用线程长期存活时value无法回收。解决使用完ThreadLocal后必须在finally块中调用remove()。排查时用jmap导出堆快照查找ThreadLocalMap$Entry对象。5.5 误用subList导致原集合被修改现象对ArrayList调用subList得到子列表后修改子列表导致原列表也变化。原因subList返回的是原列表的视图不是独立副本。解决如果需要独立列表用new ArrayList(list.subList(...))创建副本。这个坑在面试中常以“subList和substring的区别”形式出现。6. 用JMH做微基准测试验证你对Java核心知识的理解是否准确面试中经常需要比较不同实现的性能比如“String拼接用还是StringBuilder”“ArrayList和LinkedList谁更快”。凭感觉回答容易翻车用JMHJava Microbenchmark Harness做基准测试才能得到可靠结论。import org.openjdk.jmh.annotations.*; import org.openjdk.jmh.runner.Runner; import org.openjdk.jmh.runner.options.Options; import org.openjdk.jmh.runner.options.OptionsBuilder; import java.util.concurrent.TimeUnit; BenchmarkMode(Mode.AverageTime) OutputTimeUnit(TimeUnit.NANOSECONDS) State(Scope.Thread) Warmup(iterations 3, time 1) Measurement(iterations 5, time 1) Fork(1) public class StringConcatBenchmark { private String a hello; private String b world; Benchmark public String testPlus() { return a b; // 编译后实际使用StringBuilder } Benchmark public String testStringBuilder() { return new StringBuilder().append(a).append(b).toString(); } public static void main(String[] args) throws Exception { Options opt new OptionsBuilder() .include(StringConcatBenchmark.class.getSimpleName()) .build(); new Runner(opt).run(); } }参数说明Warmup做预热让JIT编译器充分优化代码Measurement做实际测量Fork指定fork的JVM进程数避免进程间干扰。BenchmarkMode(Mode.AverageTime)表示测量平均耗时。运行后会输出每次操作的平均纳秒数对比两种实现的差异。JMH的使用有几个关键点不要在测试方法里写循环JMH会自动迭代用State管理测试状态避免死代码消除JMH会自动处理返回值。如果测试结果和预期不符先检查是否触发了JIT的常量折叠或方法内联。我自己的习惯是面试前把常问的性能对比点用JMH跑一遍记住数量级差异而不是具体数字。比如StringBuilder比快多少取决于循环次数和字符串长度但通常在一个数量级以内。这样回答时既能给出结论又能说明测试条件比背答案更有说服力。希望帮到你。本文还有配套的精品资源点击获取