JVM类的加载机制

# JVM类的加载机制

# 类加载运行过程

package com.tuling.jvm;
public class Math{
	public static final int initData = 666; 
	public static User user = new User();
	public int compute() { //一个方法对应一块栈帧内存区域 inta=1;
		intb=2;
		intc=(a+b)*10; 
		return c;
	}
	 public static void main(String[] args) {
		 Math math = new Math();
		 math.compute();
	 }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# loadClass的类加载过程有如下几步:

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

加载:在硬盘上查找并通过IO读入字节码文件，使用到类时才会加载，例如调用类的 main()方法，new对象等等，在加载阶段会在内存中生成一个代表这个类的 java.lang.Class对象，作为方法区这个类的各种数据的访问入口

验证:校验字节码文件的正确性

准备:给类的静态变量分配内存，并赋予默认值

解析:在类的加载过程中将符号引用替换为直接引用，该阶段会把一些静态方法 (符号引用，比如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)，这是所谓的静态链接过程(类加载期间完成)（类名、变量名称为符号；放在常量池中，这些符号加载到JVM内存中解析内存地址的过程），动态链接是在程序运行期间完成的将符号引用替换为直接引用

初始化:对类的静态变量初始化为指定的值，执行静态代码块

# 类加载到方法区

主要包含：运行时常量池、类型信息、字段信息、方法信息、类加载器的引用、对应Class实例的引用等
类加载器的引用：这个类到类加载器实例的引用
对class实例的引用：类加载器在加载类信息放到方法区中后，会创建一个对应的Class 类型的对象实例放到堆(Heap)中, 作为开发人员访问方法区中类定义的入口和切入点。

# 类加载器

# java主要类加载器

类加载器示例：

publicclassTestJDKClassLoader{

  public static void main(String[] args) {
    System.out.println(String.class.getClassLoader());
    System.out.println(com.sun.crypto.provider.DESKeyFactory.class.getClassLoader().getClass().getName());
    System.out.println(TestJDKClassLoader.class.getClassLoader().getClass().getN ame());

    System.out.println();
    ClassLoader appClassLoader = ClassLoader.getSystemClassLoader();
    ClassLoader extClassloader = appClassLoader.getParent();
    ClassLoader bootstrapLoader = extClassloader.getParent();
    System.out.println("the bootstrapLoader : " + bootstrapLoader);
    System.out.println("the extClassloader : " + extClassloader);
    System.out.println("the appClassLoader : " + appClassLoader);
    System.out.println(); System.out.println("bootstrapLoader加载以下文件:"); 
    URL[] urls = Launcher.getBootstrapClassPath().getURLs(); 
    for (int i = 0; i < urls.length; i++) { 
      System.out.println(urls[i]);
    }
    System.out.println(); System.out.println("extClassloader加载以下文件:"); 
    System.out.println(System.getProperty("java.ext.dirs"));
    System.out.println(); System.out.println("appClassLoader加载以下文件:"); 
    System.out.println(System.getProperty("java.class.path"));
  } 
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

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

# 双亲委派机制

# 双亲委派机制说简单点就是，先找父亲加载，不行再由儿子自己加载

# 为何设计双亲委派机制

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

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

# 源码解读：

protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        synchronized (getClassLoadingLock(name)) {
            // 首先检查这个classsh是否已经加载过了
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    // c==null表示没有加载，如果有父类的加载器则让父类加载器加载
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        //如果父类的加载器为空 则说明递归到bootStrapClassloader了
                        //bootStrapClassloader比较特殊无法通过get获取
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {}
                if (c == null) {
                    //如果bootstrapClassLoader 仍然没有加载过，则递归回来，尝试自己去加载class
                    long t1 = System.nanoTime();
                    c = findClass(name);
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

从上图中我们就更容易理解了，当一个Hello.class这样的文件要被加载时。

不考虑我们自定义类加载器，首先会在AppClassLoader中检查是否加载过，如果有那就无需再加载了。如果没有，那么会拿到父加载器，然后调用父加载器的loadClass方法。

父类中同理也会先检查自己是否已经加载过，如果没有再往上，注意这个类似递归的过程，直到到达Bootstrap classLoader之前，都是在检查是否加载过，并不会选择自己去加载。

直到BootstrapClassLoader，已经没有父加载器了，这时候开始考虑自己是否能加载了，如果自己无法加载，会下沉到子加载器去加载，一直到最底层。

如果没有任何加载器能加载，就会抛出ClassNotFoundException。

# 全盘负责委托机制

# 是指当一个ClassLoder装载一个类时，除非显示的使用另外一个ClassLoder，该类所依赖及引用的类也由这个ClassLoder载入。

# 自定义加载器示例

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

# 打破双亲委派机制

# 实现自定义类加载器，重写类加载方法（loadClass），实现自己的加载逻辑（去除加载父加载器逻辑，直接自己加载，非自定义的类还是走双亲委派加载，因为jdk核心类需要引导类加载器加载（沙箱安全机制）），不委派给双亲加载

# tomcat打破双亲委派机制

# tomcat Web容器解决什么问题？

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

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

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

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

# tomcat Web容器为何不能使用默认双亲委派加载机制？

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

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

我们想我们要怎么实现jsp文件的热加载，jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp 是不会重新加载的。那么怎么办呢?我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载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版本;

注意

# 注意:同一个JVM内，两个相同包名和类名的类对象可以共存，因为他们的类加载器可以不一样，所以看两个类对象是否是同一个，除了看类的包名和类名是否都相同之外，还需要他们的类加载器也是同一个才能认为他们是同一个。

上次更新: 2023/05/27, 13:27:05

JVM内存模型→