JVM：从零到入门

在加载 Loading 阶段，Java虚拟机需要完成以下三件事情：

1）通过一个类的全限定名来获取定义此类的二进制字节流。

2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

3）在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

也就是把文件读到内存中的步骤。

2.验证

验证是连接阶段的第一步，这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。

比如：文件格式验证字节码验证符号引用验证

3.准备

准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段。

例如：

java 复制代码

private static int value = 123;

此时就是初始化value的int值为0，而不是123。（相当于在元数据区先占个位置）

4.解析

解析阶段是 Java 虚拟机将常量池内的符号引用替换为直接引用的过程，也就是初始化常量的过程。

5.初始化

初始化阶段，Java 虚拟机真正开始执行类中编写的 Java 程序代码，将主导权移交给应用程序。初始化阶段就是执行类构造器方法的过程。

那么一个类什么时候会被加载呢？

不是Java程序一运行就会把所有的类都加载，而是真正用到了才会加载。（懒汉模式）

1.构造类的实例

2.调用类的静态方法、使用静态属性

3.加载子类，就会先加载其父类

双亲委派模型

加载是把.class文件找到，读取文件内容的过程，双亲委派模型就是描述这个加载，找.class文件的基本过程。

JVM默认提供了三个类加载器：

上述三个类，存在parent属性，指向自己的父类加载器。

加载一个类的时候，先从ApplicationClassLoader开始的，但是它会把加载任务交给其父亲ExtensionClassLoader，让其父亲去执行。于是ExtensionClassLoader要去加载了，但是也不是真的加载，而是把加载任务再委托给自己的父亲。它的父亲BootstrapClassLoader要去加载了，但是发现自己的父亲是null，没有父亲，于是只能自己加载。

等待自己加载完后，如果找到了就加载，没有找到就由自己的子类加载器进行加载。也就是 BootstrapClassLoader加载完没找到后，让ExtensionClassLoader加载，如果也没找到最后再让ApplicationClassLoader加载。

最后ApplicationClassLoader如果找到了就加载，没找到就由子类加载器进行加载。由于当前没有子类了，就只能抛出类找不到这样的异常。

为什么要有上述顺序？这套顺序出自JVM实现代码的逻辑，并且这段代码大概是类似于递归的方式写的。这个顺序最主要的目的就是为了保证Bootstrap能够先加载，Application后加载，这样能够解决用户自己创建了一些奇怪的类引起bug。

例如用户自己写了一个java.lang.String这样的类，按照上述加载流程，JVM此时加载道德其实是标准库的类，而不会加载到用户自己的这个类。

同时用户自己也可以定义类加载器，可以和现有的配合使用。

垃圾回收机制

我们在java开发中何时考虑过内存管理？不像c和c++还要考虑什么时候释放资源，java只需要考虑业务实现就行了。

什么是垃圾呢？垃圾指的是不再使用的内存，垃圾回收就是把不用的内存帮我们自动释放了。

在别的语言中，如果不手动释放垃圾，这块内存空间就会一直存在，一直存在到进程结束。这就可能导致内存泄漏。剩余的空间越来越少，进一步导致后续的内存申请操作失败！

GC是垃圾回收中最主流的一种方式。很多语言都使用GC来解决上述问题。

JVM中有很多内存区域，GC主要是针对堆进行释放的。

同时GC是以对象为基本单位进行回收的，而不是字节。要回收就是回收整个对象，而不是回收半个对象。

GC回收的是对象，那么就要看有没有引用指向它。

如何知道有没有引用指向呢？有两种方式：

1.引用计数

2.可达性分析

引用计数

引用计数中，给每个对象都分配了一个计数器（整数），每次创建一个引用指向这个对象计数器就+1，这个引用被销毁了计数器就-1。

这个办法简单有效，但是Java并没有使用。因为：

1.内存空间浪费很严重，一个对象就要分配一个计数器。

2.存在循环引用的问题。

所以在Java中不用引用计数这种方式。

