0%

18.2.2 类加载机制

发表于 更新于 分类于 ， ，

18.2.2 类加载机制

JVM的类加载机制

JVM的类加载机制主要有如下三种：

  • 1.全盘负责。所谓全盘负责,就是当一个类加载器负责加载某个Class时,该Class所依赖的和引用的其他Class也将由该类加载器负责载入,除非显式使用另外一个类加载器来载入。
  • 2.父类委托。所谓父类委托,则是先让parent(父)类加载器试图加载该Class,只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类.
  • 3.缓存机制。缓存机制将会保证所有加载过的Class都会被缓存,当程序中需要使用某个Class时,类加载器先从缓存区中搜寻该Class,只有当缓存区中不存在该Class对象时,系统才会读取该类对应的二进制数据,并将其转换成Class对象,存入缓存区中。这就是为什么修改了Class后,必须重新启动JVM,程序所做的修改才会生效的原因。

类加载器之间的父子关系并不是类继承上的父子关系,这里的父子关系是类加载器实例之间的关系.

自定义类加载器

自定义的类加载器通过继承ClassLoader来实现。JVM中这4种类加载器的层次结构如图18.1所示。
这里有一张图片
下面程序示范了访问JVM的类加载器。

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
import java.util.*;
import java.net.*;
import java.io.*;

public class ClassLoaderPropTest
{
	public static void main(String[] args)
		throws IOException
	{
		// 获取系统类加载器
		ClassLoader systemLoader = ClassLoader.getSystemClassLoader();
		System.out.println("系统类加载器：" + systemLoader);
		/*
		获取系统类加载器的加载路径——通常由CLASSPATH环境变量指定
		如果操作系统没有指定CLASSPATH环境变量，默认以当前路径作为
		系统类加载器的加载路径
		*/
		Enumeration<URL> em1 = systemLoader.getResources("");
		while(em1.hasMoreElements())
		{
			System.out.println(em1.nextElement());
		}
		// 获取系统类加载器的父类加载器：得到扩展类加载器
		ClassLoader extensionLader = systemLoader.getParent();
		System.out.println("扩展类加载器：" + extensionLader);
		System.out.println("扩展类加载器的加载路径："
			+ System.getProperty("java.ext.dirs"));
		System.out.println("扩展类加载器的parent: "
			+ extensionLader.getParent());
	}
}

运行上面程序,会看到如下运行结果:

1
2
3
4
5
系统类加载器：sun.misc.Launcher$AppClassLoader@2a139a55
file:/G:/Desktop/%e9%9a%8f%e4%b9%a6%e6%ba%90%e7%a0%81/%e7%96%af%e7%8b%82Java%e8%ae%b2%e4%b9%89%e7%ac%ac%e4%b8%89%e7%89%88%e5%85%89%e7%9b%98/codes/18/18.2/
扩展类加载器：sun.misc.Launcher$ExtClassLoader@70dea4e
扩展类加载器的加载路径：E:\java\jdk1.8.0_91\jre\lib\ext;C:\Windows\Sun\Java\lib\ext
扩展类加载器的parent: null

从上面运行结果可以看出,:
系统类加载器的加载路径是程序运行的当前路径,
扩展类加载器的加载路径是:

1
E:\java\jdk1.8.0_91\jre\lib\ext;C:\Windows\Sun\Java\lib\ext

但此处看到扩展类加载器的父加载器是null,并不是根类加载器这是因为根类加载器并没有继承ClassLoader抽象类,所以扩展类加载器的getParent方法返回null但实际上,扩展类加载器的父类加载器是根类加载器,只是根类加载器并不是Java实现的。
从运行结果可以看出,系统类加载器是AppClassLoader的实例,扩展类加载器是ExtClassLoader的实例。实际上,这两个类都是URLClassLoader类的实例。
JVM的根类加载器并不是Java实现的,而且由于程序通常无须访问根类加载器,因此访问扩展类加载器的父类加载器时返回null。

类加载器加载Class步骤

类加载器加载Class大致要经过如下8个步骤。

  1. 检测此Class是否载入过(即在缓存区中是否有此Class),如果有则直接进入第8步,否则接着执行第2步。
  2. 如果父类加载器不存在(如果没有父类加载器,则要么parent一定是根类加载器,要么本身就是根类加载器),则跳到第4步执行;如果父类加载器存在,则接着执行第3步。
  3. 请求使用父类加载器去载入目标类,如果成功载入则跳到第8步,否则接着执行第5步。
  4. 请求使用根类加载器来载入目标类,如果成功载入则跳到第8步,否则跳到第7步。
  5. 当前类加载器尝试寻找Class文件(从与此ClassLoader相关的类路径中寻找),如果找到则执行第6步,如果找不到则跳到第7步。
  6. 从文件中载入Class,成功载入后跳到第8步。
  7. 抛出ClassNotFoundException异常。
  8. 返回对应的 java.lang.Class对象。

其中,第5、6步允许重写ClassLoader的findClass方法来实现自己的载入策略,甚至重写loadClass方法来实现自己的载入过程.

原文链接: 18.2.2 类加载机制