虚拟机第二章-类加载子系统
类的加载过程
类加载过程略解：
-
开始：流程从开始节点启动。
-
检查HelloLoader类是否已加载：
-
这是一个判断节点，检查
HelloLoader类是否已经被加载。 -
如果已加载（标记为“Y”），则流程进入下一步。
-
如果未加载（标记为“N”），则流程进入类加载器的加载过程。
-
-
ClassLoader加载：
-
判断ClassLoader是否成功加载
HelloLoader类。 -
如果加载成功（标记为“Y”），则流程继续。
-
如果加载失败（标记为“N”），则抛出异常。
-
-
链接：
-
如果
HelloLoader类已加载，进行链接操作。链接是将类的二进制数据合并到JVM的运行时环境中。
-
-
初始化HelloLoader：
-
链接完成后，初始化
HelloLoader类。这通常涉及静态变量的初始化和静态块的执行。
-
-
调用HelloLoader.main()：
-
初始化完成后，调用
HelloLoader类的main方法，执行程序的主逻辑。
-
-
结束：
-
流程结束。
-
加载
1 通过一个类的全限定名获取定义此类的二进制字节流
加载.class文件的方式
-
从本地系统中直接加载
-
通过网络获取，典型场景：Web Applet
-
从zip压缩包中读取，成为日后jar、war格式的基础
-
运行时计算生成，使用最多的是：动态代理技术
-
由其他文件生成，典型场景：JSP应用
-
从专有数据库中提取.class文件，比较少见
-
从加密文件中获取，典型的防Class文件被反编译的保护措施
2 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
3 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
链接
验证(Verify)
-
目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全。
-
主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证。
在Java中，.class文件是Java编译器编译Java源代码后生成的字节码文件。.class文件是Java虚拟机（JVM）可以执行的二进制文件格式。每个.class文件的开头都有一个魔数（magic number），用于标识该文件是一个有效的Java类文件。
Java .class文件的魔数是 0xCAFEBABE。这个魔数是一个4字节的十六进制数，用于确保文件格式的正确性和完整性。当JVM加载一个.class文件时，它会首先检查文件的魔数是否为0xCAFEBABE。（16进制下是CAFEBABY) 如果魔数不匹配，JVM会抛出一个异常，表示该文件不是一个有效的Java类文件。
准备(Prepare)
-
为类变量分配内存并且设置该类变量的默认初始值，即零值。假如是int那么就赋值为0
-
这里不包含用final修饰的static，因为final在编译的时候就会分配了，准备阶段会显式初始化；
-
这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中。
解析(Resolve)
-
将常量池内的符号引用转换为直接引用的过程。
-
事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行。
-
符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的Class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
-
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等。
初始化
-
初始化阶段就是执行类构造器方法<clinit>()的过程。此方法不需定义，是javac编译器自动收集类中的所有类变量（也就是静态变量）的赋值动作和静态代码块中的语句合并而来。
-
构造器方法中指令按语句在源文件中出现的顺序执行。
-
<clinit>()不同于类的构造器。（关联：构造器是虚拟机视角下的<init>()）
-
若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕。
-
虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁。
类加载器
分类
JVM支持两种类型的类加载器，分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）。
从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。也就是说，扩展类加载器和系统类加载器都算是自定义类加载器
无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有3个。
如下图所示：
-
启动类加载器（Bootstrap Class Loader）：这是最顶层的类加载器，负责加载Java的核心库，比如说位于jre/lib/rt.jar中的类，它是用C++编写的，是JVM的一部分。启动类加载器无法被Java程序直接引用。
-
扩展类加载器（Extension Class Loader）：它是Java语言实现的，继承自ClassLoader类，负责加载Java扩展目录下的jar包和类库，比如说jre/lib/ext或由系统变量Java.ext.dirs指定的目录。扩展类加载器由启动类加载器加载，并且父加载器就是启动类加载器。
-
系统类加载器（System Class Loader）/ 应用程序类加载器（Application Class Loader）：这也是Java语言实现的，负责加载用户类路径（ClassPath）上的指定类库，是我们平时编写Java程序时默认使用的类加载器。系统类加载器的父加载器是扩展类加载器。它可以通过ClassLoader.getSystemClassLoader()方法获取到。
-
自定义类加载器（Custom Class Loader）：开发者可以根据需求定制类的加载方式，比如从网络加载class文件、数据库、甚至是加密的文件中加载类等。自定义类加载器可以用来扩展Java应用程序的灵活性和安全性，是Java动态性的一个重要体现。
注意注意！！！
这里的四者之间的关系是包含关系。不是上层下层，也不是子父类的继承关系。
当然还可以从语言角度分类，Bootstrap Class Loader（启动类加载器）是C++语言编写的，其他都是JAVA语言编写的
双亲委派机制
是什么（原理）
双亲委派模型要求类加载器在加载类时，先委托父加载器尝试加载，只有父加载器无法加载时，子加载器才会加载。
这个过程会一直向上递归，也就是说，从子加载器到父加载器，再到更上层的加载器，一直到最顶层的启动类加载器。
启动类加载器会尝试加载这个类。如果它能够加载这个类，就直接返回；如果它不能加载这个类，就会将加载任务返回给委托它的子加载器。
子加载器尝试加载这个类。如果子加载器也无法加载这个类，它就会继续向下传递这个加载任务，依此类推。
直到某个加载器能够加载这个类，或者所有加载器都无法加载这个类，最终抛出 ClassNotFoundException。
为什么要用双亲委派模型？
①避免类的重复加载：父加载器加载的类，子加载器无需重复加载。
②保证核心类库的安全性：如 java.lang.* 只能由 Bootstrap ClassLoader 加载，防止被篡改。
沙箱安全机制
自定义String类，但是在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件（rt.jar包中java\lang\String.class），报错信息说没有main方法，就是因为加载的是rt.jar包中的String类。这样可以保证对java核心源代码的保护，这就是沙箱安全机制。