类的唯一性
java 中判定两个类是否相同，除了路径要有一致还需要加载他的类加载器要一样。
比如如下伪代码：
package com.classloarder.test;
class ClassLoaderTest
{
main()
{
// 1). 使用ClassLoaderTest的类加载器加载本类
Object obj1 = ClassLoaderTest.class.getClassLoader().loadClass("com.classloarder.test.ClassLoaderTest").newInstance();
System.out.println(obj1.getClass());
System.out.println(obj1 instanceof com.jvm.classloading.ClassLoaderTest); //打印结果为true
Object obj2 = myloader.loadClass("com.classloarder.test.ClassLoaderTest").newInstance();
System.out.println(obj2.getClass());
System.out.println(obj2 instanceof com.jvm.classloading.ClassLoaderTest); //打印结果为false
}
// 自定义类加载器
ClassLoader myLoader = new ClassLoader() {
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
try {
String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";
InputStream is = getClass().getResourceAsStream(fileName);
if (is == null) {
return super.loadClass(fileName);
}
byte[] b = new byte[is.available()];
is.read(b);
return defineClass(name, b, 0, b.length);
} catch (IOException e) {
throw new ClassNotFoundException();
}
}
};
}
双亲委派模型
什么是双亲委派模型呢？java中类加载器大体可以分为两种 启动类加载器（虚拟机的一部分） 和 其他类的加载器。他们之间构成层次关系，具体由哪个类是通过双亲委派行为。
如下图所示：
为什么需要双亲委派行为呢？比如java_home/lib/下有 java.lang.Object.class 就是通过bootstap classloader加载进来的，在程序启动的时候就会被加载进来（程序中有了Object.class）。
此时如果用户自己写了一个 java.lang.Object.class类，当需要加载该类的时候去查找加载器其顺序为 Application ClassLoader-> Extension ClassLoader -> Bootstrap ClassLoader，由于发现Bootstrap ClassLoader 已经加载过java.lang.Object.class所以自定义的Object.class就无法被加载。 这也就防止了程序加载了外部可能带有恶意的Object.class。
具体BootStrap会加载哪些核心类库可以通过如下代码获得
URL[] urls=sun.misc.Launcher.getBootstrapClassPath().getURLs();
for (int i = 0; i < urls.length; i++) {
System.out.println(urls.toExternalform());
}
//在我的计算机上的结果为：
//文件:/jre/lib/endorsed/dom.jar
//文件:/jre/lib/endorsed/sax.jar
//......
双亲委派模型的代码实现
1).构建双亲链条
在intellij中选中类，右键 show diagrams出现如下图：
AppclassLoader构造函数：
UrlClassLoader构造函数：
classLoader的构造函数：
。
JVM启动的时候，已经把上述的对象构造函数把对象继承关系组织好了。这些对象关系式通过如下代码组织好的：
而在真实场景中如果要加载一个类，都是通过如下方法AppClassLoader,ExtClassLoader 都没有重写该逻辑（只是加了一些校验），其加载逻辑如下图所示：
JVM 加载一个类时的步骤
当我们发起一个调用会有对应的线程来处理该请求，此时当前线程的类加载器Thread.getContextClassLoader()会去加载第一个类（假设为A）。
如果类A引用了B，java虚拟机将使用加载类A的类加载器去加载B。
大部分场景下UserClassLoader和Application ClassLoader没有重新 loaderClass()方法，classLoader.loadClass()方法直接使用了委托机制。
由于jvm判断如果class已经存在就不加载了（需要className和对应的加载器也一样）。假设不采用委托加载机制的话类A用AclassLoader加载了String.class ,类B用BClassLoader加载了String.class，这样jvm存在两份String的字节码。
tomcat 中的类加载机制
tomcat中的类加载机制违背了双亲原则，因为tomcat 容器里会有很多的webapp/ 每个容器里的类应该是互不干扰。
其加载步骤为：
1.查找缓存resourceentry有没有有就进行下一步。
2.让系统类加载器尝试加载(AppClassLoader),tomcat下会部署很多应用这些应用中的基础类是一致的。所以应用中需要的基础类应该统一有同一类加载器加载。
3.web应用类加载器自行加载 webappClassLoarder（会为每个应用生成一个类加载器？？）
4.如果还加载不到，委托为common class loader去加载。
所以tomcat中的类加载机制不是一直委托，而是先加载基础应用。对于web应用里的类优先使用其自身加载器。
