初识ClassLoader
两种类加载方式：1.隐式装载， 程序在运行过程中当碰到通过new 等方式生成对象时，隐式调用类装载器加载对应的类到jvm中；2.显式装载， 通过class.forname()等方法，显式加载需要的类。
ClassLoader体系
ClassLoader层次结构
- Bootstrap ClassLoader 称为启动类加载器（根装载器），是Java类加载层次中最顶层的类加载器，负责加载JDK中的核心类库（基础类），主要是%JAVA_HOME%/jre/lib下的rt.jar、resources.jar、charsets.jar等，和-Xbootclasspath参数指定的路径以及%JAVA_HOME%/jre/classes中的类。Bootstrap ClassLoader由C++编写，已嵌入到了JVM内核当中，当JVM启动后，Bootstrap ClassLoader也随着启动，负责加载完核心类库后，并构造Extension ClassLoader和App ClassLoader类加载器。
- ExtClassLoader Bootstrp loader加载ExtClassLoader,并且将ExtClassLoader的父加载器设置为Bootstrp loader。ExtClassLoader是用Java写的，具体来说就是 sun.misc.Launcher$ExtClassLoader，ExtClassLoader主要加载%JAVA_HOME%/jre/lib/ext路径下的所有classes目录以及java.ext.dirs系统变量指定的路径中类库。
- AppClassLoader Bootstrp loader加载完ExtClassLoader后，就会加载AppClassLoader,并且将AppClassLoader的父加载器指定为 ExtClassLoader。AppClassLoader也是用Java写成的，它的实现类是 sun.misc.Launcher$AppClassLoader。ClassLoader中有个getSystemClassLoader方法,返回的正是AppclassLoader。AppClassLoader主要负责加载classpath所指定的位置的类或者是jar文档，它也是Java程序默认的类加载器。
- User-Defined ClassLoader 除了Java默认提供的三个ClassLoader之外，用户还可以根据需要定义自已的ClassLoader，而这些自定义的ClassLoader都必须继承自java.lang.ClassLoader类。Java中提供的默认ClassLoader，只加载指定目录下的jar和class，如果我们想加载其它位置的类或jar时，比如：我要加载网络上的一个class文件，通过动态加载到内存之后，要调用这个类中的方法实现我的业务逻辑。在这样的情况下，默认的ClassLoader就不能满足我们的需求了，所以需要定义自己的ClassLoader。Bootstrap ClassLoader、Extension ClassLoader、App ClassLoader，三种加载器对应了java中类不同的类：
1.系统类 2.扩展类 3.由程序员自定义的类。
Bootstrap ClassLoader是Extension ClassLoader的parent，Extension ClassLoader是App ClassLoader的parent。但类加载器的层次体系并不是“继承”体系，而是一个“委派”体系，基本上，每一个ClassLoader实现，都有一个Parent ClassLoader。
可通过如下程序获得Bootstrap ClassLoader类加载器从哪些地方加载了相关的jar或class文件
import java.net.URL;
/**
* <p>description Bootstrap ClassLoader类加载路径</p>
* <p>date 2016年7月31日 下午9:53:23</p>
* @author Admin
* @version
* @since
*/
public class AboutClassLoader {
public static void main(String[] args) {
// TODO Auto-generated method stub
URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
for(int i=0; i < urls.length; i++){
System.out.println(urls[i].toExternalForm());
}
System.out.println("----- 分隔符------");
System.out.println(System.getProperty("sun.boot.class.path"));
}
}打印结果：
file:/D:/Program%20Files/Java/jre7/lib/resources.jar
file:/D:/Program%20Files/Java/jre7/lib/rt.jar
file:/D:/Program%20Files/Java/jre7/lib/sunrsasign.jar
file:/D:/Program%20Files/Java/jre7/lib/jsse.jar
file:/D:/Program%20Files/Java/jre7/lib/jce.jar
file:/D:/Program%20Files/Java/jre7/lib/charsets.jar
file:/D:/Program%20Files/Java/jre7/lib/jfr.jar
file:/D:/Program%20Files/Java/jre7/classes
----- 分隔符------
D:\Program Files\Java\jre7\lib\resources.jar;D:\Program Files\Java\jre7\lib\rt.jar;D:\Program Files\Java\jre7\lib\sunrsasign.jar;D:\Program Files\Java\jre7\lib\jsse.jar;D:\Program Files\Java\jre7\lib\jce.jar;D:\Program Files\Java\jre7\lib\charsets.jar;D:\Program Files\Java\jre7\lib\jfr.jar;D:\Program Files\Java\jre7\classes
ClassLoader类图
Bootstrap ClassLoader不继承自ClassLoader，因为它不是一个普通的Java类，底层由C++编写，已嵌入到了JVM内核当中，当JVM启动后，Bootstrap ClassLoader也随着启动，负责加载完核心类库后，并构造Extension ClassLoader和App ClassLoader类加载器，AppClassLoader和ExtClassLoader都继承于URLClassLoader。可以通过ClassLoader的getParent方法得到当前ClassLoader的parent。Bootstrap ClassLoader比较特殊，因为它不是java class所以Extension ClassLoader的getParent方法返回的是NULL。
/**
* <p><b>description:</b></br> 测试ClassLoader的层次关系，</br>
* ExtClassLoader的类加器是Bootstrap ClassLoader，</br>
* 因为Bootstrap ClassLoader不是一个普通的Java类，</br>
* 所以ExtClassLoader的parent=null</p>
* <p><b>date:</b></br> 2016年8月2日 上午12:26:51</p>
* @author Administrator
* @version
* @since
*/
public class TestClassLoaderRal {
public static void main(String[] args) {
// TODO Auto-generated method stub
ClassLoader loader = TestClassLoaderRal.class.getClassLoader();
while(loader != null){
System.out.println(loader);
System.out.println(loader.getClass().getSuperclass().getName());
loader = loader.getParent();
}
System.out.println(loader);
System.out.println(String.class.getClassLoader());
}
}
打印结果：
sun.misc.Launcher$AppClassLoader@11da5362
java.net.URLClassLoader
sun.misc.Launcher$ExtClassLoader@14985016
java.net.URLClassLoader
null
null
第一行结果说明：TestClassLoaderRal的类加载器是AppClassLoader。
第三行结果说明：AppClassLoader的类加器是ExtClassLoader，即parent=ExtClassLoader。
第五行结果说明：ExtClassLoader的类加器是Bootstrap ClassLoader。
第二行和第四行结果说明：AppClassLoader的父类是URLClassLoader。
第六行结果说明：java.lang.String的类加载器是Bootstrap ClassLoader。
ClassLoader类加载原理
Java由于其晚绑定和“解释型”的特性，类型的加载是到最晚才进行，一个类型直到被调用构造函数、静态方法或者在字段上使用时才会被加载。类装载器就是寻找类或接口字节码文件进行解析并构造JVM内部对象表示的组件，在java中类装载器把一个类装入JVM，经过以下步骤：
1、装载：查找和导入Class文件；
2、链接：其中解析步骤是可以选择的 （a）检查：检查载入的class文件数据的正确性 （b）准备：给类的静态变量分配存储空间 （c）解析：将符号引用转成直接引用;
3、初始化：对静态变量，静态代码块执行初始化工作。
全盘负责委托机制
类装载工作由ClassLoder和其子类负责，Java装载类使用“全盘负责委托机制”。“全盘负责”是指当一个ClassLoder装载一个类时，除非显示的使用另外一个ClassLoder，该类所依赖及引用的类也由这个ClassLoder载入（除非是显式的使用另外一个classloader载入）；“委托机制”是指先委托父类装载器寻找目标类，只有在找不到的情况下才从自己的类路径中查找并装载目标类。
每个ClassLoader实例都有一个父类加载器的引用（不是继承的关系，是一个包含的关系），虚拟机内置的类加载器（Bootstrap ClassLoader）本身没有父类加载器，但可以用作其它ClassLoader实例的的父类加载器。当一个ClassLoader实例需要加载某个类时，它会试图亲自搜索某个类之前，先把这个任务委托给它的父类加载器，这个过程是由上至下依次检查的，首先由最顶层的类加载器Bootstrap ClassLoader试图加载，如果没加载到，则把任务转交给Extension ClassLoader试图加载，如果也没加载到，则转交给App ClassLoader 进行加载，如果它也没有加载得到的话，则返回给委托的发起者，由它到指定的文件系统或网络等URL中加载该类。如果它们都没有加载到这个类时，则抛出ClassNotFoundException异常。否则将这个找到的类生成一个类的定义，并将它加载到内存当中，最后返回这个类在内存中的Class实例对象。
大多数类加载器首先会到自己的parent中查找类或者资源，如果找不到，才会在自己的本地进行查找。事实上，类加载器被定义加载哪些在parent中无法加载到的类，这样在较高层级的类加载器上的类型能够被“赋值”为较低类加载器加载的类型。
JVM搜索类时，如何判断两个Class是否相同？
理解这个问题，需引入另外一个关于Classloader的概念“命名空间”， 它是指要确定某一个类，需要类的全限定名以及加载此类的ClassLoader来共同确定。也就是说即使两个类的全限定名是相同的，但是因为不同的 ClassLoader加载了此类，那么在JVM中它是不同的类。只有两者同时满足的情况下，JVM才认为这两个class是相同的。就算两个class是同一份class字节码，如果被两个不同的ClassLoader实例所加载，JVM也会认为它们是两个不同class。
现在通过实例来验证上述所描述的是否正确：
- 比如Web服务器上的一个Java类NetClassLoaderSimple ，javac编译之后生成字节码文件NetClassLoaderSimple.class。
public class NetClassLoaderSimple {
private NetClassLoaderSimple instance;
public void setNetClassLoaderSimple(Object obj) {
this.instance = (NetClassLoaderSimple)obj;
}
}NetClassLoaderSimple类的setNetClassLoaderSimple方法接收一个Object类型参数，并将它强制转换成org.classloader.simple.NetClassLoaderSimple类型。
- 测试两个class是否相同
首先自定义的类加载器NetworkClassLoader
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.URL;
/**
* <p>description 加载网络class的ClassLoader</p>
* <p>date 2016年8月2日 上午12:06:08</p>
* @author Administrator
* @version
* @since
*/
public class NetworkClassLoader extends ClassLoader {
private String rootUrl;
public NetworkClassLoader(String rootUrl) {
this.rootUrl = rootUrl;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
Class clazz = null;//this.findLoadedClass(name); // 父类已加载
byte[] classData = getClassData(name); //根据类的二进制名称,获得该class文件的字节码数组
if (classData == null) {
throw new ClassNotFoundException();
}
clazz = defineClass(name, classData, 0, classData.length); //将class的字节码数组转换成Class类的实例
return clazz;
}
private byte[] getClassData(String name) {
InputStream is = null;
try {
String path = classNameToPath(name);
URL url = new URL(path);
byte[] buff = new byte[1024*4];
int len = -1;
is = url.openStream();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
while((len = is.read(buff)) != -1) {
baos.write(buff,0,len);
}
return baos.toByteArray();
} catch (Exception e) {
e.printStackTrace();
} finally {
if (is != null) {
try {
is.close();
} catch(IOException e) {
e.printStackTrace();
}
}
}
return null;
}
private String classNameToPath(String name) {
return rootUrl + "/" + name.replace(".", "/") + ".class";
}
}首先获得网络上一个class文件的二进制名称，然后通过自定义的类加载器NetworkClassLoader创建两个实例，并根据网络地址分别加载这份class，并得到这两个ClassLoader实例加载后生成的Class实例clazz1和clazz2，最后将这两个Class实例分别生成具体的实例对象obj1和obj2，再通过反射调用clazz1中的setNetClassLoaderSimple方法
/**
* <p>description 测试ClassLoader，NetClassLoaderSimple.class放在tomcat服务器上</p>
* <p>date 2016年8月2日 上午12:04:25</p>
* @author Administrator
* @version
* @since
*/
public class NewworkClassLoaderTest {
public static void main(String[] args) {
// TODO Auto-generated method stub
try {
//测试加载网络中的class文件
String rootUrl = "http://localhost:8080/j2ee/classes";
String className = "NetClassLoaderSimple";
NetworkClassLoader ncl1 = new NetworkClassLoader(rootUrl);
NetworkClassLoader ncl2 = new NetworkClassLoader(rootUrl);
Class<?> clazz1 = ncl1.loadClass(className);
Class<?> clazz2 = ncl2.loadClass(className);
Object obj1 = clazz1.newInstance();
Object obj2 = clazz2.newInstance();
clazz1.getMethod("setNetClassLoaderSimple", Object.class).invoke(obj1, obj2);
} catch (Exception e) {
e.printStackTrace();
}
}
}
对于JVM来说，它们是两个不同的实例对象，但它们确实是同一份字节码文件，如果试图将这个Class实例生成具体的对象进行转换时，就会抛运行时异常java.lang.ClassCaseException，提示这是两个不同的类型。虽然是同一份class字节码文件，但是由于被两个不同的ClassLoader实例所加载，所以JVM认为它们就是两个不同的类。
为什么使用全盘负责委托机制模式
类加载器的委托行为动机是为了避免相同的类被加载多次。回到1995年，Java的主要方向被放在Applet上，那时候网络带宽优先，所以程序中的类直到用时才会被加载。采用了委托模型以后加大了不同的 ClassLoader的交互能力，比如上面说的，我们JDK本生提供的类库，比如hashmap,linkedlist等等，这些类由bootstrp 类加载器加载了以后，无论你程序中有多少个类加载器，那么这些类其实都是可以共享的，这样就避免了不同的类加载器加载了同样名字的不同类以后造成混乱。考虑到安全因素，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义的类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已经在启动时就被引导类加载器（Bootstrcp ClassLoader）加载，所以用户自定义的ClassLoader永远也无法加载一个自己写的String，除非你改变JDK中ClassLoader搜索类的默认算法。
但是事实上，Java在服务器端展示了强劲的能力，但是服务器端要求类加载器能够反转委派原则，也就是先加载本地的类，如果加载不到，再到parent。
自定义加载器
- 既然JVM已经提供了默认的类加载器，为什么还要定义自已的类加载器呢？
源码分析
public abstract class ClassLoader
protected Class> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
Class c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
} protected Class<?> findClass(String name) throws ClassNotFoundException
{
<span style="white-space:pre"> </span>throw new ClassNotFoundException(name);
}
我们可以看出此方法默认的实现是直接抛出异常，其实这个方法就是留给我们应用程序来override的。那么具体的实现就看你的实现逻辑了，你可以从磁盘读取，也可以从网络上获取class文件的字节流，获取class二进制了以后就可以交给defineClass来实现进一步的加载。
“我们在写自己的ClassLoader的时候，如果想遵循双亲委托机制，则只需要override findClass.”
protected final Class<?> defineClass(String name, byte[] b, int off, int len)
throws ClassFormatError
{
return defineClass(name, b, off, len, null);
}从上面的代码我们看出此方法被定义为了final，这也就意味着此方法不能被Override，其实这也是jvm留给我们的唯一的入口，通过这个唯 一的入口，jvm保证了类文件必须符合Java虚拟机规范规定的类的定义。此方法最后会调用native的方法来实现真正的类的加载工作。
我们来思考下面一个问题：
假如我们自己写了一个java.lang.String的类，我们是否可以替换调JDK本身的类？
答案是否定的。我们不能实现。为什么呢？我看很多网上解释是说双亲委托机制解决这个问题，其实不是非常的准确。因为双亲委托机制是可以打破的，你完全可以自己写一个classLoader来加载自己写的java.lang.String类，但是你会发现也不会加载成功，具体就是因为针对java.*开头的类，jvm的实现中已经保证了必须由bootstrp来加载。
自定义
定义自已的类加载器分为两步：
1、继承java.lang.ClassLoader
2、重写父类的findClass方法
读者可能在这里有疑问，父类有那么多方法，为什么偏偏只重写findClass方法？
因为JDK已经在loadClass方法中帮我们实现了ClassLoader搜索类的算法，当在loadClass方法中搜索不到类时，loadClass方法就会调用findClass方法来搜索类，所以我们只需重写该方法即可。如没有特殊的要求，一般不建议重写loadClass搜索类的算法。下图是API中ClassLoader的loadClass方法：
- findClass()定义加载路径
findClass()的功能是找到class文件并把字节码加载到内存中。
自定义的ClassLoader一般覆盖这个方法。——以便使用不同的加载路径。
在其中调用defineClass()解析字节码。
- loadClass()定义加载机制
载器可以覆盖该方法loadClass()，以便定义不同的加载机制。
例如Servlet中的WebappClassLoader覆盖了该方法，在WEB-INFO/classes目录下查找类文件；在加载时，如果成功，则缓存到ResourceEntry对象。——不同的加载机制。
AppClassLoader覆盖了loadClass()方法。
如果自定义的加载器仅覆盖了findClass，而未覆盖loadClass（即加载规则一样，但加载路径不同）；则调用getClass().getClassLoader()返回的仍然是AppClassLoader！因为真正load类的，还是AppClassLoader。
示例：
自定义一个NetworkClassLoader，用于加载网络上的class文件
public class TestNetClassLoader{
public static void main(String[] args) {
try {
String rootUrl = "http://localhost:8080/j2ee/classes";
NetworkClassLoader networkClassLoader = new NetworkClassLoader(rootUrl);
String classname = "NetClassLoaderSimple";
Class clazz = networkClassLoader.loadClass(classname);
System.out.println(clazz.getClassLoader());
} catch (Exception e) {
e.printStackTrace();
}
}
}NetworkClassLoader@64e48e45
目前常用web服务器中都定义了自己的类加载器，用于加载web应用指定目录下的类库（jar或class），如：Weblogic、Jboss、tomcat等，下面我以Tomcat为例，展示该web容器都定义了哪些个类加载器：
1、新建一个web工程j2ee
2、新建一个ClassLoaderServletTest，用于打印web容器中的ClassLoader层次结构
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
/**
*
* <p><b>description:</b></br> Taomcat Web服务器jar，class类加载器</p>
* <p><b>date:</b></br> 2016年8月3日 下午10:10:01</p>
* @author Administrator
* @version
* @since
*/
public class ClassLoaderServletTest extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
ClassLoader loader = this.getClass().getClassLoader();
while(loader != null) {
out.write(loader.getClass().getName()+"<br/>");
loader = loader.getParent();
}
out.write(String.valueOf(loader));
out.flush();
out.close();
}
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
this.doGet(request, response);
}
}3、配置Servlet，并启动服务
<span style="white-space:pre"> </span><servlet>
<servlet-name>ClassLoaderServletTest</servlet-name>
<servlet-class>ClassLoaderServletTest</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ClassLoaderServletTest</servlet-name>
<url-pattern>/servlet/ClassLoaderServletTest</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
参考文章
深度分析 Java 的 ClassLoader 机制（源码级别）
图解classloader加载class的流程及自定义ClassLoader
深入理解Java虚拟机——JVM高级特性与最佳实践(第2版)
博客内容仅作学习/交流/参考之用，详细内容参见更多网络资源，欢迎大家交流探讨；
为防止经典/实用文章链接丢失，或不易查找，对部分文章全文转载。如果内容信息侵犯了你的合法权益，请告知我，我将及时处理。
E-Mail：dwang2014#hotmail.com（# ——> @）
站在巨人的肩上才能看得更远，一步一个脚印才能走得更远。分享成长，交流进步，转载请注明出处
671
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
