类加载

丶西红柿丶
229 阅读15分钟

什么叫类加载

类加载就是将类的.class文件中的二进制数据读入内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个java.lang.Class对象，用来封装在方法区的数据结构。

** 什么时会启动类加载器**

  1. 隐式加载：new 创建类的实例
  2. 显示加载：loaderClass,forName等
  3. 访问类的静态变量，或者为类的静态变量赋值
  4. 调用类的静态方法
  5. 使用反射创建某个类或者接口对象的Class对象
  6. 初始化某个类的子类。
  7. 类加载器并不需要等到某个类被“首次主动使用”时再加载它，JVM规范允许类加载器在预料某个类将要被使用时就预先加载它，如果在预先加载的过程中遇到了.class文件缺失或存在错误，类加载器必须在程序首次主动使用该类时才报告错误（LinkageError错误）如果这个类一直没有被程序主动使用，那么类加载器就不会报告错误。 类的加载过程

image.png

  1. 加载
    在硬盘上查找并通过IO读入字节码文件，使用到类时才会加载，例如调用类的main()方法，new对象等等，在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口.1、通过一个类的全限定名来获取其定义的二进制字节流。2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。3、在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。
  2. 验证：
    校验字节码文件的正确性
  3. 准备：
    准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：1、这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。2、这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。假设一个类变量的定义为：public static int value = 3； 那么变量value在准备阶段过后的初始值为0，而不是3，因为这时候尚未开始执行任何Java方法，而把value赋值为3的putstatic指令是在程序编译后，存放于类构造器（）方法之中的，所以把value赋值为3的动作将在初始化阶段才会执行。
  4. 解析：
    将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)，这是所谓的静态链接过程(类加载期间完成)解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，符号引用在 class 文件中以 CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info 等类型的常量出现
    符号引用：符合引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能够无歧义的定位到目标即可。符号引用与虚拟机实现的内存布局无关，因为引用的目标不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是他们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在 java 虚拟机规范的 class 文件格式中。
    直接引用：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在内存中存在。
    （个人理解：解析就是将符号引用变为直接引用。为什么要这么做呢？就是要将对象加载到内存中。“直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄” 这句话意味着对象已经被加载到内存中了。因为句柄的定义就是：当前对象的唯一一个标识。这里说解析阶段的目的是什么，那么接下来应该说解析发生的时间，以及解析是怎么做的了）。
  5. 初始化：
    对类的静态变量初始化为指定的值，执行静态代码块。

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

引导类加载器（Boostrap ClassLoader）：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等。

扩展类加载器（Ext ClassLoader）：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包。

应用程序类加载器（App ClassLoader）：负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类。

自定义加载器：负责加载用户自定义路径下的类包。

------------------------------------------

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

---------------------------------------------------------------------------

通过Java命令执行代码的大体流程如下：

image.png

从上图我们可以看出发起调用的地方是操作系统底层帮我们实现的，引导类加载器也不是由java编写的。

在真正加载我们要运行的类之前要做很多准备工作，这其中很多地方都不是java语言所能处理的，因此不必做过多的探究。

那么类加载在加载类的过程中发生了哪些事情呢？大概可以分为以下七个阶段：

image.png

image.png

那么类是在jvm启动时就全部加载了吗？

答案是否定的，事实上，主类在运行过程中如果使用到其它类，会逐步加载这些类。jar包或war包里的类不是一次性全部加载的，是使用到时才加载。请看下面例子

public class TestDynamicLoad {
static {
System.out.println("加载主启动类");
}

public static void main(String[] args) {
new A();
System.out.println("加载测试");
B b = null;//B不会加载，除非这里执行new B();
}
}

class A{
static {
System.out.println("加载A类*");
}

public A() {
System.out.println("初始化A类*");
}
}

class B{
static {
System.out.println("加载B类*");
}

public B() {
System.out.println("初始化B类*");
}
}

运行结果：
加载主启动类
加载A类
初始化A类*
加载测试*

类加载器和双亲委派机制

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

Bootstrp loader Bootstrp加载器是用C++语言写的，它是在Java虚拟机启动后初始化的，它主要负责加载 %JAVA_HOME%/jre/lib,-Xbootclasspath参数指定的路径以及 %JAVA_HOME%/jre/classes中的类。

ExtClassLoader Bootstrp loader加载ExtClassLoader,并且将ExtClassLoader的父加载器设置为Bootstrp loader.ExtClassLoader是用Java写的，具体来说就是 sun.misc.Launcher$ExtClassLoader，ExtClassLoader主要加载 %JAVA_HOME%/jre/lib/ext，此路径下的所有classes目录以及java.ext.dirs系统变量指定的路径中类库。

AppClassLoader Bootstrp loader加载完ExtClassLoader后，就会加载AppClassLoader,并且将AppClassLoader的父加载器指定为 ExtClassLoader。AppClassLoader也是用Java写成的，它的实现类是 sun.misc.Launcher$AppClassLoader，另外我们知道ClassLoader中有个getSystemClassLoader方法,此方法返回的正是AppclassLoader.AppClassLoader主要负责加载classpath所指定的位置的类或者是jar文档，它也是Java程序默认的类加载器。

类加载器初始化过程：

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

jdk源代码如下：

