1. JVM 内存区域划分

程序计数器（空间比较小）。保存了下一条要执行的指令的地址（指向元数据区指令的地址）
堆。JVM 最大的空间，new 出来的对象都在堆上
栈。函数中的局部变量，函数的形参，函数之间的调用关系都存放在栈上。栈也可以分为 Java 虚拟机栈和本地方法栈，Java 虚拟机栈主要服务于 Java 方法的执行，而本地方法栈主要服务于本地方法（C/C++实现的方法）
元数据区（方法区）。存放 Java 程序中的指令（指令都是包含在类的方法中），也就是保存了代码中涉及到类的相关信息，同时也保存了类的 static 属性

在一个 Java 进程中，元数据区和堆是只有一份的，程序计数器和栈可能有多份（当一个 Java 进程中有多个线程的时候，每个线程都有自己的程序计数器和栈，因为每个需要记录自己接下来需要执行什么指令还有其中的函数调用关系），由于堆和元数据区是共用一份的，所以如果是在堆上 new 了一个对象，或是元数据区的一个 static 属性，每一个线程都可以访问。

来看下面创建的变量都处在哪个内存区域：

一个变量处在哪个内存区域和变量是不是“内置类型”无关，而是和变量的形态有关

局部变量：栈成员变量：堆静态成员变量：元数据区（方法区）

所以说 a,b在堆区 c,d 在方法区，e,f 在元数据区（方法区）

2. JVM 类加载的过程

我们平时写的 Java 代码是一个 .java 文件，通过 javac 编译成 .class 文件，既然是文件，那么都是存储在硬盘上的，当运行 Java 进程的时候，JVM 就需要读取 .class 中的内容，并且执行里面的指令，这就是类加载的过程，也就是把类涉及到的字节码从硬盘上读取到内存中（元数据区）， .class 中的指令转变为类对象，类对象中就包含了 .class 文件的各种信息，比如：类的名字，类中定义的属性，方法，实现的接口和继承关系等。

下面介绍一下类加载的具体过程：

2.1. 加载

加载。找到对应的 .class 文件，通过类的全限定名打开并读取文件内容，获取定义此类的二进制字节流。

2.2. 验证

验证。验证是确保 Class 文件的字节流中包含的信息符合当前 JVM 的要求，在 Java 标准文档中，也明确定义了 Class 文件的格式

2.3. 准备

准备。准备阶段是正式为类中被 static 修饰的变量（类变量）在方法区中分配内存空间的，这些类变量在整个类的生命周期中都是有效的，并且被所有的实例对象所共享，根据上面读取到的内容来确定出需要的内存空间，然后申请内存空间，并把空间内所有的内容都初始化为 0 。

例如，对于 public static int value = 10;，在准备阶段，value 会被初始化为 0，而不是 10。真正的赋值 10 是在初始化阶段进行的。

2.4. 解析

解析。主要是针对类中的字符串常量进行处理，JVM 将常量池中的符号引用替换为直接引用的过程，也就是初始化常量的过程。

符号引用和内存引用：字符串常量已经在 Class 文件中了，这时是没有“地址”这样的概念的，地址是内存的地址，还没有加载到内存中，这时是用“文件偏移量”来表示的，当加载到内存空间之后就会使用地址来标识，也就是直接引用

2.5. 初始化

初始化：Java 虚拟机真正开始执⾏类中编写的 Java 程序代码，将主导权移交给应⽤程序。初始
化阶段就是执⾏类构造器⽅法的过程。例如创建类的实例，调用类的静态方法，访问类或接口的静态变量（不包括 final 修饰的静态变量，在编译阶段就确定了值），初始化子类时，父类会先被初始化，执行静态代码块。

普通的成员变量（非静态变量）不会在 JVM 类加载过程中的初始化阶段被初始化。类加载过程中的初始化阶段主要是针对类变量（被 static 修饰的变量）以及执行静态代码块。普通成员变量是在对象创建时，即通过构造函数或其他实例初始化方法进行初始化的。当使用 new 关键字创建对象时，会为对象在堆内存中分配空间，并对成员变量进行初始化等操作。

2.6. 双亲委派模型

双亲委派模型是 Java 类加载机制中的一种重要设计模式，也就是上述类加载中的第一步

JVM 默认是有三个类加载器的：

这里的父子关系并不是 Java 中的继承关系，而是类似与指向的一个 parent 引用

双亲委派模型工作原理：

当一个应用程序需要加载一个类时，应用程序类加载器首先会将加载请求委派给它的父类加载器扩展类加载器，扩展类加载器再委派给启动类加载器。如果启动类加载器无法加载该类，扩展类加载器会尝试加载。如果扩展类加载器也无法加载，最后应用程序类加载器才会尝试自己去加载。

那为什么不一开始就给启动类加载器来执行而是又绕了一圈？

避免类的重复加载：由于父类加载器优先加载，相同的类只会被加载一次，避免了类的重复加载和内存浪费。
保证核心类库的安全性：防止核心类库被恶意篡改（程序员自己写的类和标准库中的类名字一样，直接从启动类加载器加载会覆盖掉标准库的类），确保了 Java 程序的稳定性和安全性。

就类似与公司中的员工，领导和老板，当员工发现问题是需要上报给领导，领导再上报给老板，如果说这个问题比较重要，老板就亲自解决，如果不是那么重要，但也有一定分量，就交给领导解决，如果只是一些小事，就让员工自己解决

其实类加载器可以程序员自定义，自定义的类加载器可以遵守双亲委派模型也可以不遵守。

3. JVM 的垃圾回收机制（GC）

JVM 的垃圾回收主要是在堆内存进行的，这里存储的都是 new 出来的对象，当这些对象没有引用指向的时候，就成为了垃圾，如果放任不管，就会一直占用着内存，最终造成内存泄露

进行垃圾回收可能会触发 “Stop The World”（STW）问题：在执行垃圾回收的某个阶段，为了保证垃圾回收的准确性和一致性，需要暂停所有应用程序线程，使得整个应用程序出现短暂的停顿。

所以说 C++ 这种追求高性能的语言并没有使用垃圾回收机制

接下来看 JVM 中是如何进行垃圾回收的

首先，进行垃圾回收肯定需要先标记出哪些对象是垃圾

那么怎么去找哪个对象是垃圾呢？

3.1. 识别垃圾

方案一：引用计数。

给每一个对象分配一个计数器，来统计有多少引用指向，每增加一个引用，计数器 + 1，每减少一个引用，计数器 - 1，当计数器减为 0，就变成垃圾了

这个方法看似可行，python 等一些语言采用的就是这个，但是还存在一个问题：

无法解决循环引用的问题。例如，对象 A 和对象 B 相互引用，除此之外没有其他地方引用它们，此时它们的引用计数器都不为 0，但实际上它们已经不再被程序使用，应该被回收。

同时，引入计数器，也会消耗掉额外的空间

方案二：可达性分析

以一系列称为 “GC Roots” 的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链。当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的，是垃圾对象，也就是在类似图的结构中从多个根节点遍历一遍，如果发现有的对象没有任何路径可以到达，也就是没有引用指向了，那么就是垃圾

可达性分析有效的解决了循环引用的问题，可以作为根节点的可以是方法区中类静态属性引用的对象（static 修饰的变量引用的对象），常量池中引用的对象，方法中的局部变量引用的对象，本地方法栈引用的对象。

可达性分析由于需要每次都遍历一遍对象，所以是比较消耗时间的