🍒3.2双亲委派机制

双亲委派模型是类加载中的一个环节，属于Loading阶段，它是描述如何根据类的全限定名找到class文件的过程。

在JVM里面提供了一组专门的对象，用来进行类的加载，即类加载器，当然既然双亲委派模型是类加载中的一部分，所以其所描述找.class文件的过程也是类加载器来负责的。

但是想要找全class文件可不容易，毕竟.class文件可能在jdk目录里面，可能在项目的目录里面，还可能在其他特定的位置，因此JVM提供了多个类加载器，每一个类加载器负责在一个片区里面找，毕竟分工明确，才能事半功倍。

默认的类加载器主要有三个:

BootStrapClassLoader:负责加载标准库里面的类，如String，Random，Scanner等

ExtensionClassLoader:负责加载JDK扩展的类，现在基本上很少使用了

ApplicationClassLoader:负责加载当前项目目录中的类

除了默认的几个类加载器，程序员还可以自定义类加载器，来加载其他目录的类，如Tomcat就自定义了类加载器，用来专门加载webapps目录中的.class文件，但是自定义的类加载器未必要遵守双亲委派模型，毕竟你在自己特定的目录下还没有找到对应的.class文件，再去标准库去找基本上也是未果，Tomcat中的自定义的类加载器就没有遵守双亲委派模型。

而双亲委派模型就描述了类加载过程中的找目录的环节，它的内容如下：

● 如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此。

● 因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载（去自己的片区搜索）。

举两个例子：第一个，我们要去找标准库里面的String.class文件，它的过程大致如下：

● 首先ApplicationClassLoader类收到类加载请求，但是它先询问父类加载器是否加载过，即询问ExtensionClassLoader类是否加载过

● 如果ExtensionClassLoader类没有加载过，请求就会向上传递到ExtensionClassLoader类，然后同理，询问它的父加载器BootstrapClassLoader是否加载过

● 如果BootstrapClassLoader没有加载过，则加载请求就会到BootstrapClassLoader加载器这里，由于BootstrapClassLoader加载器是最顶层的加载器，它就会去标准库进行搜索，看是否有String类，我们知道String是在标准库中的，因此可以找到，请求的加载任务完成，这个过程也就结束了

第二个例子，我要加载搜索项目目录中的Test类，过程如下：

首先ApplicationClassLoader类收到类加载请求，但是它先询问父类加载器是否加载过，即询问ExtensionClassLoader类是否加载过。

如果ExtensionClassLoader类没有加载过，请求就会向上传递到BootStrapClassLoader类，然后同理,如果BootstrapClassLoader没有加载过，则加载请求就会到BootstrapClassLoader加载器这里，由于BootstrapClassLoader加载器是最顶层的加载器，它就会去标准库进行搜索，看是否有Test类，我们知道Test类不在标准库，所以会回到子加载器里面搜索。

同理，ExtensionClassLoader加载器也没有Test类，会继续向下，到ApplicationClassLoader加载器中寻找，由于ApplicationClassLoader加载器搜索的就是项目目录，因此可以找到Test类，全过程结束。

当然，如果在ApplicationClassLoader还没有找到，就会抛出异常

双亲委派模型的优点：

● 当自定义类与标准库中的类重名时，一定会加载标准库中的那个类，保证了Java的核心API不会被篡改

● 使得 Java 类随着它的类加载器一起具有一种带有优先级的层次关系，从而使得基础类得到统一

● 避免重复加载类：比如 A 类和 B 类都有一个父类 C 类，那么当 A类启动时就会将 C 类加载起来，那么在 B 类进行加载时就不需要在重复加载 C 类了

🍎四.GC垃圾回收机制

上面讲了Java运行时内存的各个区域。对于程序计数器、虚拟机栈、本地方法栈这三部分区域而言，其生命周期与相关线程有关，随线程而生，随线程而灭。并且这三个区域的内存分配与回收具有确定性，因为当方法结束或者线程结束时，内存就自然跟着线程回收了。因此我们本节课所讲的有关内存分配和回收关注的为Java堆与方法区这两个区域

Java堆中存放着几乎所有的对象实例，垃圾回收器在对堆进行垃圾回收前，首先要判断这些对象哪些还存活，哪些已经"死去"。判断对象是否已"死"有如下几种算法

● 引用计数算法

● 可达性分析算法

🍒4.1 死亡对象的判断方法

