Java 虚拟机把描述类的数据从 Class 文件加载到内存，并对数据进行校验、转换解析和初始化，最 终形成可以被虚拟机直接使用的Java 类型，这个过程被称作虚拟机的类加载机制。与那些在编译时需 要进行连接的语言不同，在Java 语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成 的，这种策略让Java 语言进行提前编译会面临额外的困难，也会让类加载时稍微增加一些性能开销， 但是却为Java 应用提供了极高的扩展性和灵活性， Java 天生可以动态扩展的语言特性就是依赖运行期动 态加载和动态连接这个特点实现的
内存结构概述
详细图
pc寄存器：每一个线程一份
栈：虚拟机栈，每个线程一份
堆：对象分配空间（Gc重点）
方法区：存放常量，类信息
类加载器子系统
类加载器子系统作用：
类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。
ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。
加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）
类加载器ClassLoader角色
class file（在下图中就是Car.class文件）存在于本地硬盘上，可以理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。
class file加载到JVM中，被称为DNA元数据模板（在下图中就是内存中的Car Class），放在方法区。
在.class文件–>JVM–>最终成为元数据模板，此过程就要一个运输工具（类装载器Class Loader），扮演一个快递员的角色。
流程
完整的流程图如下所示：
加载阶段
加载：
- 通过一个类的全限定名获取定义此类的二进制字节流
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
- 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
加载class文件的方式：
- 从本地系统中直接加载
- 通过网络获取，典型场景：Web Applet
- 从zip压缩包中读取，成为日后jar、war格式的基础
- 运行时计算生成，使用最多的是：动态代理技术
- 由其他文件生成，典型场景：JSP应用从专有数据库中提取.class文件，比较少见
- 从加密文件中获取，典型的防Class文件被反编译的保护措施
链接阶段
链接分为三个子阶段：验证 -> 准备 -> 解析
验证(Verify)
目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全
主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证。
准备(Prepare)
为类变量（static变量）分配内存并且设置该类变量的默认初始值，即零值
这里不包含用final修饰的static，因为final在编译的时候就会分配好了默认值，准备阶段会显式初始化
注意：这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中
初始化阶段
类的初始化时机
- 创建类的实例
- 访问某个类或接口的静态变量，或者对该静态变量赋值
- 调用类的静态方法
- 反射（比如：Class.forName(“com.atguigu.Test”)）
- 初始化一个类的子类
- Java虚拟机启动时被标明为启动类的类
- JDK7开始提供的动态语言支持：java.lang.invoke.MethodHandle实例的解析结果REF_getStatic、REF putStatic、REF_invokeStatic句柄对应的类没有初始化，则初始化
除了以上七种情况，其他使用Java类的方式都被看作是对类的被动使用，都不会导致类的初始化，即不会执行初始化阶段（不会调用 clinit() 方法和 init() 方法）
clinit()
初始化阶段就是执行类构造器方法<clinit>()的过程
此方法不需定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。也就是说，当我们代码中包含static变量的时候，就会有clinit方法
<clinit>()方法中的指令按语句在源文件中出现的顺序执行
<clinit>()不同于类的构造器。（关联：构造器是虚拟机视角下的<init>()）
若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕
虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁
类加载器的分类
类加载器负责加载所有的类，其为所有被载入内存中的类生成一个java.lang.Class实例对象。一旦一个类被加载入JVM中，同一个类就不会被再次载入了。正如一个对象有一个唯一的标识一样，一个载入JVM的类也有一个唯一的标识。
关于唯一标识符：
在Java中，一个类用其全限定类名（包括包名和类名）作为标识；
但在JVM中，一个类用其全限定类名和其类加载器作为其唯一标识。
类加载器的任务是根据一个类的全限定名来读取此类的二进制字节流到JVM中，然后转换为一个与目标类对应的java.lang.Class对象实例，在虚拟机提供了3种类加载器，启动（Bootstrap）类加载器、扩展（Extension）类加载器、系统（System）类加载器（也称应用类加载器），如
类加载器可以大致划分为以下三类：
启动类加载器：
BootstrapClassLoader，启动类加载器主要加载的是JVM自身需要的类，这个类加载使用C++语言实现的，是虚拟机自身的一部分，负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.开头的类均被BootstrapClassLoader加载）。启动类加载器是无法被Java程序直接引用的。<mark style="box-sizing: border-box; outline: 0px; background-color: rgb(248, 248, 64); color: rgb(0, 0, 0); overflow-wrap: break-word;">总结一句话：启动类加载器加载java运行过程中的核心类库JRE\lib\rt.jar, sunrsasign.jar, charsets.jar, jce.jar, jsse.jar, plugin.jar 以及存放在JRE\classes里的类，也就是JDK提供的类等常见的比如：Object、Stirng、List…</mark>扩展类加载器： ExtensionClassLoader，该加载器由 sun.misc.Launcher$ExtClassLoader实现，它负责加载 JDK\jre\lib\ext目录中，或者由 java.ext.dirs系统变量指定的路径中的所有类库（如javax.开头的类），开发者可以直接使用扩展类加载器。
应用程序类加载器： ApplicationClassLoader，该类加载器由 sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。<mark style="box-sizing: border-box; outline: 0px; background-color: rgb(248, 248, 64); color: rgb(0, 0, 0); overflow-wrap: break-word;">总结一句话：应用程序类加载器加载CLASSPATH变量指定路径下的类 即指你自已在项目工程中编写的类</mark>
线程上下文类加载器：除了以上列举的三种类加载器，其实还有一种比较特殊的类型就是线程上下文类加载器。类似
Thread.currentThread().getContextClassLoader()获取线程上下文类加载器，线程上下文加载器其实很重要，它违背（破坏）双亲委派模型，很好地打破了双亲委派模型的局限性，尽管我们在开发中很少用到，但是框架组件开发绝对要频繁使用到线程上下文类加载器，如Tomcat等等…
在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，因为JVM自带的类加载器（ClassLoader）只是懂得从本地文件系统加载标准的java class文件，因此如果编写了自己的ClassLoader，便可以做到如下几点：
1、在执行非置信代码之前，自动验证数字签名。
2、动态地创建符合用户特定需要的定制化构建类。
3、从特定的场所取得java class，例如数据库中和网络中。
image.png
需要注意的是，Java虚拟机对class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象，而且加载某个类的class文件时，Java虚拟机默认采用的是双亲委派模式即把请求交由父类处理，它一种任务委派模式，下面将会详细讲到！
虚拟机自带的加载器
启动类加载器（引导类加载器，Bootstrap ClassLoader）
- 这个类加载使用C/C++语言实现的，嵌套在JVM内部
- 它用来加载Java的核心库（JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容），用于提供JVM自身需要的类
- 并不继承自java.lang.ClassLoader，没有父加载器
- 加载扩展类和应用程序类加载器，并作为他们的父类加载器
- 出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类
扩展类加载器（Extension ClassLoader）
- Java语言编写，由sun.misc.Launcher$ExtClassLoader实现
- 派生于ClassLoader类
- 父类加载器为启动类加载器
- 从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录（扩展目录）下加载类库。如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载
应用程序类加载器（也称为系统类加载器，AppClassLoader）
- Java语言编写，由sun.misc.LaunchersAppClassLoader实现
- 派生于ClassLoader类
- 父类加载器为扩展类加载器
- 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
- 该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载
- 通过classLoader.getSystemclassLoader()方法可以获取到该类加载器
用户自定义类加载器
什么时候需要自定义类加载器？
在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。那为什么还需要自定义类加载器？
- 隔离加载类（比如说我假设现在Spring框架，和RocketMQ有包名路径完全一样的类，类名也一样，这个时候类就冲突了。不过一般的主流框架和中间件都会自定义类加载器，实现不同的框架，中间价之间是隔离的）
- 修改类加载的方式
- 扩展加载源（还可以考虑从数据库中加载类，路由器等等不同的地方）
- 防止源码泄漏（对字节码文件进行解密，自己用的时候通过自定义类加载器来对其进行解密）
如何自定义类加载器？
- 开发人员可以通过继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求
- 在JDK1.2之前，在自定义类加载器时，总会去继承ClassLoader类并重写loadClass()方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法，而是建议把自定义的类加载逻辑写在findclass()方法中
- 在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URIClassLoader类，这样就可以避免自己去编写findclass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。
关于ClassLoader
ClassLoader类，它是一个抽象类，其后所有的类加载器都继承自ClassLoader（不包括启动类加载器）
sun.misc.Launcher 它是一个java虚拟机的入口应用
获取ClassLoader途径
双亲委派机制
双亲委派机制原理
Java虚拟机对class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式
- 如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行；
- 如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；
- 如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。
- 父类加载器一层一层往下分配任务，如果子类加载器能加载，则加载此类，如果将加载任务分配至系统类加载器也无法加载此类，则抛出异常
双亲委派机制优势
通过上面的例子，我们可以知道，双亲机制可以
避免类的重复加载
保护程序安全，防止核心API被随意篡改
- 自定义类：自定义java.lang.String 没有被加载。
- 自定义类：java.lang.ShkStart（报错：阻止创建 java.lang开头的类） 引导类无法加载
沙箱安全机制
- 自定义String类时：在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件（rt.jar包中java.lang.String.class），报错信息说没有main方法，就是因为加载的是rt.jar包中的String类。
- 这样可以保证对java核心源代码的保护，这就是沙箱安全机制。
其他
如何判断两个class对象是否相同？
在JVM中表示两个class对象是否为同一个类存在两个必要条件：
- 类的完整类名必须一致，包括包名
- 加载这个类的ClassLoader（指ClassLoader实例对象）必须相同
- 换句话说，在JVM中，即使这两个类对象（class对象）来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的ClassLoader实例对象不同，那么这两个类对象也是不相等的
对类加载器的引用
- JVM必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的
- 如果一个类型是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中
- 当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的
例子
下面我们看一个程序：
package com.jvm.classloaderQi;
public class ClassloaderTest {
public static void main(String[] args) {
//获取ClassloaderTest类的加载器
ClassLoader classLoader= ClassloaderTest.class.getClassLoader();
System.out.println(classLoader);
System.out.println(classLoader.getParent()); //获取ClassloaderTest类的父类加载器
System.out.println(classLoader.getParent().getParent());
}
}
运行结果：
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@1b6d3586
null
从上面的结果可以看出，并没有获取到ExtClassLoader的父加载器（Loader），原因是Bootstrap Loader（启动类加载器）是用C++语言实现的（这里仅限于Hotspot，也就是JDK1.5之后默认的虚拟机，有很多其他的虚拟机是用Java语言实现的），找不到一个确定的返回父Loader的方式，于是就返回null。至于$符号就是内部类的含义。
源码解析
AppClassLoader的父类加载器是ExtClassLoader，ExtClassLoader的父类加载器为空，但逻辑上是启动类加载器；ExtClassLoader类和AppClassLoader类两个都是Java编写的，位于rt.jar中，也就是由启动类加载器负责加载这两个类；这两个类的源码在Java的官方源码包src.zip中不存在，只能反编译或者参考OpenJDK8 jdk/share/classes/sun/misc/Launcher.java源码,如下图：
这两个都继承自URLClassLoader，彼此没有继承关系，默认的包级访问，所以无法在sun.misc包外访问，JDK8下 URLClassLoader的类继承关系如下图，下面详细介绍各类加载器。
ClassLoader
ClassLoader是一个抽象类，主要定义了加载类和资源的方法，并在方法实现中定义了委托模型，如下图：
以loadClass和getResource方法的实现为例说明，如下：
public Class<?> loadClass(String name) throws ClassNotFoundException {
return loadClass(name, false);
}
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
//返回加载指定类的锁，避免并发加载时的重复加载和死锁
synchronized (getClassLoadingLock(name)) {
//首先检查该类是否已加载，最终由本地方法findLoadedClass0实现
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
//如果父类加载器不为空，委托父类加载器加载该类
c = parent.loadClass(name, false);
} else {//父类加载器为空
//从启动类加载器中查找该类，最终由本地方法findBootstrapClass实现
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
//未能读取该类，则调用findClass查找该类，自定义类加载可覆写该方法
//注意ClassLoader中未提供具体实现，只是抛出ClassNotFoundException
if (c == null) {
long t1 = System.nanoTime();
c = findClass(name);
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
//完成类的解析和初始化，最终由本地方法resolveClass0实现
resolveClass(c);
}
return c;
}
}
public URL getResource(String name) {
URL url;
if (parent != null) {
//如果父类加载器不为空，委托给父类加载器加载该资源
url = parent.getResource(name);
} else {
//如果父类加载器为空，则从启动类路径加载该资源，最终实现在sun.misc.Launcher.getBootstrapClassPath()
url = getBootstrapResource(name);
}
if (url == null) {
//如果找不到，则调用findResource继续查找，同上面的findClass，ClassLoader中未提供具体实现，返回null
url = findResource(name);
}
return url;
}
注意ClassLoader对外的loadClass方法只有一个参数String name，调用同名的保护方法时传递的resolve属性为false，并且委托父类加载器加载时传递的resolve属性也是false，这是因为从JDK1.1之后，JVM不再依赖类加载器去链接，而是完全由JVM根据类的实际使用情况来链接。
其中读取资源相关方法是读取类路径下文件，jar包等的最常用的方法，Spring中解析classpath开头的资源路径时底层也是调用这些方法，示例如下：
@Test
public void test4() throws Exception {
ClassLoader classLoader=MyTest.class.getClassLoader();
//默认从类路径下查找
// InputStream in=classLoader.getResourceAsStream("test.txt");
//getSystemResourceAsStream是利用系统类加载器读取资源
// InputStream in=ClassLoader.getSystemResourceAsStream("test.txt");
//默认从MyTest所在的当前目录读取，加上/表示从类路径下读取
InputStream in=MyTest.class.getResourceAsStream("/test.txt");
readTxt(in);
}
@Test
public void test5() throws Exception {
ClassLoader classLoader=MyTest.class.getClassLoader();
//读取多个同名文件，支持读取jar包中的文件
Enumeration<URL> resources=classLoader.getResources("META-INF/MANIFEST.MF");
while (resources.hasMoreElements()){
URL url=resources.nextElement();
String path=url.getPath();
System.out.println(path);
if(path.contains("junit-4.12.jar")){
readTxt(url.openStream());
}
}
}
private void readTxt(InputStream in) throws Exception{
BufferedReader reader=new BufferedReader(new InputStreamReader(in));
String s=reader.readLine();
while (s!=null){
System.out.println(s);
s=reader.readLine();
}
}
ClassLoader还有一个重要的方法getSystemClassLoader()，该方法返回的系统类加载器通常作为新的类加载器实例的默认父类加载器，并负责加载应用程序自身的jar包，默认的系统启动器是ClassLoader的子类。这个方法会在JVM启动创建java.lang.Thread对象时调用，并将返回结果作为Thread的contextClassLoade。如果设置了属性java.system.class.loader，则getSystemClassLoader()方法返回该属性指定的全限定名的类加载器，该类加载器由默认的系统类加载器加载，要求其必须提供只有一个参数ClassLoader的公开构造方法，然后会将默认的系统加载器作为参数调用该构造方法，创建一个指定类名的类加载器实例，将该实例作为getSystemClassLoader()的返回结果。系统类加载器的初始化逻辑在initSystemClassLoader()方法中实现，如下：
private static synchronized void initSystemClassLoader() {
//sclSet属性为true,表示系统类加载器已初始化
if (!sclSet) {
//scl属性就是系统类加载器，不为空说明已初始化完成，此调用非法
if (scl != null)
throw new IllegalStateException("recursive invocation");
//获取Launcher
sun.misc.Launcher l = sun.misc.Launcher.getLauncher();
if (l != null) {
Throwable oops = null;
//从Launcher获取类加载器作为默认的系统类加载器
scl = l.getClassLoader();
try {
//SystemClassLoaderAction实现了自定义系统类加载器的逻辑
scl = AccessController.doPrivileged(
new SystemClassLoaderAction(scl));
} catch (PrivilegedActionException pae) {
oops = pae.getCause();
if (oops instanceof InvocationTargetException) {
oops = oops.getCause();
}
}
//异常处理
if (oops != null) {
if (oops instanceof Error) {
throw (Error) oops;
} else {
// wrap the exception
throw new Error(oops);
}
}
}
sclSet = true;
}
}
class SystemClassLoaderAction
implements PrivilegedExceptionAction<ClassLoader> {
private ClassLoader parent;
SystemClassLoaderAction(ClassLoader parent) {
this.parent = parent;
}
public ClassLoader run() throws Exception {
//读取属性
String cls = System.getProperty("java.system.class.loader");
//未设置该属性返回默认的系统类加载器
if (cls == null) {
return parent;
}
//利用默认的系统类加载器加载特定类
Constructor<?> ctor = Class.forName(cls, true, parent)
.getDeclaredConstructor(new Class<?>[] { ClassLoader.class });
//调用特定类的构造方法，默认的系统类加载器作为其父类加载器
ClassLoader sys = (ClassLoader) ctor.newInstance(
new Object[] { parent });
//修改当前主线程的ContextClassLoader
Thread.currentThread().setContextClassLoader(sys);
return sys;
}
}
再看下sun.misc.Launcher#getClassLoader()方法的实现，如下：
private static Launcher launcher = new Launcher();
//getLauncher返回的是Launcher静态私有属性launcher
public static Launcher getLauncher() {
return launcher;
}
private ClassLoader loader;
//getClassLoader返回Launcher的私有属性loader，在构造方法中初始化
public ClassLoader getClassLoader() {
return loader;
}
public Launcher() {
//创建扩展类加载器
ClassLoader extcl;
try {
extcl = ExtClassLoader.getExtClassLoader();
} catch (IOException e) {
throw new InternalError(
"Could not create extension class loader", e);
}
//创建应用类加载器
try {
loader = AppClassLoader.getAppClassLoader(extcl);
} catch (IOException e) {
throw new InternalError(
"Could not create application class loader", e);
}
//将AppClassLoader作为当前线程的ContextClassLoader
Thread.currentThread().setContextClassLoader(loader);
//根据属性java.security.manager创建系统安全管理器
String s = System.getProperty("java.security.manager");
if (s != null) {
SecurityManager sm = null;
if ("".equals(s) || "default".equals(s)) {
sm = new java.lang.SecurityManager();
} else {
try {
sm = (SecurityManager)loader.loadClass(s).newInstance();
} catch (IllegalAccessException e) {
} catch (InstantiationException e) {
} catch (ClassNotFoundException e) {
} catch (ClassCastException e) {
}
}
if (sm != null) {
System.setSecurityManager(sm);
} else {
throw new InternalError(
"Could not create SecurityManager: " + s);
}
}
}
即默认的系统类加载器就是AppClassLoader，AppClassLoader的父类加载器就是ExtClassLoader。
最后看看Class#getClassLoader()方法的实现，如下：
//Class类实例由JVM创建，所以没有对外的公开构造方法，也无法通过反射创建
//通过反射修改已有Class类实例的classLoader属性也会报错NoSuchFieldException
private Class(ClassLoader loader) {
classLoader = loader;
}
@CallerSensitive
public ClassLoader getClassLoader() {
//实际返回的是Class实例的classLoader属性，该属性在实例创建时初始化
ClassLoader cl = getClassLoader0();
if (cl == null)
return null;
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
ClassLoader.checkClassLoaderPermission(cl, Reflection.getCallerClass());
}
return cl;
}
ClassLoader getClassLoader0() { return classLoader; }
private final ClassLoader classLoader;
即默认情况下自定义类调用getClassLoader返回AppClassLoader，AppClassLoader是在JVM创建该类的Class类实例时设置的，JVM设置的ClassLoader实际是当前线程的ContextClassLoader，具体逻辑下回分解。
SecureClassLoader
SecureClassLoader扩展自ClassLoader，添加了从源码文件获取类定义的安全控制的支持，主要是新增了两个子类可覆写的方法，其中CodeSource用于保存源码文件相关的属性，如URL，代码签名，签名证书等，即CodeSource表示一个唯一的源码文件，ProtectionDomain表示一系列的安全控制的策略，如下：
protected final Class<?> defineClass(String name, java.nio.ByteBuffer b,
CodeSource cs)
{
return defineClass(name, b, getProtectionDomain(cs));
}
protected final Class<?> defineClass(String name,
byte[] b, int off, int len,
CodeSource cs)
{
return defineClass(name, b, off, len, getProtectionDomain(cs));
}
private ProtectionDomain getProtectionDomain(CodeSource cs) {
if (cs == null)
return null;
ProtectionDomain pd = null;
//添加了一个ProtectionDomain的缓存，即pdcache
synchronized (pdcache) {
pd = pdcache.get(cs);
if (pd == null) {
PermissionCollection perms = getPermissions(cs);
pd = new ProtectionDomain(cs, perms, this, null);
pdcache.put(cs, pd);
if (debug != null) {
debug.println(" getPermissions "+ pd);
debug.println("");
}
}
}
return pd;
}
URLClassLoader
URLClassLoader扩展自SecureClassLoader，这个类加载器可以用指向jar包或者文件夹的URL来加载类或者其他资源，URL路径以“/”结束表示该URL指向一个文件夹，否则指向一个jar包。创建此URLClassLoader实例的线程的AccessControlContext会被用做加载类或者资源的安全控制。
URLClassLoader提供了findResource(final String name)和findClass(final String name)的具体实现，这两方法在ClassLoader中前者返回null，后者抛出ClassNotFoundException异常，如下：
public URL findResource(final String name) {
//acc是从当前线程获取的AccessControlContext，在URLClassLoader实例化时指定
URL url = AccessController.doPrivileged(
new PrivilegedAction<URL>() {
public URL run() {
//ucp就是sun.misc.URLClassPath,用来搜索类文件或者其他资源
return ucp.findResource(name, true);
}
}, acc);
return url != null ? ucp.checkURL(url) : null;
}
protected Class<?> findClass(final String name)
throws ClassNotFoundException
{
final Class<?> result;
try {
result = AccessController.doPrivileged(
new PrivilegedExceptionAction<Class<?>>() {
public Class<?> run() throws ClassNotFoundException {
//将路径中的"."替换成"/"，并在末尾加上.class，即将类名转换成对应的class文件名
String path = name.replace('.', '/').concat(".class");
//读取对应的class文件
Resource res = ucp.getResource(path, false);
if (res != null) {
try {
//将class文件转换成Class实例，此方法是URLClassLoader的私有方法，在加载类的时候会创建对应的表示包结构的Package对象
return defineClass(name, res);
} catch (IOException e) {
throw new ClassNotFoundException(name, e);
}
} else {
return null;
}
}
}, acc);
} catch (java.security.PrivilegedActionException pae) {
throw (ClassNotFoundException) pae.getException();
}
if (result == null) {
throw new ClassNotFoundException(name);
}
return result;
}
除此之外，URLClassLoader改写了原有的getResourceAsStream(String name)和Enumeration<URL> findResources(final String name)的实现，如下：
public InputStream getResourceAsStream(String name) {
URL url = getResource(name);
try {
if (url == null) {
return null;
}
//这两步的效果等价于url.openStream()
URLConnection urlc = url.openConnection();
InputStream is = urlc.getInputStream();
//主要的改动在于添加资源的自动关闭，closeables是一个保存弱引用key的WeakHashMap
//即当内存不足的时候，资源会自动关闭，无需等到该资源对象本身被回收掉
if (urlc instanceof JarURLConnection) {
JarURLConnection juc = (JarURLConnection)urlc;
JarFile jar = juc.getJarFile();
synchronized (closeables) {
if (!closeables.containsKey(jar)) {
closeables.put(jar, null);
}
}
} else if (urlc instanceof sun.net.www.protocol.file.FileURLConnection) {
synchronized (closeables) {
closeables.put(is, null);
}
}
return is;
} catch (IOException e) {
return null;
}
}
public Enumeration<URL> findResources(final String name)
throws IOException
{
final Enumeration<URL> e = ucp.findResources(name, true);
//因为需要进行安全检查，这里对findResources的结果做了一层包装
return new Enumeration<URL>() {
private URL url = null;
private boolean next() {
//如果不为空则返回true，
if (url != null) {
return true;
}
do {
//获取下一个元素
URL u = AccessController.doPrivileged(
new PrivilegedAction<URL>() {
public URL run() {
if (!e.hasMoreElements())
return null;
return e.nextElement();
}
}, acc);
//如果获取的为空则终止循环
if (u == null)
break;
url = ucp.checkURL(u);
} while (url == null);//最外层的url是否为空是对checkURL的结果做判断
//如果不为空说明存在下一个元素，且该元素保存在url属性中，返回true
return url != null;
}
public URL nextElement() {
if (!next()) {
throw new NoSuchElementException();
}
//返回url属性，将其置空，方便下一次遍历
URL u = url;
url = null;
return u;
}
public boolean hasMoreElements() {
return next();
}
};
}
即URLClassLoader中的类和其他资源的搜索和读取都由sun.misc.URLClassPath实现。
最后关注下URLClassLoader的构造方法，URLClassLoader的父类的构造方法的基础上增加了一个必填的参数URL[]，如下图：
可选的ClassLoader用于指定父类加载器，如果没有默认使用系统类加载器；另外两个可选的URLStreamHandlerFactory和AccessControlContext都是用于构造URLClassPath，AccessControlContext如果没有则使用当前线程的AccessControlContext，因为构造URLClassPath时URL[]和AccessControlContext是必须的参数。
、ExtClassLoader
ExtClassLoader扩展自URLClassLoader，未改写父类的任何方法，重点关注其初始化方法：
private static ExtClassLoader createExtClassLoader() throws IOException {
try {
return AccessController.doPrivileged(
new PrivilegedExceptionAction<ExtClassLoader>() {
public ExtClassLoader run() throws IOException {
//获取扩展路径的文件列表
final File[] dirs = getExtDirs();
int len = dirs.length;
for (int i = 0; i < len; i++) {
//将加载的文件注册到MetaIndex中
MetaIndex.registerDirectory(dirs[i]);
}
return new ExtClassLoader(dirs);
}
});
} catch (java.security.PrivilegedActionException e) {
throw (IOException) e.getException();
}
}
public ExtClassLoader(File[] dirs) throws IOException {
//getExtURLs将文件列表转换成URL列表
super(getExtURLs(dirs), null, factory);
//此类加载器的URLClassPath实例初始化查找缓存
SharedSecrets.getJavaNetAccess().
getURLClassPath(this).initLookupCache(this);
}
private static File[] getExtDirs() {
//读取属性值，要求指定路径是一个文件夹
String s = System.getProperty("java.ext.dirs");
File[] dirs;
if (s != null) {
//pathSeparator表示路径分割字符，unix下为“：”，windows下为“；”
StringTokenizer st =
new StringTokenizer(s, File.pathSeparator);
int count = st.countTokens();
dirs = new File[count];
//将文件路径转换成File对象
for (int i = 0; i < count; i++) {
dirs[i] = new File(st.nextToken());
}
} else {
dirs = new File[0];
}
return dirs;
}
private static URL[] getExtURLs(File[] dirs) throws IOException {
Vector<URL> urls = new Vector<URL>();
//依次遍历所有的路径
for (int i = 0; i < dirs.length; i++) {
//返回该路径下的文件名列表，如果为空则返回null，忽略该路径
String[] files = dirs[i].list();
if (files != null) {
for (int j = 0; j < files.length; j++) {
//如果文件名不包含meta-index，则将其转换成File对象，获取其URL
if (!files[j].equals("meta-index")) {
File f = new File(dirs[i], files[j]);
urls.add(getFileURL(f));
}
}
}
}
//最后将Vector中的内容复制到URL数组中
URL[] ua = new URL[urls.size()];
urls.copyInto(ua);
return ua;
}
java.ext.dirs在默认情况下JAVA_HOME/jre/lib/ext，测试代码如下：
@Test
public void test6() throws Exception {
//结果是C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext;C:\windows\Sun\Java\lib\ext
System.out.println(System.getProperty("java.ext.dirs"));
}
5、AppClassLoader
AppClassLoader扩展自URLClassLoader，同ExtClassLoader，未改写父类的任何方法，重点关注其初始化方法，如下：
public static ClassLoader getAppClassLoader(final ClassLoader extcl)
throws IOException
{
//读取系统属性
final String s = System.getProperty("java.class.path");
//读取类路径下的文件，跟getExtDirs方法不同，getClassPath不要求路径是一个文件夹
final File[] path = (s == null) ? new File[0] : getClassPath(s);
return AccessController.doPrivileged(
new PrivilegedAction<AppClassLoader>() {
public AppClassLoader run() {
//将类路径下的文件列表有File[]转换成URL数组
URL[] urls =
(s == null) ? new URL[0] : pathToURLs(path);
return new AppClassLoader(urls, extcl);
}
});
}
private static File[] getClassPath(String cp) {
File[] path;
if (cp != null) {
int count = 0, maxCount = 1;
int pos = 0, lastPos = 0;
//统计路径分隔符的数量
while ((pos = cp.indexOf(File.pathSeparator, lastPos)) != -1) {
maxCount++;
lastPos = pos + 1;
}
path = new File[maxCount];
lastPos = pos = 0;
//不断遍历读取每个路径
while ((pos = cp.indexOf(File.pathSeparator, lastPos)) != -1) {
//找到一个新的非空路径
if (pos - lastPos > 0) {
path[count++] = new File(cp.substring(lastPos, pos));
} else {
//空路径，如;;中间的部分，转换成路径为"."的File
path[count++] = new File(".");
}
lastPos = pos + 1;
}
// 确保包含最后一个路径
if (lastPos < cp.length()) {
//最后一个路径非空
path[count++] = new File(cp.substring(lastPos));
} else {
//最后一个路径为空
path[count++] = new File(".");
}
//数组复制
if (count != maxCount) {
File[] tmp = new File[count];
System.arraycopy(path, 0, tmp, 0, count);
path = tmp;
}
} else {
path = new File[0];
}
return path;
}
java.class.path默认情况下就是启动命令中的classpath选项的值，可比对Ideal的启动命令选项同该属性的值。
URLClassPath
URLClassPath提供了搜索和读取指定类的功能，以findResource(String name, boolean check)为例说明，如下：
public URLClassPath(URL[] urls,
URLStreamHandlerFactory factory,
AccessControlContext acc) {
for (int i = 0; i < urls.length; i++) {
//path属性包含原始的URL
path.add(urls[i]);
}
//将原始的URL放入urls属性中，该属性保存未打开的URL
push(urls);
if (factory != null) {
jarHandler = factory.createURLStreamHandler("jar");
}
if (DISABLE_ACC_CHECKING)
this.acc = null;
else
this.acc = acc;
}
public URL findResource(String name, boolean check) {
Loader loader;
//根据资源名查找包含该资源的Loader对象，int数组目标Loader对象在Loader列表中的索引
int[] cache = getLookupCache(name);
//依次从包含目标资源的loader对象中读取资源
for (int i = 0; (loader = getNextLoader(cache, i)) != null; i++) {
URL url = loader.findResource(name, check);
if (url != null) {
return url;
}
}
return null;
}
private synchronized int[] getLookupCache(String name) {
//lookupCacheURLs包含已经加载并缓存的URL路径
//lookupCacheEnabled参数表示是否启用查找缓存，通过属性sun.cds.enableSharedLookupCache指定，默认为true
if (lookupCacheURLs == null || !lookupCacheEnabled) {
return null;
}
//lookupCacheLoader在initLookupCache方法中完成初始化，该方法在URLClassPath实例化完成调用，通常是URLClassLoader的父类加载器
//getLookupCacheForClassLoader是一个本地方法，该方法返回包含指定name的资源的路径在URL[]中的索引
//比如URL[]为{a.jar, b.jar, c.jar, d.jar}，a.jar和c.jar都包含有foo/Bar.class，则该方法返回[0,2]
int[] cache = getLookupCacheForClassLoader(lookupCacheLoader, name);
if (cache != null && cache.length > 0) {
int maxindex = cache[cache.length - 1]; // cache[] is strictly ascending.
//确保对应路径的Loader对象已实例化
if (!ensureLoaderOpened(maxindex)) {
if (DEBUG_LOOKUP_CACHE) {
System.out.println("Expanded loaders FAILED " +
loaders.size() + " for maxindex=" + maxindex);
}
return null;
}
}
return cache;
}
Loader是URLClassPath定义的私有静态内部类，Loader提供在指定路径的资源包如jar包或者文件目录下查找指定名称的资源的能力即findResource和getResource两个方法，JarLoader表示jar包资源加载器，FileLoader表示文件目录的资源加载器，两者都是Loader的子类，如下图：
以FileLoader的实现为例说明，如下：
URL findResource(final String name, boolean check) {
//查找资源，如果存在则返回URL，否则返回null
Resource rsc = getResource(name, check);
if (rsc != null) {
return rsc.getURL();
}
return null;
}
Resource getResource(final String name, boolean check) {
final URL url;
try {
//getBaseURL()是该资源的起始地址，如最外层的文件夹名
URL normalizedBase = new URL(getBaseURL(), ".");
//构造目标资源的URL
url = new URL(getBaseURL(), ParseUtil.encodePath(name, false));
//获取目标资源的文件名，校验是否在基地址下，如果不是返回null
if (url.getFile().startsWith(normalizedBase.getFile()) == false) {
// requested resource had ../..'s in path
return null;
}
if (check)
URLClassPath.check(url);
final File file;
//资源名中包含..，这时获取的资源可能在基地址外
if (name.indexOf("..") != -1) {
//处理路径中包含的..将其转换成平台相关的绝对路径
file = (new File(dir, name.replace('/', File.separatorChar)))
.getCanonicalFile();
//判断目标资源是否在基地址下，dir即基地址
if ( !((file.getPath()).startsWith(dir.getPath())) ) {
/* outside of base dir */
return null;
}
} else {
file = new File(dir, name.replace('/', File.separatorChar));
}
//如果文件存在则返回对应的Resource
if (file.exists()) {
return new Resource() {
public String getName() { return name; };
public URL getURL() { return url; };
public URL getCodeSourceURL() { return getBaseURL(); };
public InputStream getInputStream() throws IOException
{ return new FileInputStream(file); };
public int getContentLength() throws IOException
{ return (int)file.length(); };
};
}
} catch (Exception e) {
return null;
}
return null;
}
类加载委托机制
Java提供的应用类加载器AppClassLoader只能加载位于classpath下的类，因此Java应用的启动命令通常会将应用自身的jar包，依赖的第三方jar包都追加到classpath后面，以ideal测试程序的启动命令为例，如下图：
当前测试程序编译结果的目录target/test-classes，应用依赖的第三方jar包如junit-4.12.jar都加入到classpath中了，除此之外属于ExtClassLoader加载的位于ext目录下的jar包，属于启动类加载器加载的jar包如rt.jar也都包含在里面了。那么AppClassLoader会重复加载本属于ExtClassLoader和启动类加载器加载的类么？答案是不会，类加载的委托机制保证了子类加载器不会重复加载父类加载器已经加载过的类，因为Java核心类都是由启动类加载器加载的，所以类加载的委托机制还保证了子类加载器无法加载一个非法的核心类来替换官方的核心类，源码参考ClassLoader的loadClass方法定义，其时序图如下：
在某些特殊场景下如Servlet容器需要同时加载多个应用，而多个应用之间可能存在同名的类，为了保证多个应用间的类的隔离，允许同一个类被加载多次，需要打破上述委托模型，即加载某个类时不再优先委托父类类加载器加载，而是现用自定义的类加载加载，如果无法加载了再用父类加载器加载，参考下篇文章的分析。
