跳到主要内容Java 核心技术面试知识点总结 | 极客日志Javajava算法
Java 核心技术面试知识点总结
Java 核心技术面试要点涵盖 JDK 版本演进、集合框架底层实现、多线程锁机制、JVM 内存模型与类加载、垃圾回收算法及收集器原理。重点解析 ArrayList、HashMap、ConcurrentHashMap 数据结构，synchronized 锁升级路径，堆栈内存划分，双亲委派模型，以及 CMS、G1、ZGC 等收集器的标记清理流程与写屏障策略。同时包含 Spring 基础概念与 MySQL 索引优化思路。
ServerBase0 浏览 JDK 版本进化史
这是 JDK (Java Development Kit) 自发布以来的主要版本演进时间轴。
JDK 版本线性演进图
- JDK Beta (1995): Java 概念首次亮相。
- JDK 1.0 (1996): 第一个正式版本，奠定 Java 基础。
- JDK 1.1 (1997): 引入内部类、JDBC、RMI、Bean。
- J2SE 1.2 (1998): 关键里程碑，引入 Collections 集合框架，更名为 J2SE。
- 引入 HotSpot JVM。
J2SE 1.3 (2000):
J2SE 1.4 (2002): 引入正则表达式、NIO、异常链。J2SE 5.0 (2004): 重大语法更新：泛型、枚举、注解、自动装箱、可变参数。Java SE 6 (2006): 脚本支持、JDBC 4.0。Java SE 7 (2011): 引入 try-with-resources、钻石操作符 <>、Fork/Join 框架。Java SE 8 (LTS) (2014): 革命性版本：Lambda 表达式、Stream API、新的日期时间 API。Java SE 9 (2017): 引入模块化系统 (Project Jigsaw)。Java SE 10 (2018): 局部变量类型推断 (var)。Java SE 11 (LTS) (2018): 长期支持版，完全移除 Java EE 模块，引入 HTTP Client。Java SE 12 - 16 (2019-2021): 快速迭代版，引入 Switch 表达式、Record 类型、密封类 (Sealed Classes)。Java SE 17 (LTS) (2021): 最新的主流长期支持版。Java SE 18 - 20 (2022-2023): 虚拟线程 (预览)、模式匹配。Java SE 21 (LTS) (2023): 引入 虚拟线程 (Virtual Threads)、分代 ZGC。Java SE 22 - 24 (2024-2025): 正在进行的迭代。Java SE 25 (LTS) (预计 2026): 下一个计划中的长期支持版本。关键节点总结
| 类型 | 版本号 | 说明 |
|---|
| 目前最主流 | JDK 8, JDK 11, JDK 17 | 生产环境使用率最高 |
| 最新 LTS | JDK 21 | 具备高性能并发能力 |
| 发布周期 | 每 6 个月 | 每年 3 月和 9 月发布新版本 |
Java 集合框架详解
ArrayList
- 底层结构：基于动态数组实现，维护一个 elementData[] 数组和 size 变量
- 增删查：
- add(E e)：在数组末尾插入，若容量不足则扩容（1.5 倍扩容）
- get(int index)：O(1) 时间复杂度，直接通过索引访问
- remove(int index)：O(n) 时间复杂度，删除后需移动后续元素
- 扩容机制：当 size >= capacity 时，创建新数组（原容量 + 原容量>>1），复制元素
HashMap（JDK 1.8+）
- 底层结构：数组 + 链表 + 红黑树，通过哈希值确定数组位置
- 存储过程：
- 计算 key 的 hash 值，通过 (n-1) & hash 确定数组索引
- 若该位置为空，直接插入
- 若已存在节点，比较 key 是否相等，相等则替换
- 否则遍历链表/红黑树查找
- 冲突处理：链地址法，相同 hash 值的 Entry 形成链表
- 树化条件：链表长度≥8 且数组长度≥64 时转红黑树；链表长度≤6 时转回链表
- 扩容机制：负载因子 0.75，元素数超过阈值时扩容 2 倍并 rehash
ConcurrentHashMap（JDK 1.8+）
- 实现方式：CAS + synchronized（不再使用分段锁）
- 线程安全：
- 插入时，若槽位为空使用 CAS 插入
- 若槽位不为空，使用 synchronized 锁定头节点
- 对不同槽位的操作不会相互阻塞，提高并发性
- 扩容机制：支持并发扩容，使用 transfer 机制
ConcurrentHashMap（JDK 1.7）
- 实现方式：分段锁（Segment-based locking）
- 初始化：默认创建 16 个 Segment，每个 Segment 管理数组的一部分
- 线程安全：
- 插入时，首先通过 key 的 hash 值定位到特定 Segment
- 获取该 Segment 的锁（ReentrantLock）
- 在该 Segment 内部的 HashEntry 数组中进行操作
- 操作完成后释放 Segment 锁
- 并发限制：同一 Segment 内的不同槽位操作仍会相互阻塞，但不同 Segment 间完全独立
- 并发度：最大并发写入线程数等于 Segment 数量（默认 16）
多线程：理解 synchronized 关键字的作用和用法
核心概念
synchronized 是 Java 中的关键字，用于解决多线程并发访问共享资源时的线程安全问题。它的核心目的是保证被修饰的代码块具有原子性（同时也保证了可见性和有序性）。
一、锁升级机制 (JDK 15 之前)
升级路径：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁
-
偏向锁 (Biased Lock)
- 机制：当线程第一次访问同步块时，使用 CAS 修改对象头（Mark Word），将其中的 Thread ID 指向当前线程。
- 状态：此时并没有真正'上锁'（没有互斥开销），只是打了个标记。
- 触发升级：当其他线程尝试获取该锁时，偏向模式宣告结束，触发锁升级。
-
轻量级锁 (Lightweight Lock)
- 撤销与升级：偏向锁的撤销需要等待全局安全点 (Global Safepoint)。此时 JVM 会暂停拥有偏向锁的线程，检查其状态，然后将 Mark Word 修改为指向线程栈帧中锁记录 (Lock Record) 的指针，升级为轻量级锁。
- 竞争逻辑：
- 当前线程持有锁执行。
- 后来的线程发现锁被占用，会尝试通过 CAS 将 Mark Word 替换为自己的锁记录指针。
- 膨胀：如果 CAS 失败（意味着存在竞争），且不是锁重入，当前锁就会直接膨胀为重量级锁。
-
重量级锁 (Heavyweight Lock)
- 机制：锁膨胀后，Mark Word 指向堆中的 ObjectMonitor 对象。
- 自适应自旋 (Adaptive Spinning)：在进入阻塞之前，为了避免线程挂起/唤醒（用户态与内核态切换）的高昂开销，JVM 会进行最后一次挣扎——尝试自旋（空循环）获取锁。
- 阻塞等待：如果自旋依然失败，线程会进入一个循环 (Loop) 逻辑：
- 尝试获取锁 失败
- 调用系统底层 Park 挂起资源
- 等待 OS 唤醒
- 再次尝试获取锁。
二、JDK 15 之后的变革
变化：JDK 15 默认禁用偏向锁，JDK 18 彻底废弃。
- 维护成本高：偏向锁的撤销需要进入全局安全点 (Safepoint)，导致所有线程短暂暂停 (Stop-The-World)，引入了极高的代码复杂度和运行时开销。
- 硬件红利：随着 CPU 架构升级，原子指令 (CAS) 的执行成本越来越低。
- 性价比倒挂：偏向锁'为了省一次 CAS 而引入复杂的撤销机制'，在现代硬件上收益已不如直接使用轻量级锁。
三、用法与锁对象
-
静态方法
- 锁对象：当前类的 Class 对象 (e.g., Test.class)。
- 范围：控制该类的所有实例对该静态方法的并发访问。
static synchronized void fun() {
}
-
实例方法
- 锁对象：当前实例对象 (this)。
- 范围：控制同一对象实例的并发访问，不同对象之间互不干扰。
synchronized void fun() {
}
-
代码块
- 锁对象：括号内指定的对象 (lock)。
- 范围：最灵活，根据传入的对象决定锁的粒度。
synchronized(lock) {
}
JVM 基础：知道堆、栈、方法区的基本概念（JDK 17）
一、代码启动与内存区域划分
JVM 把 java 文件编译为字节码 class 之后，会将类加载到方法区（元空间）中。这里需要补充一个关键细节：JDK 8 之后，静态变量被移动到了堆中存储。
- GC 统一管理：让垃圾回收器能统一扫描堆，回收无用的静态对象
- 避免内存泄漏：元空间回收条件苛刻，移到堆后更容易被回收
- 方法区（元空间）：只存类元数据（字节码、常量池、字段描述等）
- 堆：存 Class 对象（包含静态变量值） + 所有实例对象
class User {
static int count = 0;
static User admin = new User();
}
二、栈与栈帧结构
栈是一块连续的内存地址，当执行引擎调用一个方法时，会在栈中创建一个栈帧。这个栈帧中会创建四个区域：
1. 局部变量表
- 底层实现：是一个数组，不是栈结构
- 存储位置：变量在数组中的位置在编译时就决定了，所以能够通过 O(1) 的时间拿到
- 变量复用：JVM 会检查变量的生命周期，作用域不重叠的变量会复用同一个槽位（与变量名无关）
2. 操作数栈
是一个后进先出的数据结构，储存需要计算的变量。最大的作用是作为规范和寄存器优化：
规范作用：实现跨平台
使用栈来模拟数据之间的计算步骤，然后真正的计算又抽象为字节码执行（比如 iadd）。这个实际怎么计算是根据当前硬件架构决定的。
- 不用栈：ARM 要写成 add r0, r0, r1，x86 要写成 add eax, ebx，寄存器命名都不一样，编码为字节码就不能统一，实现不了跨平台
- 用操作数栈：抽象为 iload_0 加载、iload_1 加载、iadd 相加，具体实现由 JIT 决定。这样实现了跨平台，也解耦了具体实现
寄存器优化：最大化性能
不同架构的寄存器数量不同（x86 有 16 个，ARM 可能只有 4 个）。如果不用栈，在编译时就写死了寄存器地址，对于不同数量的寄存器就无法处理了。
而使用了栈之后：
- JIT 编译时会使用所有的寄存器
- 如果寄存器装不下了，才会放到内存的这个栈中
- 这样最大程度优化了性能
3. 索引（准确术语：动态链接）
在方法调用时，需要通过类的地址找到方法所在位置，这个信息就储存在索引中。
- 第一次调用：存储的是方法的全限定名，不是实际地址
- 找到之后：替换为实际地址
- 下次调用：直接通过地址找到方法对应的字节码
4. 返回地址
记录方法返回值的位置，还有恢复外层方法被调用前的状态，确保方法正常运行。
三、方法执行与栈帧生命周期
这几个区域，等到方法执行完毕，就会把这个栈帧从栈中弹出去。
- 执行引擎读取字节码指令
- 遇到 new 指令时，在堆中创建对象实例
- 实例化时只复制字段，方法只有一份存在方法区
- 方法返回后，栈帧销毁，局部变量表一同销毁
四、堆与垃圾回收
- 工作区域：只在堆中运行
- 回收目标：没有被 GC Roots 引用的对象
- GC Roots 包括：栈帧中的局部变量、静态变量（堆中 Class 对象引用）、活跃线程等
对象头：Mark Word(8B) + 类型指针 (8B)
实例数据：字段值
对齐填充：8 字节对齐
类型指针的作用：指向方法区中的类元数据，所有对象通过它共享同一份方法字节码，不会重复复制。
五、核心设计哲学总结
- 跨平台性：操作数栈抽象屏蔽硬件差异，JIT 负责具体实现
- 性能优化：编译时确定局部变量位置 + JIT 寄存器优化
- 自动内存管理：GC 自动回收堆中无用对象，开发者无需手动释放
- 空间效率：方法只有一份，变量复用槽位
六、验证实验
javap -v YourClass.class
java -cp jol-cli.jar org.openjdk.jol.Main internals java.lang.Object
package out;
public class Jvm {
public Jvm() {
int c = 3;
}
public static void main(String[] args) {
int a = 0;
int b = 1;
int var10000 = a + b;
}
}
Last modified 2026 年 2 月 15 日; size 450 bytes SHA-256 checksum 4e616623e230b57980210bb0867a700d5bb3ef54ad45b8c0dfc5dfc1125b3322 -- 文件物理信息（位置、大小、校验和）
Compiled from "Jvm.java"
public class out.Jvm minor version:0 major version:61 flags:(0x0021) ACC_PUBLIC, ACC_SUPER this_class:
Constant pool: ← 常量池（类的"词典"，存字符串、方法名等）
{
← 方法区开始
public out.Jvm();
← 默认构造器方法 descriptor:()V flags:(0x0001) ACC_PUBLIC Code: stack=1, locals=2, args_size=1
0: aload_0
1: invokespecial #1// Method java/lang/Object."<init>":()V
4: iconst_3
5: istore_1
6:return
LineNumberTable: line 8:0 line 9:4 line 10:6
LocalVariableTable:StartLengthSlotNameSignature
070thisLout/Jvm;
611 c I
public static void main(java.lang.String[]);
<- main 方法 descriptor:([Ljava/lang/String;)V flags:(0x0009) ACC_PUBLIC, ACC_STATIC Code: stack=2, locals=4, args_size=1
stack 方法的操作数栈的大小 -- 对应到源代码就是这样
0: iconst_0 将 a 变量 0 储存到操作数栈中
1: istore_1 将操作数栈中储存到局部变量表的第一个下标
2: iconst_1 将 b 变量 1 储存到操作数栈中
3: istore_2 将操作数栈中储存到局部变量表的第而个下标
4: iload_1 取出变量表的第一个下标 储存到操作数栈中
5: iload_2 取出变量表的第二个下标 储存到操作数栈中
6: iadd 将操作数栈中的头俩个值相加储存到操作数栈栈顶
7: istore_3 将值操作数栈顶的值变量 c 储存到变量表的第三个位置
8:return 方法结束弹出方法栈帧
LineNumberTable: line 12:0 line 13:2 line 14:4 line 15:8
LocalVariableTable:StartLengthSlotNameSignature
090 args [Ljava/lang/String;
271 a I
452 b I
813 e ISlot：变量占用的位置（物理地址）1 istore_1 Start：变量生效的起始字节码位置 Length：变量存活的长度（字节码行数）
}
SourceFile:"Jvm.java" ← 源文件信息
JVM 类加载过程 与 双亲委派模型核心梳理
class 文件加载到 JVM 中会经历以下五个主要阶段：加载 -> 验证 -> 准备 -> 解析 -> 初始化。
1. 加载 (Loading)
- 在方法区（元空间）中创建 InstanceKlass 对象，类的核心元数据（类信息、方法字节码、静态变量元数据、访问权限等）都会储存在这个对象中。
- 关键动作： 这时的 class_mirror不是空的！JVM 在创建完 InstanceKlass 后，会紧接着在 Java 堆中实例化一个代表该类的 java.lang.Class 对象。然后，原子性地将这个堆中 Class 对象的地址赋值给 InstanceKlass 的 class_mirror 指针，同时给堆中 Class 对象底层的指针赋上 InstanceKlass 的地址。这两个内存区域的类和对象在这一步就建立好了沟通桥梁。
2. 验证 (Verification)
- JVM 不会轻易相信传入的 class 文件（因为存在被恶意篡改的可能）。
- 会校验 class 文件的版本号看是否兼容。
- 验证引用格式是否正确（字段、方法、类都有其规定的内部引用格式，比如 java/lang/String）。
- 检查代码是否满足 Java 语法规范：例如方法重写是否合法、抽象类的方法是否全部被实现、是否非法继承了 final 类等不满足规范的情况。
3. 准备 (Preparation)
- 计算静态变量的指针偏移量。
- 在堆中的 java.lang.Class 对象的内存尾部，为静态变量分配内存，并给静态变量赋予零值（系统默认初始值，如 int 赋 0，对象引用赋 null）。
4. 解析 (Resolution)
- 通常伴随懒加载机制，将常量池内的符号引用转换为直接引用（内存地址指针或句柄）。
- 会检查符号引用是否可达，以及是否指向一个真实存在的类或方法。
5. 初始化 (Initialization)
- 注意：这个阶段不会再创建 Class 对象。
- JVM 会执行类构造器 () 方法。
- 底层会顺着早已绑定好的 class_mirror 指针找到堆中的 Class 对象，按照准备阶段算好的偏移量，把代码中定义的真实值赋给静态变量。
- 同时执行静态代码块（static {}）里的代码。
双亲委派模型机制
在加载类时，涉及四个主要类加载器，层级从底向上依次是：自定义加载器 -> 应用程序加载器 -> 扩展加载器 -> 启动加载器。
- 委派过程： 自定义加载器收到加载 String 类的任务，它不会自己先加载，而是委派给父类应用程序加载器 -> 继续委派给扩展加载器 -> 继续委派给启动加载器。
- 尝试加载过程： 启动加载器发现没有父类可以委派了，就开始尝试加载 String 类。如果加载成功就直接返回；如果失败，再依次交还给子类加载器去尝试加载。
- 真正的加载顺序： 启动加载器 -> 扩展加载器 -> 应用程序加载器 -> 自定义加载器。
核心结论：
咱们自己写的普通类通常是由应用程序加载器加载的；而 JVM 自带的基础核心类（比如 java.util., java.lang.）是由启动加载器加载的，它的加载优先级最高。
因此，如果你自己写了一个 java.lang.String 类，启动加载器会优先把官方自带的正牌 String 类加载进内存，你自己写的那个类永远没有机会被加载到。这就是双亲委派模型保护核心类库安全的机制！
Java 垃圾收集（GC）核心流程与可达性分析机制
1. 垃圾寻找机制概述
- 引用计数法：通过统计对象被引用的次数来判定垃圾。由于存在循环引用（例如对象 A 和 B 互相引用，但均未被程序其他部分使用，导致计数器永远不为 0）的致命缺陷，Java 虚拟机（HotSpot JVM）并没有采用此算法。
- 可达性分析算法（Reachability Analysis）：现代主流 GC 均采用此算法。它以 GC Roots（垃圾收集根节点，如当前运行线程的方法栈帧中的局部变量、静态变量等）为起点，向下遍历引用树。能遍历到的对象即为存活，遍历不到的即为垃圾。
2. GC 的完整执行流程
当堆内存使用量达到特定阈值时，将触发 GC 流程，具体经历以下核心阶段：
- 第一阶段：初始标记（Initial Mark）
系统触发 STW（Stop-The-World，即暂停所有用户业务线程）。此时只扫描与 GC Roots 直接相连的对象，将它们标记为灰色，并放入广度优先遍历（BFS）的待处理队列中。此阶段耗时极短。
- 第二阶段：并发标记（Concurrent Mark）
GC 标记线程与用户业务线程并发（同时/交替）运行。GC 从 BFS 队列中的灰色节点出发，基于三色标记法遍历引用树：
- 白色：尚未被遍历到的对象（若标记结束时仍为白色，则被认定为垃圾）。
- 灰色：对象已被遍历，但其内部的子引用尚未被完全遍历（当前处于 BFS 队列中）。
- 黑色：对象及其所有子引用均已被完全遍历，确认存活。
- 第三阶段：漏标风险与写屏障（Write Barrier）干预
在并发标记期间，由于用户线程在动态修改引用，可能导致对象消失（活对象被当成垃圾漏标）。发生此问题必须同时满足两个条件：1. 黑色对象新增了对白色对象的引用；2. 灰色对象断开了对该白色对象的引用。
为了在并发环境下根治此问题，JVM 引入了写屏障技术，具体分为两种核心策略：
- 增量更新（Incremental Update，CMS 收集器使用）：破坏条件 1。当黑色对象引用白色对象时，将其记录下来。在并发标记结束后，统一将这些黑色对象降级为灰色，并重新遍历其子节点。
- 原始快照（SATB，G1 收集器使用）：破坏条件 2。当灰色对象断开对白色对象的引用时，立刻将该旧的白色对象记录下来，并直接升级为灰色放入处理队列。G1 会在并发运行期间不断消费这个队列，提前将这部分白色对象消化掉。
- 第四阶段：最终标记 / 重新标记（Final Mark）
并发标记结束后，再次触发短暂的 STW。此阶段主要用于处理写屏障遗留的最后少量数据，例如 G1 集中消化 SATB 队列的残余记录，或 CMS 集中处理记录下来的黑色对象，确保标记的绝对准确。
- 第五阶段：清理与回收（Sweep / Evacuation）
在明确区分出存活对象和垃圾对象后，正式回收所有未被引用的白色对象所占用的内存。
3. 总结与应用演进
原始快照（SATB）机制通过在并发阶段'边记录边消化'数据，大幅减少了最终重新标记阶段的 STW 停顿时间。得益于这种高效的设计，G1 收集器从 JDK 9 开始正式取代了此前的收集器，成为了 Java 官方的默认垃圾收集器，这也是目前业界最主流的选择。
该核心机制在 JVM 的发展史上有着非常明确的阵营划分。具体到 Java 的各大垃圾收集器，它们对这套机制的选用情况如下：
1. 增量更新（Incremental Update）的使用者
- 唯一代表收集器：CMS（Concurrent Mark Sweep）
- 技术细节：CMS 是 JVM 历史上第一款真正意义上的并发收集器。它采用了写后屏障（Post-Write Barrier）来实现增量更新。当用户线程在并发阶段把一个白色对象的引用赋值给黑色对象时，写后屏障会把这个黑色对象记录下来。在最终的重新标记（Remark）阶段，CMS 必须 STW，然后把这些记录下来的黑色对象当作根节点，重新向下扫描一遍。
- 致命弱点：由于需要重新向下深度扫描，这就导致了 CMS 的 Remark 阶段停顿时间往往比较长，且不可预测。这也是它后来被 G1 淘汰的核心原因之一。
2. 原始快照（SATB）的使用者
- 代表收集器：G1（Garbage-First）与 Shenandoah
- G1 收集器：正如我们之前深入探讨的，G1 使用了写前屏障（Pre-Write Barrier）结合 SATB 算法。它不需要在最终标记阶段重新深度扫描对象图，只需要把 SATB 缓冲区里记录的旧引用（那些被断开的白色对象）直接标记为存活即可。这种'只看历史快照，不深度重扫'的策略，极大缩短了最终标记的 STW 时间。
- Shenandoah 收集器：这是由 Red Hat 开发的一款超低延迟收集器（在 OpenJDK 12 成为正式特性，参考官方文档 JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector）。它的并发标记阶段同样完全沿用了 SATB 算法和写前屏障来解决漏标问题。
3. 扩展视野：跳出'写屏障'的新流派
除了上述两种主流方案，现代 JVM 还有一种更前沿的收集器，它完全抛弃了写屏障和这套复杂的记录队列：
- 代表收集器：ZGC（Z Garbage Collector）
- 核心技术：读屏障（Load Barrier） + 染色指针（Colored Pointers）。
- 技术细节：ZGC 不在对象属性被'写入/修改'时做拦截，而是在业务线程试图'读取'一个对象指针时做拦截。ZGC 把对象的标记状态（是不是垃圾、有没有被移动过）直接存放在了指针的几位二进制位上（这就是染色指针）。当业务线程读到一个指针，读屏障会检查指针的颜色，如果发现这个对象正在被 GC 处理，读屏障会顺手帮忙把指针更新到正确的地址再返回给业务线程。这种极度硬核的底层设计，让 ZGC 能把停顿时间压缩到惊人的 1 毫秒以内（JDK 16+ 版本）。
4. 为什么有些收集器根本不用这些？
- 代表收集器：Serial, Parallel Scavenge, Parallel Old
- 原因：这些传统的收集器在进行垃圾标记和清理时，采用的是全程绝对 STW（Stop-The-World）的策略。在它们工作的期间，所有的用户业务线程都被死死冻结了。既然没有业务线程在运行，对象之间的引用关系就是一潭死水，绝对不可能发生'黑色对象突然指向白色对象'这种并发修改的情况。因此，它们根本不需要考虑'漏标'问题，也就不需要引入增量更新或 SATB 任何一种复杂的屏障机制。
G1（Garbage-First）总结定稿
- JDK 7 引入，JDK 9+ 成为默认收集器
- 核心重构：将堆划分为等大小 Region（1~32MB，2 的幂），逻辑分代（Eden/Survivor/Old 由 Region 动态扮演），以 Region 为最小回收单元实现可预测停顿时间（Soft Real-Time）
一、宏观回收流程（5 步框架）
| 步骤 | 阶段 | 关键动作 |
|---|
| 1 | 触发 | Eden 区满（受 GCLocker 或分配速率影响） |
| 2 | 标记 | 双轨制独立触发： |
| • 路线 A（Young GC）：纯 STW 快速标记 Eden+Survivor | | |
| • 路线 B（并发标记）：Old 区达到触发阈值（IHOP）时，后台启动并发标记（SATB + TAMS + 写屏障）→ Initial Mark STW → Concurrent Mark → Remark STW → Cleanup STW | | |
| 3 | 统计（Cleanup） | 计算高价值 Old Region：活对象占比 ≤ 85%（即可回收垃圾 ≥ 15%）且按垃圾量 / RSet 大小排序，生成候选回收集（不移动对象） |
| 4 | 决策 | 检查 G1HeapWastePercent（默认 5%）：若候选垃圾占整个堆比例 > 5%，则升级为 Mixed GC；否则退化为 Young GC |
| 5 | 回收（STW） | 复制存活对象 → 通过 RSet 更新外部引用者指针 → 清空 Region → 归还空闲列表 |
二、核心细节校准
1. Eden 区动态调控
- 动态长度限制：List_max_eden_length（Young List 长度限制）控制可分配 Eden Region 数量（非固定 60% 堆空间）。
- 自适应调整：若 Young GC 实际停顿 > MaxGCPauseMillis，动态缩小 Eden 长度，降低下次 GC 负荷。
2. 标记阶段：双轨制（独立触发，非并行）
路线 A（Young GC 标记）：Eden 满 → STW → 快速标记 Eden+Survivor → 立即复制回收（无 SATB/TAMS）
路线 B（并发标记周期）：Old 占比达到 IHOP（JDK 9+ 默认开启 Adaptive IHOP，根据对象分配速率和标记真实耗时动态计算阈值，不再死守 45%） → 后台线程启动
1. Initial Mark（STW）：扫描 GC Roots，启动 SATB
2. Concurrent Mark：并发遍历 Old 对象图，配合 TAMS 指针（Top-at-Mark-Start）防止漏标新分配对象
3. Remark（STW）：处理 SATB 队列，完成最终标记
4. Cleanup（STW）：统计垃圾分布，生成候选名单（不回收对象）
3. Mixed GC 升级条件（精确版）
- 阈值：-XX:G1HeapWastePercent=5（垃圾占整个 Java 堆的比例，非 CSet）。
- 时间预测模型：
预测停顿 = Young GC 基线 + (Old Region 平均耗时 × 选取数量) + 安全余量（1~2×标准差）
若 Young GC 基线本身 ≥ MaxGCPauseMillis，则强制退化为 Young GC（Old Region 留待下次）。
4. Mixed GC 次数：目标 8 次（软性）
- 参数：G1MixedGCCountTarget=8（仅目标值，非承诺）。
- 实际行为：每次 Eden 满时重新评估，若时间预算不足或候选集垃圾占比已降至 5% 以下，会提前结束 Mixed 周期，切回纯 Young GC。
5. RSet 更新机制（修正）
- 误区：'修改 RSet 中的地址'。
- 正解：扫描 CSet Region 的 RSet（Remembered Set） → 定位外部引用者所在 Region → 读取外部引用者对象字段 → 修改该字段的指针（使其指向存活对象复制后的新地址）。
6. 巨型对象（Humongous Objects）的特殊待遇
- 定义：大小超过单个 Region 容量 50% 的对象。
- 分配机制：不进入 Eden 区，直接分配在连续的 Humongous Region 中（逻辑上属于 Old 区）。
- 提前回收（Eager Reclaim）：G1 在执行 Young GC 时，若通过 RSet 发现巨型对象已无外部引用，会顺手将其直接回收，无需等待并发标记周期或 Mixed GC，极大降低了老年代的空间压力。
三、可预测停顿的基石与终极兜底
G1 通过以下机制实现软实时（Soft Real-Time）目标：
- 细粒度回收单元：Region 级回收，可精确控制单次 GC 工作量。
- 动态 Eden 调控：根据历史停顿自适应调整年轻代大小。
- 时间预测模型：基于衰减标准差（Decaying Standard Deviation）计算安全余量，宁可少回收也不超时。
- Mixed GC 速率控制：将 Old 区回收分摊到多次 GC 周期，避免单次长时间停顿。
- 常态代价：RSet 维护开销（写屏障运行税）、更高的内存占用（约 10-20% 堆空间用于元数据）、更复杂的 CPU 调度。
- 极端兜底（Full GC）：当对象分配速率极快，导致 Young/Mixed GC 复制存活对象时找不到空闲 Region（To-space Exhaustion / 晋升失败），G1 会撕毁可预测停顿契约，退化为全局绝对 STW 的 Full GC。
(注：从 JDK 10 开始，该兜底机制被重构为并行多线程执行（Parallel Full GC），大幅缩短了死亡停顿时间。)
其他技术点
第二步：框架原理
- Spring：先理解什么是依赖注入（IoC）和面向切面编程（AOP）
- Spring Boot：了解它是如何简化 Spring 配置的
第三步：数据库优化
- MySQL：掌握基本的索引概念和 SQL 优化思路
微信扫一扫，关注极客日志
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
相关免费在线工具
- Keycode 信息
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
- Escape 与 Native 编解码
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
- JavaScript / HTML 格式化
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
- JavaScript 压缩与混淆
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
- 加密/解密文本
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
- Base64 字符串编码/解码
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
