虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机的外部去实现,以便让应用程序自己决定如何去获取所需要的类,实现这个动作的代码模块成为“类加载器”;
类加载器虽然只用于实现类的加载动作,但它在Java程序中起到的作用却远远不限于类加载阶段。
对于任意一个类,都需要由加载他的类加载器和这个类本身一同确定其在java虚拟机中的唯一性,每一个类加载器,都拥有一个独立的类名称空间。
可以通俗的理解:比较两个类是否相等(是同一个类),只有在这两个类是由同一个类加载器加载的前提下才有意义,否则,即使这两个类来源于同一个Class文件,被同一个虚拟机加载,只要加载他们的类加载器不同,那么这两个类就必定不相等。
1.从Java虚拟机的角度来说,只存在两种不同的类加载器:一种是启动类加载器,这个类加载器使用C++语言实现,是虚拟机自身的一部分;另一部分就是所有的其他的类加载器,这些类加载器都是由java语言实现,独立于虚拟机外部,并且全部继承自抽象类java.lang.ClassLoader
2.从Java开发人员的角度,类加载器可以划分的更为细致,绝大部分java程序都是用到三种系统提供的类加载器
①启动类加载器:这个类加载器负责将存放在
②扩展类加载器:这个加载器由sun.misc.Launcher$ExtClassLoader实现,他负责加载
③应用程序类加载器:这个类加载器由sun.misc.Launcher$AppClassLoader实现。由于这个类加载时ClassLoader中的getSystemClassLoader()方法的返回值,所以一般也被称为系统类加载器。他负责加载用户类路径(ClassPath)上所指定的类库,开发者可以直接使用这个类加载器。
图中展示的类加载器之间的这种层次关系,称为类加载器的双亲委派模型。
双亲委派模型要求除了顶层的启动类加载器外,其余的类加载器都应当有自己的父亲加载器。这里的类加载器之间的父子关系
一般不会以继承的方式实现,而是都是使用组合的关系来复用父加载器的代码。
模型的工作过程
如果一个类加载器收到了类加载的请求,他首先不会自己去尝试加载这个类,而是吧这个请求交给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当类加载器反馈自己无法完成这个加载请求(它的搜索范围没有找到所需要的类)时,子加载器才会尝试自己去加载。
简单的例子去理解:
使用双亲委派模型来组织类加载器之间的关系,有一个显而易见的好处就是Java类随着他的类加载器一起具备了一种带有优先级的层次关系。
例如:类java.lang.Object,它存放在rt.jar中,无论哪一个类加载器去加载这个类,最终都是委派给处于模型最顶端的启动类加载器中去加载,因此Object在程序的各种类加载器环境中都是同一个类(最终真正加载的类加载器是同一个)。相反,如果没有使用双亲委派模型,有各个类加载器自行去完成加载的话,如果用户自己编写了一个java。lang。Object类,并放在程序的Classpath中,那系统中将会出现多个不同的Object类,Java类型体系中最基础的行为也就无法保证,应用程序也将变的混乱。
实现双亲委派模型的逻辑:
实现双亲委派模型的代码都集中在java.lang.ClassLoader的loadClass方法中。
实现逻辑很简单:
①先检查类是否被加载过,如果没有加载则调用父加载器的loadClass方法。
②如果父加载器为空,则默认使用启动类加载器(最顶层)作为父加载器。
③如果父加载器加载失败,抛出异常,在调用自己的findClass方法进行加载。
代码如下:
protected synchronized Class> loadClass(String name,boolean bool)
{
//首先检查是否已经被加载过了,name为类名
Class class1 = findLoadedClass(name);
if(class1 == null)
{
//如果class为空,表示函数返回null,没有加载过
if(parent != null)
{
//父加载器不为空,表示不是启动类加载器
//调用父加载器的loadClass方法
//注意这一步,进去之后,如果父加载器仍旧不为null,则还会往上委派
class1 = parent.loadClass(name,false);
}else {
//父加载器为空,则表示当前已经到了最顶层的启动类加载器
class1 = findBootstrapClassOrNull(name);
}
if(class1 == null)
{
//经过上述代码,仍旧为null,表示父加载器无法完成。
//由自己来完成,所以把自定义的代码实现在findClass中
//而loadClass方法实际上是实现双亲委派模型的逻辑
class1 = findClass(name);
}
}
}
通过上述代码,也就不难理解其逻辑。
需要注意的是,根据上述代码,我们知道,如果自定义类加载器,也就不是去覆盖loadClass方法了,而是把具体的实现逻辑放到自己所写的findClass中,这样也就保证了所写的类加载器是符合双亲委派模型的,因为,loadClass方法实际上就是维护了双亲委派模型的逻辑。
所以,这里也就有了自定义类加载器的步骤,如果看明白了loadClass方法,那就很简单
定义自已的类加载器分为两步:
1、继承java.lang.ClassLoader(这一步,实际上也就有了loadClass方法,以及具体的逻辑所需的变量等内容)
2、重写父类的findClass方法(上述已经介绍过原因了)