在jvm中的类基本上都是由类加载器来加载的（像基本数据类型，数组类型这些不是类加载器加载的，是由jvm自己加载的）。并且对于java中的一个类是由加载它的类加载器和这个类本身所 唯一确定的。也就是说如果两个类是来源同一个Class文件但没有被同一个类加载器加载，那么这两个类就不是相等的。
这里面说的“相等”，是类的Class对象的equals()方法、isAssignableForm()方法、isInstance()方法返回的结果，也包括使用instanceof这个关键字所判定的情况。
双亲委派模型
从使用Java的程序员来说，Java提供的类加载器可以分为这3种：
- 启动类加载器（Bootstrap ClassLoader）：这个类加载器在HotSpot虚拟机中是由C++实现的。主要负责将<JAVA_HOME>\lib 目录下的，或者是-Xbootclasspath参数所指定的路径中的，并且是虚拟机按照文件名识别的，也就是说只会识别虚拟机事先定义好的几个包，你把第三方或者是自己打的jar包放再目录下也不会被这个类加载器加载。
用Class.getClassLoader()方法来获取类的加载器的时候，如果这个类是Bootstrap ClassLoader加载的那么则会返回null。
代码如下：
/**
* Returns the class loader for the class. Some implementations may use
* null to represent the bootstrap class loader. This method will return
* null in such implementations if this class was loaded by the bootstrap
* class loader.
*
*/
@CallerSensitive
public ClassLoader getClassLoader() {
ClassLoader cl = getClassLoader0();
if (cl == null)
return null;
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
ClassLoader.checkClassLoaderPermission(cl, Reflection.getCallerClass());
}
return cl;
}
- 扩展类加载器（Extension ClassLoader）:这个类加载器是sun.misc.Launcher$ExtClassLoader来试下的，它负责加载<JAVA_HOME>\lib\ext目录下类库。我们可以直接在代码中使用这个类加载器。
- 应用程序类加载器（Application ClassLoader）:这个类加载器是sun.misc.Launcher$AppClassLoader实现的。这个类加载器是ClassLoader类中的getSystemClassLoader()方法返回的。所以我们一般称之为类加载器。它负责加载用户类路径（就是ClassPath）上所指定的目录。我们可以直接使用这个类加载器，如果我们没有自定义类加载器一般情况下我们可以使用这个加载器。
我们也可以自己定义类加载器，这些类加载器的关系如下图：
上图所示的这种层次关系我们一般称之为双亲委派模型（Parents Delegation Model）。双亲委派模型要求除了顶层的启动类加载器之外，其他的类加载都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承的方式实现，而是使用组合的方式复用父类加载器的代码。
双亲委派模式的工作过程：
如果一个类加载收到了类加载的请求，它不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每个层次都是这样，因此所欲的加载请求在这个模式下都会传送到顶层的启动类加载器中去。只有当父加载器加载不了这个类的时候子类加载器才会去尝试加载。
虽然这种双亲委派模型虽然是Java推荐的一种实现方式，但是它不是强制的。也就是说我们可以自己定义一个加载器不用去把它交给父加载器。
使用这种双亲委派模型来进行类加载有什么好处呢？首先，它让类加载器具有了一种带有优先级的层次关系。比如类java.lang.Object,它存放在rt.jar中，但是无论哪一个类加载器要加载这个类，最终都会到启动类加载器上进行加载，所以Object类在这种双亲委派模型下都是同一个类。如果没有使用这个模型，那么我们自己编写了一个java.lang.Object，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，那么程序就会很很乱，正确性也无法得到保证。
那如何实现这个双亲委派模型呢？其实java里实现是非常简单的。我们只需要继承ClassLoader后，重新findClass方法即可。具体的ClassLoader里的loadClass()方法如下：
/**
* Loads the class with the specified <a href="#name">binary name</a>. The
* default implementation of this method searches for classes in the
* following order:
*
* @param name
* The <a href="#name">binary name</a> of the class
*
* @param resolve
* If <tt>true</tt> then resolve the class
*
* @return The resulting <tt>Class</tt> object
*
* @throws ClassNotFoundException
* If the class could not be found
*/
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 首先，检查请求的类是否已经被加载过了
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
// 说明父类无法加载
}
if (c == null) {
// If still not found, then invoke findClass in order
// 调用本身的findClass去加载
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;
}
}
