类加载过程
在《深入理解Java虚拟机》第二版中，关于类的生命周期是如下定义的：
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)、卸载(UnLoading) 七个阶段，其中类加载过程包括 加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization) 这五个阶段,如下图
加载(Loading)
在加载阶段，虚拟机需要做3个事情
- 通过类的全限定名获取该类的二进制字节流(.class)
- 将二进制字节流所代表静态存储结构转化为方法区中的运行时数据结构
- 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。(相当于这个类生成实例对象的模版)
验证(Verification）
验证这一阶段是为了确保Class文件的字节流中包含的信息是否符合虚拟机的要求，并且不会危害虚拟机自身的安全，这一阶段是否严谨，直接决定了java虚拟机是否能承受恶意代码的攻击。在这一阶段，大致上会完成对以下4方面的校验动作:
- 文件格式验证
验证二进制字节流是否符合Class文件格式的规范，并且能被当前版本虚拟机处理。 - 元数据验证
对字节流中的所描述的信息进行语义分析，确保不存在不符合java语言规范的元数据信息. - 字节码验证
主要通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。与元数据验证不同的是，在元数据验证阶段是对元数据信息中的数据类型做校验，而字节码校验是对类的方法体进行校验分析，保证被校验类的方法在运行时不会作出危害虚拟机安全的事件。 - 符号引用验证
符号引用验证可以看作是对类自身以外的信息进行匹配行校验(如常量池中的各种符号引用)
准备(Preparation)
准备阶段会在方法区正式中为类变量分配内存并设置初始值，此处说的类变量是指有static修饰的静态变量，而并非指类实例变量，类实例变量会随类对象实例化时一起在堆中分配内存。
解析(Resolution)
解析阶段是虚拟机将常量池内的符号引用替换成直接引用的过程。
- 符号引用(Symbolic References)
以一组符号来描述所引用的目标。符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可,其引用的目标不一定已经加载到内存中。 - 直接引用(Direct REferences)
直接引用可以是直接指向目标的指针、相对偏移量或一个能间接定位到目标的句柄。如果有了直接引用，那直接饮用的目标必定已经被加载到内存中。
初始化(Initialization)
类初始化阶段是类加载过程的最后一步，在这一阶段，会根据程序员通过程序制定的主观计划去初始化类变量和其他资源，从另外一个角度来看，初始化就是执行类构造器方法的过程。
类加载器
Java类加载器（Java Classloader）是Java运行时环境（Java Runtime Environment）的一部分，负责动态加载Java类到Java虚拟机的内存空间中。JVM中有3个默认的类加载器，分别是启动类类加载器(BootStrap ClassLoader)、扩展类类加载器(Extension ClassLoader)、应用程序类加载器(Application ClassLoader)
启动类类加载器(BootStrap ClassLoader)
在HotSpot虚拟机中，启动类加载器是有C++语言实现的，是虚拟机自身的一部分。启动类加载器负责将放在%JAVA_HOME%\lib目录中，或者被-Xbootclasspath参数所指定的，并且是虚拟机能通过文件名识别(如rt.jar的类库加载到虚拟机内存中)。启动类加载器无法被java程序直接引用
扩展类类加载器(Extension ClassLoader)
这个类加载器有sun.misc.Launcher$ExtClassLoader实现，它负责加载%JAVA_HOME%\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
应用程序类加载器(Application ClassLoader)
由于这个类是java.lang.ClassLoader中getSystemClassLoader()的返回值，所以也叫系统类加载器，由sun.misc.Launcher$AppClassLoader实现。应用程序类加载器负责加载用户类路径(ClassPath)上所指定的类库。如果开发者没有自定义自己的类加载器，这个类加载器就是程序中的默认类加载器。
双亲委派模型(Parents Delegation Model)
在双亲委派模型中，要求除了启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器的父子关系一般不会以继承来实现，而是都使用组合关系来复用父类加载器的代码(例如子类加载器中通过成员变量方式调用父类加载器的代码)。
双亲委派模型的工作过程：如果一个类加载器收到了类加载的请求，它不会先尝试自己去加载这个类，而是把这个类向上委派给父类加载器，父类加载器也会重复向上委派这个步骤，直到顶层启动类加载器。因此，所有的类加载请求最终都会被委派到最顶层的启动类加载器中，这样从上往下尝试去加载这个类，只有当父类加载器无法完成这个类的加载请求(在此类加载器的搜索范围中没有找到需要加载的类)时，子加载器才会尝试自己去加载。
在双亲委派模型中，一个明显的好处就是，jdk自带的类库，会随着它的类加载器具备了优先加载的层级关系，这样可以保证jdk自带的类在程序的各种类加载环境中都是同一个类。例如，在不违反双亲委派模型的前提下，即使你自定义一个java.lang.Object类，在编译期也没有报错，但是这个类永远都不会加载到内存中，加载到内存的只会是jdk自带的java.lang.Object类。
本文链接：https://highphone.xyz/3d2798f3.html