JVM的类加载机制

一个Java类加载的全过程

1、Java代码执行全流程

      当我们用Java命令启动某个Java类的应用程序时，首先是通过类加载器把主类加载到JVM。整个流程如下图所示：

2、类加载过程步骤

        其中loadClass的类加载过程有如下几步：

      加载 >> 验证 >> 准备 >> 解析 >> 初始化 >> 使用 >> 卸载

• 加载：在硬盘上查找并通过IO读入字节码文件，使用到类时才会加载，例如调用类的 main()方法，new对象等等，在加载阶段会在内存中生成一个代表这个类的 java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
• 验证：校验字节码文件的正确性。
• 准备：给类的静态变量分配内存，并赋予默认值。
• 解析：将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如 main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)，这是所谓的静态链接过程(类加载期间完成)，动态链接是在程序运行期间完成的将符号引用替换为直接引用。
• 初始化：对类的静态变量初始化为指定的值，执行静态代码块。
• 使用：JVM底层会通过C++来调用我们的类方法进行运算。
• 卸载：程序运行结束，JVM通过GC机制回收原来分配给类运行的内存空间。

类加载器和双亲委派机制

1、类加载器分类

       类加载过程主要是通过类加载器来实现的，Java里有如下几种类加载器：

• 引导类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等。
• 扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包。
• 应用程序类加载器：负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类。
• 自定义加载器：负责加载用户自定义路径下的类包。

2、类加载器初始化过程

       参见类运行加载全过程图可知其中会创建JVM启动器实例sun.misc.Launcher。sun.misc.Launcher初始化使用了单例模式设计，保证一个JVM虚拟机内只有一个 sun.misc.Launcher实例。 在Launcher构造方法内部，其创建了两个类加载器，分别是 sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。 JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序。

3、双亲委派机制

       什么是双亲委派机制？就是我们在加载某个类时，先委托父加载器先去加载这个类，找不到再由上一级父加载器加载这个类，直到所有的父加载器在自己的加载路径都找不到这个类再由自己的类加载路径去加载这个类。这个加载器的层级关系如下图所示：

      设计双亲委派机制的目的：

      1、沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心 API库被随意篡改。

      2、避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一 次，保证被加载类的唯一性。

4、如何实现一个自定义类加载器

      自定义类加载器只需要继承 java.lang.ClassLoader 类，该类有两个核心方法，一个是 loadClass(String, boolean)，实现了双亲委派机制，还有一个方法是findClass，默认实现是空方法，所以我们自定义类加载器主要是重写findClass方法。

5、Tomcat打破双亲委派机制

      Tomcat是个web容器， 那么它要解决什么问题：

      1. 一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只            有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。

      2. 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机。

      3. web容器也有自己依赖的类库，不能与应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。

      4. web容器要支持jsp的修改，我们知道，jsp文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事       情， web容器需要支持 jsp 修改后不用重启。

      基于以上的问题，tomcat在原有的基础上设计出了符合需要的自定义类加载器：

      Tomcat的几个主要类加载器：

      commonLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问；

      catalinaLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见；

      sharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有 Webapp可见，但是对于Tomcat容器不可见；

      WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见，比如加载war包里相关的类，每个war包应用都有自己的WebappClassLoader，实现相互隔离，比如不同war包应用引入了不同的spring版本， 这样实现就能加载各自的spring版本；

      从图中的委派关系中可以看出： CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用， 从而实现了公有类库的共用，而CatalinaClassLoader和SharedClassLoader自己能加载的类则与对方相互隔离。 WebAppClassLoader可以使用SharedClassLoader加载到的类，但各WebAppClassLoader实例之间相互隔离。 而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例， 并通过再建立一个新的Jsp类加载器来实现JSP文件的热加载功能。