在堆空间，内存的分布有三种，一是正在使用的内存，二是未使用且未回收的内存，三是未分配的内存，那内存中的对象，也有三种情况，对象内存全部在使用（相当于对象整体全部在使用），对象的内存部分在使用（相当于对象的一部分在使用），对象的内存不使用（对象也就使用完毕了），对于这三类对象，前两类不需要回收，最后一类需要回收

🍉4.1.1引用计数算法(python采取该方案)

引用计数描述的算法为:

给对象增加一个引用计数器，每当有一个地方引用它时，计数器就+1；当引用失效时，计数器就-1；任何时刻计数器为0的对象就是不能再被使用的，即对象已"死"。

引用计数法实现简单，判定效率也比较高，在大部分情况下都是一个不错的算法。比如Python语言就采用引用计数法进行内存管理

但是，在主流的JVM中没有选用引用计数法来管理内存，最主要的原因就是引用计数法无法解决对象的循环引用问题会导致最终内存泄漏

class D{
 D d = null;
}
public class Test1 {
    public static void main(String[] args) {
        D a = new D();
        D b = new D();
        a = b.d;
        b = a.d;
        a = null;
        b = null;
    }
}

两个对象的属性相互指向另一个对象，使得计数器的值都为1，由于对象外界没有指向这两个对象的引用，于是这两个对象处于既不被使用，也不被释放的尴尬场景当中，这就是循环引用问题

🍉4.1.1可达性分析算法(Java采取该方案)

