回顾了一下双亲委派机制，在这记录记录，下一篇会基于打破双亲委派机制来更新

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下的该类复原时，再次打印类加载器时，返回的则是应用类加载器了，说明双亲委派机制的加载层级关系。

 

为什么设计双亲委派机制呢？

1. 沙箱安全机制：自己编写的String类不会被加载，可以防止核心API库被随意篡改；
2. 避免类的重复加载：当父类已经加载了该类时，就没有必要子类加载器再次加载一次，保证被加载类的唯一性。

 

打破双亲委派机制：

 

  例如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方法进行重写，取出双亲委派部分。