类加载子系统是jvm中负责将.class字节码加载到内存、验证链接并初始化的准入机构，其过程包括加载（生成class对象和元数据）、链接（验证、准备、解析）和初始化（执行方法），最终所有类信息存于方法区（jdk 8+为元空间）。
JVM 是 Java 程序运行的底层支撑环境，它的整体架构不是一堆抽象概念，而是一套分工明确、各司其职的子系统组合。理解它，关键不在于死记结构图，而在于看清“代码怎么进来、数据存在哪、指令怎么跑、对象怎么活又怎么死”这个完整链条。
类加载子系统：字节码的“准入机构”
Java 源文件（.java）编译成 .class 字节码后，并不能直接执行，必须由类加载器子系统完成三步落地：
-
加载：根据类的全限定名找到字节码，读入内存，在方法区生成类元数据结构，并在堆中创建一个
java.lang.Class对象作为访问入口； -
链接：分验证（确保字节码符合规范）、准备（为静态变量分配内存并设默认值，如
int x初值为 0）、解析（把符号引用转成真实内存地址）； -
初始化：真正执行
<clinit>()</clinit>方法，给静态变量赋代码里写的初始值，运行静态代码块。
这个过程决定了哪些类能进 JVM、以什么形式存在——所有类信息最终都沉淀在方法区（JDK 8+ 是元空间）。
运行时数据区：内存的“功能分区”
这是 JVM 运行中实际使用的内存布局，严格按《Java 虚拟机规范》划分为 5 个区域，核心区分是“谁用”和“归谁管”：
-
线程私有区（每个线程一份，互不干扰）：
-
程序计数器：记录当前线程正在执行的字节码指令地址；Native 方法中为空；它是唯一不会抛
OutOfMemoryError的区域； -
Java 虚拟机栈：方法调用时压入栈帧，存局部变量、操作数栈、动态链接等；栈深度超限抛
StackOverflowError，空间不足可能 OOM； - 本地方法栈：专为 JNI 调用的 C/C++ 方法服务，行为类似虚拟机栈，只是对象不同。
-
程序计数器：记录当前线程正在执行的字节码指令地址；Native 方法中为空；它是唯一不会抛
-
线程共享区（所有线程共用，GC 和 OOM 主战场）：
-
堆（Heap）：所有 new 出来的对象和数组都在这里；JDK 8 后逻辑上分新生代（Eden + Survivor From/To）和老年代；GC 主要发生地；最常触发
OutOfMemoryError: Java heap space； -
方法区 / 元空间：存储类结构、常量池、静态变量、JIT 编译后的代码；JDK 8 开始，永久代被移除，改用元空间（Metaspace），它位于本地内存（直接内存），不再受 JVM 堆大小限制，但仍有上限，超限会抛
OutOfMemoryError: Metaspace。
-
堆（Heap）：所有 new 出来的对象和数组都在这里；JDK 8 后逻辑上分新生代（Eden + Survivor From/To）和老年代；GC 主要发生地；最常触发
执行引擎与本地接口：让字节码真正动起来
类加载完成后，字节码就绪，接下来靠执行引擎驱动：
- 解释器：逐条读取、翻译、执行字节码，启动快但效率低；
- 即时编译器（JIT）：对热点代码（频繁执行的方法）编译成本地机器码，缓存复用，大幅提升执行速度；
- 垃圾收集器（GC）：不是独立引擎，而是执行引擎的一部分协同机制，专门管理堆和方法区中不再使用的对象和类元数据；
- 本地方法接口（JNI）：提供桥梁，让 Java 代码能调用操作系统或硬件级的 C/C++ 函数，本地方法栈就是为其服务的。
直接内存：虽不在规范内，却很关键
它不属于 JVM 运行时数据区，但被 NIO 的 DirectByteBuffer 频繁使用。这部分内存由操作系统直接分配，绕过 JVM 堆，速度快但需手动管理。如果大量使用且未及时清理，也会引发 OutOfMemoryError，错误提示常带 “unable to create new native thread” 或 “Direct buffer memory”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