//Launcher的构造方法
public Launcher() {
Launcher.ExtClassLoader var1;
try {
//构造扩展类加载器，在构造的过程中将其父加载器设置为null
var1 = Launcher.ExtClassLoader.getExtClassLoader();
} catch (IOException var10) {
throw new InternalError("Could not create extension class loader", var10);
}
try {
//构造应用类加载器，在构造的过程中将其父加载器设置为ExtClassLoader，
//Launcher的loader属性值是AppClassLoader，我们一般都是用这个类加载器来加载我们自己写的应用程序
this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
} catch (IOException var9) {
throw new InternalError("Could not create application class loader", var9);
}
Thread.currentThread().setContextClassLoader(this.loader);

image.png

双亲委派机制

前面说了，java中有三个类加载器，问题就来了，碰到一个类需要加载时，它们之间是如何协调工作的，即java是如何区分一个类该由哪个类加载器来完成呢。 在这里java采用了委托模型机制，这个机制简单来讲，就是“类装载器有载入类的需求时，会先请示其Parent使用其搜索路径帮忙载入，如果Parent 找不到,那么才由自己依照自己的搜索路径搜索类”

下面举一个例子来说明，为了更好的理解，先弄清楚几行代码：

Public class Test{

Public static void main(String[] arg){

ClassLoader c = Test.class.getClassLoader(); //获取Test类的类加载器

System.out.println(c);

ClassLoader c1 = c.getParent(); //获取c这个类加载器的父类加载器

System.out.println(c1);

ClassLoader c2 = c1.getParent();//获取c1这个类加载器的父类加载器

System.out.println(c2);

}

}

结果：
……AppClassLoader……

……ExtClassLoader……

Null

可以看出Test是由AppClassLoader加载器加载的，AppClassLoader的Parent 加载器是 ExtClassLoader,但是ExtClassLoader的Parent为 null ·依java的观点来看，逻辑上并不存在Bootstrap Loader的类实体，所以在java程序代码里试图打印出其内容时，我们就会看到输出为null。

我们来看下应用程序类加载器AppClassLoader加载类的双亲委派机制源码，AppClassLoader 的loadClass方法最终会调用其父类ClassLoader的loadClass方法，该方法的大体逻辑如下：

首先，检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载，直接 返回。

如果此类没有加载过，那么，再判断一下是否有父加载器；如果有父加载器，则由父加 载器加载（即调用parent.loadClass(name, false);）.或者是调用bootstrap类加载器来加 载。

如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前类加载器的 findClass方法来完成类加载。

源代码如下：


ClassLoader.java

protected Class<?> loadClass(String name, boolean resolve)\
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 检查当前类加载器是否已经加载了该类
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) { //如果当前加载器父加载器不为空则委托父加载器加载该类
c = parent.loadClass(name, false);
} else {//如果当前加载器父加载器为空则委托引导类加载器加载该类
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}

if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
//都会调用URLClassLoader的findClass方法在加载器的类路径里查找并加载该类
//（ExtClassLoader类中无loadClass方法，会调用其父类URLClassLoader中的loadClass()）
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}


URLClassLoader.java

protected Class<?> findClass(final String name)
throws ClassNotFoundException
{
final Class<?> result;
try {
result = AccessController.doPrivileged(
new PrivilegedExceptionAction<Class<?>>() {
public Class<?> run() throws ClassNotFoundException {
//匹配被加载类的路径和当前类加载器的加载路径，看能否匹配到
String path = name.replace('.', '/').concat(".class");
Resource res = ucp.getResource(path, false);
if (res != null) {
try {
//如果能匹配到，就进行真正的类加载，
//就会执行前面说的类加载的几个阶段
return defineClass(name, res);
} catch (IOException e) {
throw new ClassNotFoundException(name, e);
}
} else {
return null;
}
}
}, acc);
} catch (java.security.PrivilegedActionException pae) {
throw (ClassNotFoundException) pae.getException();
}
if (result == null) {
throw new ClassNotFoundException(name);
}
return result;
}

分析源代码可知：双亲委派功能是在ClassLoader类的loadClass中方法实现的（所以想要打破双亲委派机制，重写loadClass方法即可），真正的类加载是在URLClassLoader的findClass方法实现的。

）**

主要有以下2点原因：

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

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

Tomcat打破双亲委派机制

以Tomcat类加载为例，Tomcat 如果使用默认的双亲委派类加载机制行不行？

我们思考一下：Tomcat是个web容器， 那么它要解决什么问题：

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

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

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

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

再看看我们的问题：Tomcat 如果使用默认的双亲委派类加载机制行不行？

答案是不行的。为什么？

第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认 的类加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。

第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。

第三个问题和第一个问题一样。

我们再看第四个问题，我们想我们要怎么实现jsp文件的热加载，jsp 文件其实也就是class文 件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp 是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想 到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载 器。重新创建类加载器，重新加载jsp文件。

Tomcat自定义加载器详解

image.png 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文件的热加载功能。

tomcat 这种类加载机制违背了java 推荐的双亲委派模型了吗？答案是：违背了。

很显然，tomcat 不是这样实现，tomcat 为了实现隔离性，没有遵守这个约定，每个 webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器，打破了双亲委 派机制。

avatar
文章
阅读
粉丝