内存划分

JVM中内存主要划分为以下几个部分

1. 栈 存放方法的调用关系
2. 堆 存放new的对象
3. 方法区 存放类对象（加载好的类）
4. 程序计数器 存放下一条要执行的指令的地址

例如

class Test2 {private int z = 0;
}
public class Test {public int x = 0;public static int y = 0;public static Test2 t2 = new Test2;public static void main(String[] args){Test t = new Test();}
}

局部变量在栈上
成员变量在堆上
静态变量在方法区中

因此
t是局部变量，在栈上
x，z是成员变量，在堆上
y，t2是静态变量，在方法区中

类加载

1. 加载 找到.class 文件，按照指定格式读取并解析
2. 验证 查看.class文件中的内容是否符合规范
3. 准备 给类里面的静态资源分配内存
4. 解析 初始化字符串常量，将符号引用替换成直接引用（也就是将一些还没有分配内存空间的引用对象先用占位符标记，然后将占位符替换成真正的内存地址）
5. 初始化 初始化静态成员，静态代码块，加载父类

以下情景会触发类加载：

1. 创建类的实例
2. 使用了类中的静态方法，属性
3. 使用类的子类

类加载的过程：

双亲委派模型

JVM中包括了下面三个类加载器

1. Bootstrap ClassLoader 加载标准库中的类
2. Extension ClassLoader 加载JVM扩展的库的类
3. Application ClassLoader 加载自定义类
   这里的Bootstrap相当于Extension的父亲，Extension相当于Application的父亲。当进行类加载时，会先从这几个类中的最高等级出发，向下寻找是否有匹配的类

例如cat类，先去标准库中找，找不到就去扩展库中找，找不到就去自定义类找，如果还没有找到，类加载就失败了

双亲委派模型避免了自己定义的类名和标准库中的类发生冲突时，无法正常加载标准库中的类的问题

内存回收

之前C语言的博客中讲到了动态内存分配的问题，在我们malloc的时候很有可能忘记或者无法执行到free代码，导致内存泄漏。因此JVM及其他语言中有GC（垃圾回收）机制，保证我们申请的内存可以自动释放。相当于我们开车从手动挡变成了自动挡

栈中存放的都是局部变量，当代码块执行完毕后就会释放，因此不用回收，方法区中存放类对象，加载后也不太会卸载，程序计数器中是固定的内存空间，也不必进行回收，因此，GC主要回收堆中引用的对象

对于如何判定一个对象是否是垃圾，有下面几种方式

引用计数

给每一个对象都加上一个计数器，当有一个变量引用了这个对象，计数器就加一，如果计数器变成0了，那么对象就该被回收了

缺点：

1. 空间利用率低 当是占用内存空间很小的对象时，再加上一个引用计数器就会显得更占内存
2. 循环引用时会无法清理对象

循环引用就是如下情况

class Test {Test t
}
Test a = new Test();
Test b = new Test();
a.t = b;
b.t = a;
a = null;
b = null;

a和b互相引用，这两个对象没有其他人引用，因此都无法访问到，这两个对象的程序计数器虽然都是1，但是事实上已经是垃圾了，因此程序计数器无法解决这个问题

可达性分析

约定一些特定的变量（栈上的变量，常量值引用的对象，方法区引用的静态变量）为“GC roots”，从这些变量出发遍历访问所有的对象，如果能访问到就是“可达”的，否则就是“不可达”的，如果不可达，就是垃圾

先约定好一侧的内存是专门存放变量的（比如左侧），那么另一侧就是负责方便拷贝对象的。当一些对象是“不可达”时，就标记这些对象，然后将这些标记的对象释放掉，这时内存中会出现大量内存碎片，因此将左侧的资源拷贝到右侧，或者将这些内存碎片进行搬运，凑到一起

分代回收

依据对象挺过GC可达性扫描的次数，可以分为下面几种

1. 伊甸区 新创建出来的对象
2. 生存区 经过一次或多次GC扫描的对象
3. 老年代 经过许多次GC扫描的对象
   新生代的对象会经历一次GC，如果“可达”，就会进入生存区，生存区中的对象每经历一次GC，都会通过复制算法拷贝到另一个生存区，只要对象不消亡，就会在两个生存区中来回拷贝。直到达到一个限定值，就会进入老年代。老年代的GC就会比生存区的频率小很多，因为进入老年区的说明这个对象十分常用。

另外，如果创建的是一个很大的对象，那么这个对象会直接进入老年代，因为频繁的复制算法会有很大的开销