类从 被加载到虚拟机内存中 开始，到 卸载出内存 为止，它的生命周期包括：加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)、卸载(Unloading)7个阶段，其中 验证、准备、解析3个部分统称为 连接(Linking)
类加载过程顺序按部就班的开始(注意是按部就班的开始，而不是按部就班的"进行"或"完成")：加载->验证->准备->初始化->卸载
解析 可以在 初始化 阶段之后在开始
类加载过程
1：加载
“加载“”是“类加载“过程的一个阶段，该阶段虚拟机要完成3件事
1）通过一个类的全限定名来获取定义此类的二进制字节流。
2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3）在内存中生成一个代表这个类的java.long.Class对象，作为方法区这个类的各种数据的访问入口。
数组本身不通过类加载器创建，它是由Java虚拟机直接创建的
一个数组类创建过程遵循以下规则
1）如果数组的组件类型是引用类型，那就递归采用加载过程去加载这个组件类型，数组将在加载该组件类型的类加载器的类名称空间被标识
2）如果数组的组件类型不是引用类型(如int[])，java虚拟机将会把数组标记为与引导类加载器关联。
3）数组类的可见性与它的组件类型的可见性一致，如果数组类型不是引用类型，那数组类的可见性默认为public。
加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中。
加载阶段与连接阶段的部分内容是交叉进行的，两个阶段的开始时间仍保持着固定的先后顺序。
2：验证
目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全；
如果验证到输入的字节流不符合Class文件格式约束，虚拟机应抛出一个java.lang.VerifyError异常或其子类异常；
验证分为4个阶段动作：文件格式验证，元数据验证，字节码验证，符号引用验证；
2.1。文件格式校验：验证字节流是否符合Class文件格式的规范，并能被当前虚拟机处理，验证通过后，字节流才会进入内存的方法区中进行存储，所以后面三个阶段不会直接操作字节流
2.2。元数据验证：对字节码描述的信息进行语义分析，以保证其描述的信息符合java语言规范要求，主要目的是对元数据信息进行语义校验，保证不存在不符合java语言规范的元数据信息
2.3。字节码验证：目的是通过数据流和控制流分析确定语义是合法的、符合逻辑的，该阶段将对类的方法进行校验分析，保证被校验方法在运行时不会做出危害虚拟机安全的事件，该阶段最为复杂
2.4。符号引用验证：最后一阶段校验发生在虚拟机将符号引用转化为直接引用的时候，该转化将在 连接 的第三阶段 (解析) 发生，该验证可以看作是对类自身以外的信息进行匹配性校验，目的是确保解析动作能正常执行，如无法通过将抛出一个java.lang.IncompatibleClassChangeError异常的子类(如java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等)
3：准备
是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。
通常情况：这里说的初始值"通常情况"下是数据类型的零值，假设public static int value = 123，value在准备阶段过后的初始值为0而不是123，因为尚未开始执行任何java方法，把value赋值为123的动作在初始化阶段才会执行。
特殊情况：如果类字段属性表中存在Constant Value属性，那在准备阶段变量value就会被初始化为Constant Value属性所指定的值，public static final int value = 123;
编译时javac将会为value生成Constant Value属性
4：解析
是虚拟机将常量池内的符号引用替换为直接引用的过程。
符号引用：用一组符号来描述引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可
符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中
直接引用：可以是直接指向目标的指针、相对偏移量 或是一个能间接定位到目标的句柄。
直接引用是和虚拟机实现的内存布局相关的，有了直接引用，那引用的目标必定已经在内存中存在
解析动作主要针对 类、接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用
5：初始化
该阶段是类加载过程的最后一步，到了该阶段才真正开始执行类中定义的java程序代码，该阶段是执行类构造器<clinit>()方法的过程，多个线程同时去初始化一个类，那么只会有一个线程去执行这个类<clinit>()方法，其他线程都需要阻塞等待，知道活动线程执行<clinit>()方法完毕
虚拟机规范规定以下5种必须立即对类进行"初始化"的情况：
1：使用 new 关键字实例化对象的时候、读取或设置一个类的静态字段(被final修饰、已在编译期把结果放入常量池的静态字段除外)的时候、以及调用一个类的静态方法时。
2：使用java.lang.reflect包的方法对类进行反射调用时，如类没有进行过初始化，则需要先触发其初始化。
3：当初始化一个类时，如果其父类还没有进行初始化，则要先触发其父类的初始化。
4：虚拟机启动时，需要指定一个要执行的主类(包含main()方法的类)，虚拟机会先初始化这个主类。
5：如果java.lang.invoke.MethodHandle(动态语言)实例的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则先触发初始化。
这5种场景中的行为称为 对一个类进行主动引用，除此之外，所有引用类的方式都不会触发初始化，称为 被动引用
一个接口在初始化时，并不要求其父接口全部都完成初始化，只有在真正使用到父接口时(如引用接口中定义的常量)才会初始化
类加载器
类加载阶段中“通过一个类的权限定名来获取描述此类的二进制字节流”这个动作放到java虚拟机外部实现，实现这个动作的代码模块称为"类加载器"，它只实现类的加载动作
每一个类加载器都有一个独立的类名称空间，比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，只要他们的类加载器不同，即使源于同一个class文件，两个类也不相等。
双亲委派模型
java虚拟机角度来讲，只存在两种类加载器：一种是启动类加载器(Bootsrtap ClassLoader)，使用C++实现，是虚拟机的一部分；另一种是所有其他的类加载器，由java实现，全都继承自抽象类java.lang.ClassLoader
从java开发人员角度看，分为3种系统提供的类加载器
1：启动类加载器(Bootstrap ClassLoader)：负责加载<JAVA_HOME>\lib目录中或被-Xbootclasspath参数指定路径中的，并且虚拟机识别的(仅按照文件名识别，如rt.jar)类库加载到虚拟机内存中，该加载器无法被java程序直接引用，如需要把加载器委派给引导类加载器，直接使用null代替即可
2：扩展类加载器(Extension ClassLoader)：由sun.misc.Launcher$ExtClassLoader实现，负责加载<JAVA_HOME>\lib\ext目录中的，或被java.ext.dirs系统变量指定的路径中的所有类库，开发者可以直接使用该加载器
3：应用程序类加载器(Application ClassLoader)：一般称为系统类加载器，它负责加载用户路径(ClassPath)上所指定的类库，开发者可直接使用这个类加载器，如果程序中没有自定义过自己的类加载器，一般这个就是程序中默认的类加载器
这些类加载器关系如图
双亲委派模型工作过程：如果一个类加载器收到了类加载请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的类加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求(它的搜索范围中没有找到所需的类)时，子加载器才会尝试自己去加载。
