ClassLoader：类加载器。Java中所有的类都通过类加载器j进行加载，包含几种加载器：
- BootStrapClassLoader 使用C++编写属于Java的JVM层面。用于加载核心类库（lib）下的类库
- ExtensionClassLoader 用于加载Java lib/ext下的类库
- ApplicationClassLoader 也称SystemClassLoader 用于加载classPath下的类库
首先Java中类加载有五个过程：加载、验证、准备、解析、初始化。类加载器通过类全名读取类的二进制z字节流到JVM，然后转化成一个与目标类d对应的Class实例。JVM提供上面三种类加载器。一个类由不同加载器实例加载时，会在方法区产生不同类，但是彼此不可见，在堆中产生不同class实例。
ApplicationClassLoader的parent是ExtensionClassLoader,ExtensionClassLoader的parent是BootStrapClassLoader。
我们使用Java类库中的类进行获取ClassLoader：
System.out.println(String.class.getClassLoader()); System.out.println(ArrayList.class.getClassLoader());
结果：
这是因为Java环境获取不到对应class，Java的类或者说jre/lib包下的类，由根加载器BootStrapClassLoader加载，环境在C++中。
我们编写任意一个类AA，使用
System.out.println(AA.class.getClassLoader());
得到如下结果：
得到的结果是AppClassLoader也就是之前说的ApplicationClassLoader，再使用
System.out.println(AA.class.getClassLoader().getParent());
得到如下结果
再使用
System.out.println(AA.class.getClassLoader().getParent().getParent());
得到的结果便是null了。因为拿不到BootStrapClassLoader
调用对象的getClass()方法是获取当前对象类的类型，该部分数据存储在方法区中，getClass().getClassLoader()方法是获取当前类型的类加载器。由于Java中所有类都通过类加载器加载到jvm中，且各个类加载器存在父子关系，子知道父的存在，父不知道子的存在，由于此不同子之间加载的类型是无法互相访问的（虽然都在方法区中），正是因为这样，通过当前类的加载器加载资源能够保证是同一个类加载器加载的。
InputStream resourceAsStream = AA.class.getClassLoader().getResourceAsStream("aa.txt");
JVM加载一个类时由BootStrapClassLoader首先进行查找加载，找不到时再有其子类ExtensionClassLoader查找加载，再找不到时由ApplicationClassLoader查找加载。这也就是“双亲委派机制”。
2.线程中的ClassLoader
每个运行中的线程都有成员ContextClassLoader线程上下文ClassLoader，用于在运行时动态加载其它类。通过
ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
可以获取当前运行线程的上下文ClassLoader。通过
Thread.currentThread().setContextClassLoader(new ClassLoader() {
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
return super.loadClass(name);
}
});
可以设置当前线程的ContextClassLoader
事实上所有Java程序都运行在线程中，若一个程序没有通过上述方法设置过ContextClassLoader，对于一般的jJava类下面两个方法获取的ClassLoader一般是同一个：
this.getClass().getClassLoader();
Thread.currentThread().getContextClassLoader();
上述两个方法区别：
第一个得到的是静态的ClassLoader，表明类的加载者
第二个得到的是动态的ClassLoader，表明当前线程。对于单例模式的类、静态的类载入一次后可能被其它多个线程调用，对于这些类，载入的ClassLoader和执行的线程的ClassLoader通常不同。
3.web应用中ClassLoader
以tomcat中webapp的ClassLoader来说，这类Class Loader与之前说过的机制略有不同，web应用线程会尝试自己加载（ContextPath/web-inf/....)中的类，若是加载不到，再请求父加载器加载。对于webapp线程，他的contextCloassloader是WebAppClassLoader，对于tomcat Server线程，他的ContextClassLoader是catalinaClassLoader。除了上述获取动态ClassLoader和获取静态ClassLoader外还可通过：
ClassLoader.getSystemClassLoader();
获取系统入口点所使用的ClassLoader。此类SystemClassLoader与根ClassLoader不同，JVM下SystemClassLoader通常为AppClassLoader。
ClassLoader可广泛用于资源载入层面，对于类资源，类可通过new，文件可进行IO。
类资源：
1.Class clazz=Class.forName("com.dabai.AA"); AA aa=(AA)clazz.newInstance(): 2.AA aa=new AA(); 3.ClassLoader cl; Class clazz=cl.loadClass("com.dabai.AA"); AA aa=clazz.newInstance();
文件资源：
假设AA类想要读取 com/dabai/conf/ 下文件conf.properties，我们可以通过绝对路径和相对路径读取，绝对路径自然是包括磁盘符的，相对路径的值是相对ClassLoader。将ClassLoader视为一棵树，相对与该ClassLoader路径后的资源都能被加载到
InputStream resourceAsStream3 = Thread.currentThread().getContextClassLoader().getResourceAsStream("com/dabai/conf/conf.properties"）;
获取文件URL绝对路径：
URL resource = BB.class.getClassLoader().getResource("com/dabai/Test/conf/conf.properties");
System.out.println(resource);
Java中getResource()会进入到ClassLoader getResource（）中，通过main方法启动时，当前ClassLoader就是AppClassLoader，其parent就是ExtensionClassLoader，再其parent就是BootStrapClassLoader。当BootStrapResource都无法找到对应资源时，就从findResource（name）中将返回值返回。
4.其它
ClassLoader的线程安全问题
类加载器需要b保证线程安全，当装载一个不存在的类时，由于双亲委派机制的存在，强制加载会报错SecurityException。
自定义类加载器的话可继承ClassLoader并重写findClass方法
随口一说：类加载器不加载接口，嗯。