JVM类加载机制（二）：类加载器简要介绍

最新推荐文章于 2024-08-25 00:52:03 发布

进击的NULL

最新推荐文章于 2024-08-25 00:52:03 发布

阅读量169

点赞数

分类专栏： java开发文章标签： JVM类加载器

本文链接：https://blog.csdn.net/u014179251/article/details/86138011

版权

java开发专栏收录该内容

18 篇文章 0 订阅

订阅专栏

本文用意

这篇博客会简要介绍类加载器的一些相关技术点，后面我会专门针对一些技术点进行记录，能力有限，不足之处请多拍砖。

概述

虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类，实现这个动作的代码块称为“类加载器”。

类与类加载器

类加载器用于实现类的加载动作。在java虚拟机中，任意一个类都需要由加载它的加载器和这个类本身一同确立它的唯一性。也就是说，比较两个类是否相等，前提必须要是两个类由同一个类加载器加载。只要加载他们的加载器不同，两个类就必定不相等（利用这个实现热部署，后面会介绍）。因此如下代码输出为false。

public class ClassLoaderTest {

	public static void main(String[] args) throws InstantiationException, IllegalAccessException, ClassNotFoundException {
		ClassLoader myLoader = new ClassLoader() {
			@Override
			public Class<?> loadClass(String name) throws ClassNotFoundException {
				try {
					String fileName = name.substring(name.indexOf(".") + 1) + ".class";
					InputStream is = getClass().getResourceAsStream(fileName);
					if (is == null) {
						return super.loadClass(name);
					}
					byte[] b = new byte[is.available()];
					is.read(b);
					return defineClass(name, b, 0, b.length);
				} catch (Exception e) {
					throw new ClassNotFoundException(name);
				}
			}
		};
		java.lang.Object obj = myLoader.loadClass("classloading.ClassLoaderTest").newInstance();
		System.out.println(obj.getClass());
		System.out.println(obj instanceof classloading.ClassLoaderTest);

	}

}

双亲委派模型

对于Java虚拟机而言，类的加载器只有两种：一种是启动类加载器（Bootstrap ClassLoader），这是由C++语言实现的，属于JVM的一部分；另外一类是其他所有的类加载器，这些是由java语言实现的，可以继承自ClassLoader抽象类或者URLClassLoader类等。这些类独立于虚拟机外部。但是从开发人员角度来看，可以细分为以下三种系统提供的类加载器：

启动类加载器（Bootstrap ClassLoa）：负责将<JAVA_HOME>\lib目录中，并且（注意：这是出于虚拟机安全考虑）是虚拟机识别的（仅按照文件命名，如sun、java开头的或者rt.jar，名字不符合的类库即使放进来也不会被加载。对于这个解释，我觉得光靠命名就够了么？这点我没有深入了，但是总觉得光靠命名限制还是少了点啥。。。）.
扩展类加载器（Extension ClassLoader）：这个加载器有sun.misc.Launcher$ExtClassLoader实现，它负责将<JAVA_HOME>\lib\ext目录中的所有类库加载到虚拟机.
应用程序类加载器（Application ClassLoader）：这个类加载器由sun.misc.Launcher$AppClassLoader实现。一般称为系统类加载器，它负责将用户CLASSPATH环境变量指定路径下的类库，开发者可以直接使用这个类加载器。
当然用户还可以自定义类加载器，下面的图展示类所有类加载器之间的这种层次关系，这是早起JDK（JDK1.2被引入）使用的加载双亲委派模型。

双亲委派模型的工作流程

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此。只有当父加载器反馈自己无法完成这这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。因此，其实所有的加载请求最终都应该传送到顶层的启动类加载器中。

双亲委派模型的意义

双亲委派模型对于Java程序的稳定运作很重要，因为Java类随着它的加载器一起具备了一种带有优先级的层次关系。例如java.lang.Object，存放于rt.jar中，无论哪一个类加载器要去加载这个类，最终都是由Bootstrap ClassLoader去加载，因此Object类在程序的各种类加载器环境中都是一个类。相反，如果没有双亲委派模型，由各个类自己去加载的话，如果用户自己编写了一个java.lang.Object，并放在CLASSPATH下，那系统中将会出现多个不同的Object类，Java体系中最基础的行为也将无法保证，应用程序也将会变得一片混乱。

破坏双亲委派模型

“被破坏是java发展的必然结果！”

双亲委派模型并不是一个强制性的约束模型，而是java设计者给java开发者的一个推荐实现方式。

目前为止，双亲委派模型主要有过三次较大规模的“被破坏”：

第一次是在双亲委派模型出现之前——即JDK1.2发布之前。由于双亲委派模型在JDK1.2之后才有，而java.lang.ClassLoader在JDK1.0就有。JDK1.2为了向前兼容，作了妥协，在ClassLoader抽象类中添加了一个findClass（）方法。
第二次“被破坏”是该机制自身缺陷所致。双亲委派很好的解决了越基础的类由越上层的加载器进行加载。如果基础类又要调用用户的代码，那该怎么办？典型的例子便是JNDI服务，它的代码是由启动器加载类加载（rt.jar），但JNDI的目的是对资源进行集中管理和查找，它需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者（SPI）的代码，但启动类不认识这些代码！！所以java设计团队引入了线程上下文加载器（暂时没有深入了解）。
第三次是由于用户对程序动态性的追求导致的。比如代码热替换、热部署等