可达性分析

Java中的对象都是通过引用来指向并访问的。所以整个Java中的所有对象类似于一个树根节点，通过链式或者树形结构一个个串连起来。

可达性分析就是把这些对象被组织的结构看做树，从树根节点出发，遍历树，所有能被访问到的对象标记成"可达"。

通过这种方式，只需要有一个GC Roots节点就可以访问到所有的元素。访问不到的就代表着可以被GC回收了。所有的对象在创建的时候JVM都会记录下地址。

1、虚拟机栈（栈帧中的本地变量表）中引用的对象

2、方法区中类静态属于引用的对象

3、方法区中常量引用的对象

4、本地方法栈中Native方法引用的对象。

如何清除垃圾

主要有三种方式：标记清除，复制算法，标记整理。

标记清除

在一块内存空间中，2,4,6是需要清楚的垃圾，那么直接对其垃圾回收就可以完成。但是这样做就会有一个问题：全都是内存碎片。被释放的空闲空间是零散的，不是连续的。如果要申请一块很大的空间，必须要是连续的空间，此时就会申请失败！

复制算法

复制算法会把内存分成两半，对于垃圾（1和3）不去处理，把不是垃圾的部分（2和4）复制到另一边。

此时再把左边的内存清除。这样也就是把需要回收的垃圾处理掉了。

这种方法空间利用率低，并且垃圾少、有效对象多那么复制成本就比较大。

标记整理

标记整理解决了复制算法的缺点，类似于顺序表删除中间元素的操作，并且会有元素搬运的操作。

1 3 5 是垃圾，在标记整理的时候，会把1 3 5删除，然后把2移动到1的位置，4移动到2的位置，6移动到3的位置。

这种方式保证了空间利用率，并且解决了内存碎片问题。

但是这种方式效率也不高，如果搬运的空间比较大开销也会很大。

实际上基于这一些基本的策略，把垃圾回收分成不同的场景，不同的场景有不同的算法。这就是"分代回收"。

这个"代"，就是一代代的代。我们给对象引入一个概念：年龄。这个年龄，是熬过GC的轮次。如果经历了一轮可达性分析，发现这个对象还不是垃圾，就说明这个对象熬过了一轮GC。

代

JVM把堆分成两个区域：新生代、老年代。

新生代又分为Eden、From Survivor、To Survivor。

生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ( 该值可以通过参数 --XX:NewRatio 来指定 )，即：新生代 ( Young ) = 1/3 的堆空间大小。老年代 ( Old ) = 2/3 的堆空间大小。

Edem ： From Survivor ： To Survivor = 8 : 1 : 1 ( 可以通过参数 --XX:SurvivorRatio 来设定 )，即： Eden = 8/10 的新生代空间大小，From Survivor = To Survivor = 1/10 的新生代空间大小。

数据会首先分配到Eden区当中（当然也有特殊情况，如果是大对象那么会直接放入到老年代（大对象是指需要大量连续内存空间的java对象）。当Eden没有足够空间的时候就会触发jvm发起一次Minor GC，。如果对象经过一次Minor-GC还存活，并且又能被Survivor空间接受，那么将被移动到Survivor空间当中。并将其年龄设为1，对象在Survivor每熬过一次Minor GC，年龄就加1，当年龄达到一定的程度（默认为15）时，就会被晋升到老年代中了，当然晋升老年代的年龄是可以设置的。

这也就是之前的三种垃圾回收机制的分代回收中的代。其实主要原因就是可以根据各个年代的特点进行对象分区存储，更便于回收，采用最适当的收集算法：

新生代中，每次垃圾收集时都发现大批对象死去，只有少量对象存活，便采用了复制算法，只需要付出少量存活对象的复制成本就可以完成收集。（从From Survivor到To Survivor用的是复制算法）

而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须采用标记清除或者标记整理算法。

到此为止，JavaEE初阶的内容告一段落~接下来博主会持续更新JavaEE进阶一些的内容，快快关注吧~