在上面我们讲了，Java并不采用引用计数法来判断对象是否已"死"，而采用"可达性分析"来判断对象是否存活(同样采用此法的还有C#、Lisp-最早的一门采用动态内存分配的语言)。

此算法的核心思想为 : 通过一系列称为"GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称之为"引用链"，当一个对象到GC Roots没有任何的引用链相连时(从GC Roots到这个对象不可达)时，证明此对象是不可用的

在Java语言中，可作为GC Roots的对象包含下面几种:

虚拟机栈(栈帧中的本地变量表)中引用的对象；

方法区中类静态属性引用的对象；

方法区中常量引用的对象；

本地方法栈中 JNI(Native方法)引用的对象

从上面我们可以看出“引用”的功能，除了最早我们使用它（引用）来查找对象，现在我们还可以使用“引用”来判断死亡对象了。所以在 JDK1.2 时，Java 对引用的概念做了扩充，将引用分为强引用(StrongReference)、软引用(Soft Reference)、弱引用(Weak Reference)和虚引用(Phantom Reference)四种，这四种引用的强度依次递减

🍒4.2垃圾回收相关算法

垃圾回收的算法最常见的有以下几种：

● 标记-清除算法

● 标记-复制算法

● 标记-整理算法

● 分代回收算法（本质就是综合上述算法，在堆的不同区采取不同的策略）

🍉4.2.1 标记-清除算法

标记其实就是可达性分析的过程，在可达性分析的过程中，会标记可达的对象，其他不可达的对象，都会被视为垃圾进行回收

标记-清除算法的不足主要有两个 :

效率问题 : 标记和清除这两个过程的效率都不高

空间问题 : 标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行中

需要分配较大对象时，无法找到足够连续内存而不得不提前触发另一次垃圾收集,因为在我们申请内存的时候时需要申请连续的内存,这时使用标记清除算法就会导致在回收的内存都是"内存碎片",

比如经过一轮标记后，标记状态如图：

🍉4.2.2 标记-复制算法(幸存区)

为了解决标记-清除算法所带来的内存碎片化的问题，引入了复制算法。

它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。如果内存中多数对象都是存活的，这种算法将会产生大量的内存间复制的开销，但对于多数对象都是可回收的情况，算法需要复制的就是占少数的存活对象，而且每次都是针对整个半区进行内存回收，分配内存时也就不用考虑有空间碎片的复杂情况。

复制算法的第一步还是要通过可达性分析进行标记，得到那一部分需要进行回收，那一部分需要保留，不能回收。

标记完成后，会将还在使用的内存连续复制到另外一块等大的内存上，这样得到的未分配内存一直都是连续的，而不是碎片化的

但是，复制算法也有缺陷：

● 空间利用率低。

● 如果可回收的内存少，需保留的内存大，复制的开销也大

🍉4.2.3 标记-整理算法(老年区)

复制收集算法在对象存活率较高时会进行比较多的复制操作，效率会变低。因此在老年代一般不能使用复制算法。

针对老年代的特点，提出了一种称之为"标记-整理算法"。标记过程仍与"标记-清除"过程一致，但后续步骤不是直接对可回收对象进行清理，而是让所有存活对象都向一端移动，然后直接清理掉端边界以外的内存。

解决了标记-复制算法空间利用率低的问题，但是复制的开销问题并没有得到解决

流程图如下

🍉4.2.4 分代回收算法

上述的回收算法都有缺陷，分代回收就是将上述三种算法结合起来分区使用，分代回收会针对对象进行分类，以熬过的GC扫描轮数作为“年龄”，然后针对不同年龄采取不同的方案

在新生代，包括一个伊甸区与两个幸存区，伊甸区存储的是未经受GC扫描的对象，也就是刚刚创建的对象。

幸存区存储了经过若干轮存储的对象，通过实际经验得出，新生代的对象具有“朝生夕灭”的特点，也就是说只有少部分的伊甸区对象才能熬过第一轮的GC扫描，所以到幸存区的对象相比于伊甸区少的多，正因为大部分新生代的对象熬不过JVM第一轮扫描，所以伊甸区与幸存区的分配比例并不是1:1的关系，HotSpot虚拟机默认一个Eden和一个Survivor的大小比例是8∶1，正因为新生代的存活率较小，所以新生代使用的垃圾回收算法为标记-复制算法最优，毕竟存活率越小，对于标记-复制算法，复制的开销也就很小。

不妨我们将第一个Survivor称为活动空间，第二个Survivor称为空闲空间，一旦发生GC，将10%的活动区间与另外80%中存活的对象复制到10%的空闲空间，接下来，将之前90%的内存全部释放，以此类推。

在后续几轮GC中，幸存区的对象在两个Survivor中进行标记-复制算法。

在继续持续若干轮GC后，幸存区的对象就会被转移到老年代，老年代中都是年龄较老的对象，根据经验，一个对象越老，继续存活的可能性就越大，因此老年代的GC扫描频率远低于新生代，所以老年代采用标记-整理的算法进行内存回收，毕竟老年代存活率高，对于标记-整理算法，复制转移的开销很低

🍒常见垃圾收集器

这一部分，我们了解即可，首先有请历史最悠久的Serial收集器(新生代收集器,串行GC)与 Serial Old收集器(老年代收集器，串行GC)登场，这两类收集器前者是新生代收集器，后者是老年代收集器，采用串行GC的方式进行垃圾收集，由于串行GC开销较大，会产生较严重的STW

STW是什么？

Stop The World (STW)，你可以理解为你打游戏的时候，你的xxx来干xxx，使得你不得不中断游戏，这段中断的时间就相当于STW，或者你理解为由于设备原因使得你打游戏很卡，这些卡顿的时间就是STW

然后就是 ParNew收集器(新生代收集器,并行GC)，Parallel Scavenge收集器(新生代收集器,并行GC)，Parallel Old收集器(老年代收集器，并行GC)，前两个是新生代的收集器，最后一个是老年代的收集器，这组收集器引入了多线程，并发情况下，GC处理效率相比于前一组更高，但是如果在单线程情况下，可能不会比Serial收集器要好，此外，Parallel Scavenge收集器相比于 ParNew收集器只是多了些参数而已。

CMS收集器，该收集器设计的初衷是尽量使得STW时间尽量地短，特点：

●初始标记，过程速度很快，只是找到GCRoots，只会引起短暂的STW。
●并发标记，虽然速度很慢，但是它可以和业务线程并发执行，不会产生STW。
●重新标记，在并发标记过程中，业务代码可能会改变标记的结果，需要进行一次微调，由于是微调，引起的STW很短。
●回收内存，也是和业务代码并发。
前三部分的标记过程就是将可达性分析给拆开了，回收内存主要用于标记-整理，老年代专属。

G1收集器，它把内存分为分成了很多的小区域（Region），并且给这些Region做了标记，有些Region放新生代对象，有些Region放老年代对象。

GC扫描的时候，只扫描一部分Region，不追求一次扫描完，分多次来扫描，这样对业务代码执行影响更小。

G1收集器可以优化STW的时间小于1ms。本质上CMS与G1都是化整为零的思想。

最后，做个小总结，垃圾回收本质靠运行时环境，来帮助程序员完成内存释放的工作，但是它有以下缺点：

●产生额外的开销。
●可能会影响程序的流畅运行（STW造成）

JVM【类加载与GC垃圾回收机制】（下）