一、Java中的class加载机制有以下三个特性：
1、全盘负责制
“全盘负责”是指当一个ClassLoader装载一个类时，除非显示地使用另一个ClassLoader，则该类所依赖及引用的类也由这个CladdLoader载入。
例如，系统类加载器AppClassLoader加载入口类（含有main方法的类）时，会把main方法所依赖的类及引用的类也载入，依此类推。“全盘负责”机制也可称为当前类加载器负责机制。显然，入口类所依赖的类及引用的类的当前类加载器就是入口类的类加载器。
2、双亲委派制（Parent Delegation）
1) 委托机制的意义
主要是出于安全性考虑，确保Java的核心类在内存中只有一份字节码，比如两个类A和类B都要加载java.lang.System类，通过双亲委派，系统只会加载一次java.lang.System，即使用户重写了java.lang.System，也不会有机会被加载到，除非你重写ClassLoader。不过有时候为了做容器隔离，需要在JVM中对同一个Class有多份字节码，例如OSGI和Pandora技术，后面会详细谈到。
2) 委托机制是必须的吗？
“双亲委派”机制只是Java推荐的机制，并不是强制的机制。我们可以继承java.lang.ClassLoader类，实现自己的类加载器。如果想保持双亲委派模型，就应该重写findClass(name)方法；如果想破坏双亲委派模型，可以重写loadClass(name)方法。使用自己的类加载器，有很多高级玩法，例如OSGI和Pandora的隔离机制，就是通过自定义ClassLoader来实现的。
3) 如何实现双亲委派？
默认的ClassLoader的loadClass()实现方式是双亲委派模型，我们可以继承ClassLoader去自定义自己的ClassLoader，如果不重写loadClass方法，那么默认也是双亲委派的。例如，URLClassLoader只是实现了findClass( )，而loadClass( )还是继承ClassLoader的，所以其依然是Parent Delegation的。下面是ClassLoader.loadClass( )源码，看下双亲委派是怎么实现的。
1）Check这个class是否被装载过，如果有直接返回。
装载过的类是被缓存起来的，这样确保了同一个类不会被加载两次，不过有一个问题，用什么来作为class缓存的key呢？在JVM中，class是用类全名（包名+类名） 再加上加载这个类的classLoader来唯一标识的，例如class的类全名是C1，classLoader是L1，那么这个class instance在JVM中的key就是(C1, L1)，此时另一个classLoader L2也加载了该类，那么将会有另一个class instance (C1, L2)，这两个class instance是不同的type，如果这两个class的object做赋值操作的话，会出现ClassCastException。
2）尝试从parent classloader去加载类。
3）如果parent是null（当parent是bootstrap时就是null了），试图从BootstrapClassLoader的native方法去加载类。
4）在上面尝试都失败的情况下，尝试自己去加载。
3、按需加载 （On-demand Loading）
什么时候Class会被JVM加载呢? 回答是只有当class被用到时，才会被load，例如new instance，调用其static变量和方法，或使用反射调用其class对象。
这个很容易验证，在启动参数里加上-verbose:class, 就可以清晰看到class是何时被加载的。
二、JVM中classloader加载class的顺序
三、ContextClassloader的用处
1）什么是ContextClassLoader
Thread的一个属性，可以在运行时，通过setContextClassLoader方法来指定一个合适的classloader作为这个线程的contextClassLoader，然后在任何地方通过getContextClassLoader方法来获得此contextClassLoader，用它载入我们所需要的Class。如果没有被显示set过，默认是system classloader。利用这个特性，我们可以“打破”classloader委托机制，父classloader可以获得当前线程的contextClassLoader，而这个contextClassLoader可以是它的子classloader或者其他的classloader。
2) 为什么要使用ContextClassLoader
Thread context classloaders provide a back door around the classloading delegation scheme.
Take JNDI for instance: its guts are implemented by bootstrap classes in rt.jar (starting with J2SE 1.3), but these core JNDI classes may load JNDI providers implemented by independent vendors and potentially deployed in the application‘s -classpath. This scenario calls for a parent classloader (the primordial one in this case) to load a class visible to one of its child classloaders (the system one, for example). Normal J2SE delegation does not work, and the workaround is to make the core JNDI classes use thread context loaders, thus effectively "tunneling" through the classloader hierarchy in the direction opposite to the proper delegation.
这个后门在SPI的实现中很有用，因为接口类是在parent classloader中加载的，而实现类是由它的child classloader加载的，使用contextClassLoader可以绕过双亲委派，达到在parent中使用child classloader去load class的目的。其过程如下图所示：
这样的示例在JDK中很常见，例如JNDI和JAXP都是通过这样的方式去加载具体的provider的。例如
javax.xml.ws.spi.FactoryFinder
Object find(String factoryId, String fallbackClassName){
ClassLoader classLoader;
try {
// get context classloader, mostly it‘s system classloader, but it could be user-defined classloader as well.
classLoader = Thread.currentThread().getContextClassLoader();
} catch (Exception x) {
throw new WebServiceException(x.toString(), x);
}
String serviceId = "META-INF/services/" + factoryId;
// try to find services in CLASSPATH
// Note that if it‘s not system classloader, this will invoke user-defined classloader‘s findResource( ) to find services when all its parents failed.
try {
InputStream is=null;
if (classLoader == null) {
is=ClassLoader.getSystemResourceAsStream(serviceId);
} else {
is=classLoader.getResourceAsStream(serviceId);
}
.....
return newInstance(fallbackClassName, classLoader);
}