摘要
java的类装载器是java动态性的核心，本文将向大家简要介绍java的类装载器，及相关的parent delegation模型，命名空间，运行时包等概念，同时讨论一些在学习中容易混淆的问题。
类装载器的功能及分类
顾名思义，类装载器是用来把类(class)装载进jvm的。jvm规范定义了两种类型的类装载器：启动类装载器(bootstrap)和用户自定义装载器(user-defined class loader)。
bootstrap是jvm自带的类装载器，用来装载核心类库，如java.lang.*等。如java.lang.object是由bootstrap装载的。
java提供了抽象类classloader，所有用户自定义类装载器都实例化自classloader的子类。 system class loader是一个特殊的用户自定义类装载器，由jvm的实现者提供，在编程者不特别指定装载器的情况下默认装载用户类。系统类装载器可以通过classloader.getsystemclassloader() 方法得到。例1，测试你所使用的jvm的classloader
/*loadersample1.java*/
public class loadersample1 {
public static void main(string[] args) {
class c;
classloader cl;
cl = classloader.getsystemclassloader();
system.out.println(cl);
while (cl != null) {
cl = cl.getparent();
system.out.println(cl);
}
try {
c = class.forname("java.lang.object");
cl = c.getclassloader();
system.out.println("java.lang.object's loader is " + cl);
c = class.forname("loadersample1");
cl = c.getclassloader();
system.out.println("loadersample1's loader is " + cl);
} catch (exception e) {
e.printstacktrace();
}
}
}在我的机器上(sun java 1.5)的运行结果
c:/java>java loadersample1
sun.misc.launcher$appclassloader@82ba41
sun.misc.launcher$extclassloader@923e30
null
java.lang.object's loader is null
loadersample1's loader is sun.misc.launcher$appclassloader@82ba41
第一行表示，系统类装载器实例化自类sun.misc.launcher$appclassloader
第二行表示，系统类装载器的parent实例化自类sun.misc.launcher$extclassloader
第三行表示，系统类装载器parent的parent为bootstrap
第四行表示，核心类java.lang.object是由bootstrap装载的
第五行表示，用户类loadersample1是由系统类装载器装载的
parent delegation模型
从1.2版本开始，java引入了双亲委托模型，从而更好的保证java平台的安全。在此模型下，当一个装载器被请求装载某个类时，它首先委托自己的parent去装载，若parent能装载，则返回这个类所对应的class对象，若parent不能装载，则由parent的请求者去装载。
如图1所示，loader2的parent为loader1，loader1的parent为system class loader。假设loader2被要求装载类myclass，在parent delegation模型下，loader2首先请求loader1代为装载，loader1再请求系统类装载器去装载myclass。若系统装载器能成功装载，则将myclass所对应的class对象的reference返回给loader1，loader1再将reference返回给loader2，从而成功将类myclass装载进虚拟机。若系统类装载器不能装载myclass，loader1会尝试装载myclass，若loader1也不能成功装载，loader2会尝试装载。若所有的parent及loader2本身都不能装载，则装载失败。
若有一个能成功装载，实际装载的类装载器被称为定义类装载器，所有能成功返回class对象的装载器（包括定义类装载器）被称为初始类装载器。如图1所示，假设loader1实际装载了myclass，则loader1为myclass的定义类装载器，loader2和loader1为myclass的初始类装载器。
图 1 parent delegation模型
需要指出的是，class loader是对象，它的父子关系和类的父子关系没有任何关系。一对父子loader可能实例化自同一个class，也可能不是，甚至父loader实例化自子类，子loader实例化自父类。假设myclassloader继承自parentclassloader，我们可以有如下父子loader：
classloader loader1 = new myclassloader();//参数 loader1 为 parentclassloader loader2 = new parentclassloader(loader1);
那么parent delegation模型为什么更安全了？因为在此模型下用户自定义的类装载器不可能装载应该由父亲装载器装载的可靠类，从而防止不可靠甚至恶意的代码代替由父亲装载器装载的可靠代码。实际上，类装载器的编写者可以自由选择不用把请求委托给parent，但正如上所说，会带来安全的问题。
命名空间及其作用
每个类装载器有自己的命名空间，命名空间由所有以此装载器为初始类装载器的类组成。不同命名空间的两个类是不可见的，但只要得到类所对应的class对象的reference，还是可以访问另一命名空间的类。
例2演示了一个命名空间的类如何使用另一命名空间的类。在例子中，loadersample2由系统类装载器装载，loadersample3由自定义的装载器loader负责装载，两个类不在同一命名空间，但loadersample2得到了loadersample3所对应的class对象的reference，所以它可以访问loadersampl3中公共的成员(如age)。
例2 不同命名空间的类的访问
/*loadersample2.java*/
import java.net.*;
import java.lang.reflect.*;
public class loadersample2 {
public static void main(string[] args) {
try {
string path = system.getproperty("user.dir");
url[] us = {new url("file://" + path + "/sub/")};
classloader loader = new urlclassloader(us);
class c = loader.loadclass("loadersample3");
object o = c.newinstance();
field f = c.getfield("age");
int age = f.getint(o);
system.out.println("age is " + age);
} catch (exception e) {
e.printstacktrace();
}
}
}
/*sub/loadersample3.java*/
public class loadersample3 {
static {
system.out.println("loadersample3 loaded");
}
public int age = 30;
}
编译：
javac loadersample2.java;
javac sub/loadersample3.java
运行：java loadersample2
loadersample3 loadedage is 30
从运行结果中可以看出，在类loadersample2中可以创建处于另一命名空间的类loadersample3中的对象并可以访问其公共成员age。
运行时包(runtime package)
由同一类装载器定义装载的属于相同包的类组成了运行时包，决定两个类是不是属于同一个运行时包，不仅要看它们的包名是否相同，还要看类装载器是否相同。只有属于同一运行时包的类才能互相访问包可见的类和成员。这样的限制避免了用户自己的代码冒充核心类库的类访问核心类库包可见成员的情况。假设用户自己定义了一个类java.lang.yes，并用用户自定义的类装载器装载，由于java.lang.yes和核心类库java.lang.*由不同的装载器装载，它们属于不同的运行时包，所以java.lang.yes不能访问核心类库java.lang中类的包可见的成员。
总结
在简单讨论了类装载器，parent delegation模型，命名空间，运行时包后，相信大家已经对它们的作用有了一定的了解。命名空间并没有完全禁止属于不同空间的类的互相访问，双亲委托模型加强了java的安全，运行时包增加了对包可见成员的保护。
parent delegation模型
从1.2版本开始，java引入了双亲委托模型，从而更好的保证java平台的安全。在此模型下，当一个装载器被请求装载某个类时，它首先委托自己的parent去装载，若parent能装载，则返回这个类所对应的class对象，若parent不能装载，则由parent的请求者去装载。
如图1所示，loader2的parent为loader1，loader1的parent为system class loader。假设loader2被要求装载类myclass，在parent delegation模型下，loader2首先请求loader1代为装载，loader1再请求系统类装载器去装载myclass。若系统装载器能成功装载，则将myclass所对应的class对象的reference返回给loader1，loader1再将reference返回给loader2，从而成功将类myclass装载进虚拟机。若系统类装载器不能装载myclass，loader1会尝试装载myclass，若loader1也不能成功装载，loader2会尝试装载。若所有的parent及loader2本身都不能装载，则装载失败。
若有一个能成功装载，实际装载的类装载器被称为定义类装载器，所有能成功返回class对象的装载器（包括定义类装载器）被称为初始类装载器。如图1所示，假设loader1实际装载了myclass，则loader1为myclass的定义类装载器，loader2和loader1为myclass的初始类装载器。
图 1 parent delegation模型
需要指出的是，class loader是对象，它的父子关系和类的父子关系没有任何关系。一对父子loader可能实例化自同一个class，也可能不是，甚至父loader实例化自子类，子loader实例化自父类。假设myclassloader继承自parentclassloader，我们可以有如下父子loader：
classloader loader1 = new myclassloader();//参数 loader1 为 parentclassloader loader2 = new parentclassloader(loader1);
那么parent delegation模型为什么更安全了？因为在此模型下用户自定义的类装载器不可能装载应该由父亲装载器装载的可靠类，从而防止不可靠甚至恶意的代码代替由父亲装载器装载的可靠代码。实际上，类装载器的编写者可以自由选择不用把请求委托给parent，但正如上所说，会带来安全的问题。
命名空间及其作用
每个类装载器有自己的命名空间，命名空间由所有以此装载器为初始类装载器的类组成。不同命名空间的两个类是不可见的，但只要得到类所对应的class对象的reference，还是可以访问另一命名空间的类。
例2演示了一个命名空间的类如何使用另一命名空间的类。在例子中，loadersample2由系统类装载器装载，loadersample3由自定义的装载器loader负责装载，两个类不在同一命名空间，但loadersample2得到了loadersample3所对应的class对象的reference，所以它可以访问loadersampl3中公共的成员(如age)。
例2 不同命名空间的类的访问
/*loadersample2.java*/
import java.net.*;
import java.lang.reflect.*;
public class loadersample2 {
public static void main(string[] args) {
try {
string path = system.getproperty("user.dir");
url[] us = {new url("file://" + path + "/sub/")};
classloader loader = new urlclassloader(us);
class c = loader.loadclass("loadersample3");
object o = c.newinstance();
field f = c.getfield("age");
int age = f.getint(o);
system.out.println("age is " + age);
} catch (exception e) {
e.printstacktrace();
}
}
}
/*sub/loadersample3.java*/
public class loadersample3 {
static {
system.out.println("loadersample3 loaded");
}
public int age = 30;
}
编译：
javac loadersample2.java;
javac sub/loadersample3.java
运行：java loadersample2
loadersample3 loadedage is 30
从运行结果中可以看出，在类loadersample2中可以创建处于另一命名空间的类loadersample3中的对象并可以访问其公共成员age。
运行时包(runtime package)
由同一类装载器定义装载的属于相同包的类组成了运行时包，决定两个类是不是属于同一个运行时包，不仅要看它们的包名是否相同，还要看类装载器是否相同。只有属于同一运行时包的类才能互相访问包可见的类和成员。这样的限制避免了用户自己的代码冒充核心类库的类访问核心类库包可见成员的情况。假设用户自己定义了一个类java.lang.yes，并用用户自定义的类装载器装载，由于java.lang.yes和核心类库java.lang.*由不同的装载器装载，它们属于不同的运行时包，所以java.lang.yes不能访问核心类库java.lang中类的包可见的成员。
总结
在简单讨论了类装载器，parent delegation模型，命名空间，运行时包后，相信大家已经对它们的作用有了一定的了解。命名空间并没有完全禁止属于不同空间的类的互相访问，双亲委托模型加强了java的安全，运行时包增加了对包可见成员的保护。
parent delegation模型
从1.2版本开始，java引入了双亲委托模型，从而更好的保证java平台的安全。在此模型下，当一个装载器被请求装载某个类时，它首先委托自己的parent去装载，若parent能装载，则返回这个类所对应的class对象，若parent不能装载，则由parent的请求者去装载。
如图1所示，loader2的parent为loader1，loader1的parent为system class loader。假设loader2被要求装载类myclass，在parent delegation模型下，loader2首先请求loader1代为装载，loader1再请求系统类装载器去装载myclass。若系统装载器能成功装载，则将myclass所对应的class对象的reference返回给loader1，loader1再将reference返回给loader2，从而成功将类myclass装载进虚拟机。若系统类装载器不能装载myclass，loader1会尝试装载myclass，若loader1也不能成功装载，loader2会尝试装载。若所有的parent及loader2本身都不能装载，则装载失败。
若有一个能成功装载，实际装载的类装载器被称为定义类装载器，所有能成功返回class对象的装载器（包括定义类装载器）被称为初始类装载器。如图1所示，假设loader1实际装载了myclass，则loader1为myclass的定义类装载器，loader2和loader1为myclass的初始类装载器。
图 1 parent delegation模型
需要指出的是，class loader是对象，它的父子关系和类的父子关系没有任何关系。一对父子loader可能实例化自同一个class，也可能不是，甚至父loader实例化自子类，子loader实例化自父类。假设myclassloader继承自parentclassloader，我们可以有如下父子loader：
classloader loader1 = new myclassloader();//参数 loader1 为 parentclassloader loader2 = new parentclassloader(loader1);
那么parent delegation模型为什么更安全了？因为在此模型下用户自定义的类装载器不可能装载应该由父亲装载器装载的可靠类，从而防止不可靠甚至恶意的代码代替由父亲装载器装载的可靠代码。实际上，类装载器的编写者可以自由选择不用把请求委托给parent，但正如上所说，会带来安全的问题。
命名空间及其作用
每个类装载器有自己的命名空间，命名空间由所有以此装载器为初始类装载器的类组成。不同命名空间的两个类是不可见的，但只要得到类所对应的class对象的reference，还是可以访问另一命名空间的类。
例2演示了一个命名空间的类如何使用另一命名空间的类。在例子中，loadersample2由系统类装载器装载，loadersample3由自定义的装载器loader负责装载，两个类不在同一命名空间，但loadersample2得到了loadersample3所对应的class对象的reference，所以它可以访问loadersampl3中公共的成员(如age)。
例2 不同命名空间的类的访问
/*loadersample2.java*/
import java.net.*;
import java.lang.reflect.*;
public class loadersample2 {
public static void main(string[] args) {
try {
string path = system.getproperty("user.dir");
url[] us = {new url("file://" + path + "/sub/")};
classloader loader = new urlclassloader(us);
class c = loader.loadclass("loadersample3");
object o = c.newinstance();
field f = c.getfield("age");
int age = f.getint(o);
system.out.println("age is " + age);
} catch (exception e) {
e.printstacktrace();
}
}
}
/*sub/loadersample3.java*/
public class loadersample3 {
static {
system.out.println("loadersample3 loaded");
}
public int age = 30;
}
编译：
javac loadersample2.java;
javac sub/loadersample3.java
运行：java loadersample2
loadersample3 loadedage is 30
从运行结果中可以看出，在类loadersample2中可以创建处于另一命名空间的类loadersample3中的对象并可以访问其公共成员age。
运行时包(runtime package)
由同一类装载器定义装载的属于相同包的类组成了运行时包，决定两个类是不是属于同一个运行时包，不仅要看它们的包名是否相同，还要看类装载器是否相同。只有属于同一运行时包的类才能互相访问包可见的类和成员。这样的限制避免了用户自己的代码冒充核心类库的类访问核心类库包可见成员的情况。假设用户自己定义了一个类java.lang.yes，并用用户自定义的类装载器装载，由于java.lang.yes和核心类库java.lang.*由不同的装载器装载，它们属于不同的运行时包，所以java.lang.yes不能访问核心类库java.lang中类的包可见的成员。
总结
在简单讨论了类装载器，parent delegation模型，命名空间，运行时包后，相信大家已经对它们的作用有了一定的了解。命名空间并没有完全禁止属于不同空间的类的互相访问，双亲委托模型加强了java的安全，运行时包增加了对包可见成员的保护。
闽公网安备 35060202000074号