流程
首先类加载在整个体系结构的哪一个环节呢？见红色圈住的部分。
类加载器分为那几个过程呢？五个过程
加载
根据类的全限定名（简单理解为类的绝对路径，见附录），找到指定的字节码文件，并在内存中生产一个java.lang.Class的对象，存放在方法区中。
验证
作用：确保字节码文件中包含的信息符合Class文件格式规范，对虚拟机来说是安全的。
规则一直在更新，大体有四种
1. 文件格式验证 基于二进制字节流进行分析。
2. 元数据验证（可以理解成是对类层面的信息验证） 对类的元数据进行语义分析。
3. 字节码验证（对方法层面的信息验证）* 对方法体语义分析。
4. 符号引用验证 验证根据引用能否找到对应的类、方法、字段。
如果确认字节码文件是安全的，通过 -Xverify:none 关闭大部分验证。
准备
在方法区中为类的静态变量分配内存并初始化。
解析
将常量池中的符号引用替换为直接引用的过程。
初始化
执行类构造器<client>方法，<client>方法是由编译器自动收集的类中的类变量赋值操作和静态语句块中的语句。并且会保证父类的<client>方法先执行。
加载过程由谁来执行的
类加载器 classLoader，也就是 Java.lang.ClassLoader。核心函数是loadClass
protected synchronized Class<?> loadClass (String name,boolean resolve) throws ClassNotFoundException {
// 首先检查类是不是已经被加载
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
//如果父类不为空，优先检查父类的
c = parent.loadClass(name, false);
} else { //否则检查当前的
c = findBootstrapClass0(name);
}
} catch (ClassNotFoundException e) { // 如果还是找不到，就触发子类本身的findClass方法去找
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
类加载器
两大类,四小种：JDK默认提供的三种，用户自定义的一种。
默认的三种有（非继承关系）
-
Bootstrap ClassLoader 启动类加载器，没有父类。
- 一般是native code（C++）实现
- 用于加载虚拟机的核心类（<JAVA_HOME>/jre/lib/rt.jar），包括扩展类/系统类加载器
-
Extension ClassLoader 扩展类加载器，父类加载器为空
- java实现，是rt.jar中sun.misc.Launcher的内部类sun.misc.Launcher$ExtClassLoader (miscellaneous)
- 用于加载扩展库中的类（<JAVA_HOME>/jre/lib/ext）
-
System ClassLoder 父类加载器Ext ClassLoader
- java实现，是rt.jar中sun.misc.Launcher的内部类sun.misc.Launcher$AppClassLoader
- 用于CLASS_PATH中的类
用户自定义的有一种 父类是 System ClassLoader
- 继承自java.lang.ClassLoader
同名文件处理
这里有一个双亲委派的概念。就是当查找一个类的时候，会一层一层的向上委托查询，如果父类加载器有对应的类，就直接从父类加载该类。
这样的双亲委派有好处，但是有些场景我们是希望破坏双亲委派的
-
场景一：我们想在顶层的classLoader中加载底层的classLoader
- 可以在线程中放入底层的classLoader到Thread.setContextClassLoader()中，然后在顶层的classLoader中使用Thread.getContextClassLoader()加载第三方的classLoader实现。
-
场景二：实现类热部署
- 一个class只能被一个classLoader加载一次，当需要实现代码热部署的时候可以每次都new一个自定义的classLoader来加载新的Class文件。
场景三：Tomcat中使用WebAppClassLoader进行单独加载，加载不了再去委托父加载器去加载。
