类加载机制 和垃圾回收机制

类加载机制

Java 分类：
>JVM：虚拟机：用于将程序员写的源代码编译成可执行的class文件。
>JRE：Java的运行环境，可以执行class文件。
>JDK：Java开发的集成环境，给程序员编程用的。
>JVM小于JRE，JRE小于JDK，JKD包含JRE，JRE包括JVM

类的加载过程如图，再做具体的介绍。

系统类加载器：

它负责加载系统类路径java -classpath或-D java.class.path 指定路径下的类库，也就是我们经常用到的classpath路径，开发者可以直接使用系统类加载器，一般情况下该类加载是程序中默认的类加载器，通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器。

由Java语言实现，父类加载器为ExtClassLoader。
类加载器加载Class大致要经过如下8个步骤：

1.检测此Class是否载入过，即在缓冲区中是否有此Class，如果有直接进入第8步，否则进入第2步。
2.如果没有父类加载器，则要么Parent是根类加载器，要么本身就是根类加载器，则跳到第4步，如果父类加载器存在，则进入第3步。
3.请求使用父类加载器去载入目标类，如果载入成功则跳至第8步，否则接着执行第5步。
4.请求使用根类加载器去载入目标类，如果载入成功则跳至第8步，否则跳至第7步。
5.当前类加载器尝试寻找Class文件，如果找到则执行第6步，如果找不到则执行第7步。
6.从文件中载入Class，成功后跳至第8步。
7.抛出ClassNotFountException异常。
8.返回对应的java.lang.Class对象。

ClassLoader类中的loadClass方法显示出了双亲委派模式，在类进行加载之前首先在缓存中查询是否该类已经被加载过了，如果加载过了则直接返回class对象，如果没有被加载过，则首先查看本类加载器的父类加载器是否存在，如果存在则委托父类加载器进行类的加载，如果父类加载器为null，代表子类加载器是扩展类加载器，而其父类是启动类加载器，使用委托给启动类加载器进行加载。若以上的父类没有加载成功，最后使用自定义的类加载器进行加载。

findClass方法默认抛出ClassNotFoundException，子类可以通过重写findClass方法来调用自定义类加载器。

类与类加载机制

两个class对象是否为同一个类对象存在两个必要条件:

1. 类的完整类名必须一致，包括包名。
2. 加载这个类的ClassLoader(指ClassLoader实例对象)必须相同。

垃圾回收机制

四个问题分别进行讲解
垃圾回收简介
圾回收是如何工作的br> 垃圾回收的类别
垃圾回收监视和分析

Java GC（Garbage Collection，垃圾收集，垃圾回收）机制，是Java与C++/C的主要区别之一，作为Java开发者，一般不需要专门编写内存回收和垃圾清理代码，对内存泄露和溢出的问题，也不需要像C程序员那样战战兢兢。这是因为在Java虚拟机中，存在自动内存管理和垃圾清扫机制。概括地说，该机制对JVM（Java Virtual Machine）中的内存进行标记，并确定哪些内存需要回收，根据一定的回收策略，自动的回收内存，永不停息（Nerver Stop）的保证JVM中的内存空间，防止出现内存泄露和溢出问题。

Java GC机制主要完成3件事：确定哪些内存需要回收，确定什么时候需要执行GC，如何执行GC。经过这么长时间的发展（事实上，在Java语言出现之前，就有GC机制的存在，如Lisp语言），Java GC机制已经日臻完善，几乎可以自动的为我们做绝大多数的事情。然而，如果我们从事较大型的应用软件开发，曾经出现过内存优化的需求，就必定要研究Java GC机制

启动Java垃圾回收
作为一个自动的过程，程序员不需要在代码中显示地启动垃圾回收过程。System.gc()和Runtime.gc()用来请求JVM启动垃圾回收。
这个请求机制提供给程序员一个启动 GC 过程的机会，但是启动由 JVM负责。JVM可以拒绝这个请求，所以并不保证这些调用都将执行垃圾回收。启动时机的选择由JVM决定，并且取决于堆内存中Eden区是否可用。JVM将这个选择留给了Java规范的实现，不同实现具体使用的算法不尽相同。

毋庸置疑，我们知道垃圾回收过程是不能被强制执行的。我刚刚发现了一个调用System.gc()有意义的场景。通过这篇文章了解一下适合调用System.gc() 这种极端情况。
标记
垃圾回收的第一步是标记。垃圾回收器此时会找出哪些内存在使用中，还有哪些不是。

内存分配器会保留指向可用内存的引用，以供分配新对象。
压缩

新对象会被分配在新生代内存。一旦新生代内存满了，就会开始对死掉的对象，进行所谓的小型垃圾回收过程。一片新生代内存里，死掉的越多，回收过程就越快；至于那些还活着的对象，此时就会老化，并最终老到进入老年代内存。
Stop the World 事件 —— 小型垃圾回收属于一种叫 “Stop the World” 的事件。在这种事件发生时，所有的程序线程都要暂停，直到事件完成（比如这里就是完成了所有回收工作）为止。
老年代用来保存长时间存活的对象。通常，设置一个阈值，当达到该年龄时，年轻代对象会被移动到老年代。最终老年代也会被回收。这个事件成为 Major GC。
Major GC 也会触发STW（Stop the World）。通常，Major GC会慢很多，因为它涉及到所有存活对象。所以，对于响应性的应用程序，应该尽量避免Major GC。还要注意，Major GC的STW的时长受年老代垃圾回收器类型的影响。
永久代包含JVM用于描述应用程序中类和方法的元数据。永久代是由JVM在运行时根据应用程序使用的类来填充的。此外，Java SE类库和方法也存储在这里。
如果JVM发现某些类不再需要，并且其他类可能需要空间，则这些类可能会被回收。

世代垃圾收集过程
Eden 区：当一个实例被创建了，首先会被存储在堆内存年轻代的 Eden 区中。

注意：如果你不能理解这些词汇，我建议你阅读这篇 垃圾回收介绍 ，这篇教程详细地介绍了内存模型、JVM 架构以及这些术语。

Survivor 区（S0 和 S1）：作为年轻代 GC（Minor GC）周期的一部分，存活的对象（仍然被引用的）从 Eden 区被移动到 Survivor 区的 S0 中。类似的，垃圾回收器会扫描 S0 然后将存活的实例移动到 S1 中。(图：JVM中的对象分配和老化过程。)

在释放一个实例和回收内存空间之前，Java 垃圾回收器会调用实例各自的 finalize() 方法，从而该实例有机会释放所持有的资源。虽然可以保证 finalize() 会在回收内存空间之前被调用，但是没有指定的顺序和时间。多个实例间的顺序是无法被预知，甚至可能会并行发生。程序不应该预先调整实例之间的顺序并使用 finalize() 方法回收资源。

对象什么时候符合垃圾回收的条件/p>

内存碎片：一旦实例从堆内存中被删除，其位置就会变空并且可用于未来实例的分配。这些空出的空间将会使整个内存区域碎片化。为了实例的快速分配，需要进行碎片整理。基于垃圾回收器的不同选择，回收的内存区域要么被不停地被整理，要么在一个单独的GC进程中完成。

在编译过程中作为一种优化技术，Java 编译器能选择给实例赋 null 值，从而标记实例为可回收。