回顾了一下双亲委派机制，在这记录记录，下一篇会基于打破双亲委派机制来更新
1. 类加载：
多个java文件经过编译打包后生成可运行jar包，最后启动程序。首先需要通过类加载器把主类加载到JVM。主类在运行过程中如果使用到其他类，会逐步加载这些类。（jar包里的类不是一次性全部加载的，是使用到时才加载的）
类加载到使用过程步骤：
加载 >> 验证 >> 准备 >> 解析 >> 初始化 >> 使用 >> 卸载
加载：在硬盘上查找并通过IO读入字节码文件，使用到类时才会加载；
验证：校验字节码文件的正确性；
准备：给类的静态变量分配内存，并赋予默认值；
解析：将符号引用替换为直接引用，会把一些静态方法替换为指向数据所存内存的指针或句柄等（直接引用），这是静态链接过程；动态链接是在程序运行期间完成的将符号引用替换为直接引用。
初始化：对类的静态变量初始化为指定的值，执行静态代码块。
2．类加载器和双亲委派机制
类加载器包括有：启动类加载器，扩展类加载器，应用类加载器，自定义类加载器
主要是：
启动类加载器（bootstrap class loader）：基于C++实现，负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar等；
扩展类加载器（ExtClassLoader）：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包
应用类加载器（AppClassLoader）：负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类
自定义加载器：负责加载用户自定义路径下的类包
自定义一个类加载器：
自定义类加载器需要继承java.lang.ClassLoader 类，这个类有两个核心方法，一个是loadClass(String,boolean),实现了双亲委派机制，大概逻辑为：
1. 首先，检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载，直接返回。
2. 如果此类没有加载过，那么，再判断一下是否有父加载器；如果有父加载器，则由父加载器加载（即调用parent.loadClass(name, false);）.或者是调用bootstrap类加载器来加载。
3. 如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前类加载器的findClass方法来完成类加载。
还有一个方法是findClass，默认实现是抛出异常，所以自定义类加载器主要是重写findClass()方法。
双亲委派机制：
JVM类加载器有亲子层级结构：
双亲委派机制说简单点就是，先找父亲加载，不行再由儿子自己加载。
我在自己实验过程中发现，当我删除classpath下编译的类时，通过自定义类加载器加载我指定路径的类文件，打印出为我自己的类加载器加载；当我将classpath下的该类复原时，再次打印类加载器时，返回的则是应用类加载器了，说明双亲委派机制的加载层级关系。
为什么设计双亲委派机制呢？
- 沙箱安全机制：自己编写的String类不会被加载，可以防止核心API库被随意篡改；
- 避免类的重复加载：当父类已经加载了该类时，就没有必要子类加载器再次加载一次，保证被加载类的唯一性。
打破双亲委派机制：
例如tomcat：在webapp下存在多个项目时，所加载的是单独隔离的，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器，打破了双
亲委派机制。
tomcat的几个主要类加载器：
commonLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问；
catalinaLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见；
sharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有Webapp可见，但是对于Tomcat容器不可见；
WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见；
实现打破双亲委派机制，在原来重写findClass基础上，对于加载类loadClass方法进行重写，取出双亲委派部分。
