JVM-类加载子系统（Class Loader SubSystem）

类加载子系统负责从文件系统或者网络中加载Class文件，Class文件开头有特定的文件标识。加载的类信息存放于一块称为方法区的内存空间。

加载（Loading）

1、通过一个类的全限定名获取定义此类的二进制字节流

2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构

3、在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

类加载器分类

引导类加载器（Bootstrap ClassLoader）和自定义加载器（User-Defined ClassLoader）

概念上，将所有派生于抽象类ClassLoader的类加载器都划分为自定义加载器

获取类加载器代码示例

在程序中我们常见的3给类加载器：启动类加载器（引导类加载器）（Bootstrap ClassLoader）、扩展类加载器（Extension ClassLoader）、应用程序加载器（系统类加载器）（Application ClassLoader）

启动类加载器（引导类加载器）（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放在此目录下，也会自动由扩展类加载器加载

应用程序加载器（系统类加载器）（Application ClassLoader）

Java语言编写，由sun.misc.Launcher$AppClassLoader实现

派生于ClassLoader类

父类加载器为扩展类加载器

负责加载环境变量classpath或系统属性java.class.path指定路径下的类库

该类加载器是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载

通过ClassLoader#getSystemClassLoader（）方法可以后去到改类加载器

用户自定义类加载器

在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。

为什么要自定义类加载器?

隔离加载类（例如使中间件的Jar包与应用程序Jar包不冲突）；

修改类加载的方式（启动类加载器必须使用，其他可以根据需要自定义加载）；

扩展加载源；

防止源码泄漏（对字节码进行加密，自定义类加载器实现解密）

用户自定义类加载器实现步骤:

1、开发人员可以通过继承抽象类java.lang.classLoader类的方式，实现 自己的类加载器，以满足一些特殊的需求

2、在JDK1.2之前，在自定义类加载器时，总会去继承classLoader类并重写loadclass ()方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadclass ()方法，而是建议把自定义的类加载逻辑写在findclass ()方法中

3、在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findclass ()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

关于ClassLoader

是一个抽象类，除了启动类加载器，其他类加载器都继承自他

获取途径

双亲委派机制

Java虚拟机对Class文件采用的是按需加载，而且加载class文件时，Java虚拟机使用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式

工作原理：

1、如果一个类加载器收到了类加载请求，它并不会自己先去加载。而是把这个请求委托给父类的加载器去执行

2、如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将达到顶层的启动类加载器

3、如果父类的加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式

优势

避免类的重复加载

保护程序安全，防止核心API被篡改

沙箱安全机制

什么是沙箱？

沙箱是一个限制程序运行的环境（沙箱主要限制系统资源的访问，如cpu,内存等等。不同级别的沙箱对这些资源的访问限制也不一样）

什么是沙箱机制？

就是将java代码限定在虚拟机（jvm) 特定的运行范围中，并且严格限制代码对本地系统资源的访问，通过这样的措施来保证对代码的有效隔离，防止对系统造成破坏。

作用

保证对Java核心源代码的保护

jdk1.6安全模型（当前最新安全机制）

引入了域的概念，虚拟机会把所有代码加载到不同的系统域和应用域，系统域部分专门负责与关键资源进行交互，各个应用域部分则通过系统域代理来对各种需要的资源进行访问。虚拟机中不同的受保护域对应不一样的权限。存在于不同域的类文件就具有了当前域的全部权限

沙箱的基本组件

字节码校验器：确保Java类文件遵循java语言规范。这样可以帮助Java实现内存保护。但并不是所有类文件都会经过字节码校验，比如核心类。

类装载器：在三个方面对沙箱起作用

1.防止恶意代码去干涉善意代码（双亲委派机制）

2.守护了被信任的类库边界

3.它将代码归入保护域，确定了代码可以执行哪些操作

补充

1、在JVM中表示两个class对象，是否为同一个类存在两个必要条件

·类的完整类名必须一致，包括包名

·加载这个类的ClassLoader必须相同

2、JVM必须知道一个类型是由启动类加载器加载的，还是由用户类加载器加载的。如果是用户类加载器加载的，JVM会将这个类加载器的一个引用作为类型信息的一部分，保存到方法区中。当解析一个类型到另一个类型的引用的时候，JVM需要保证着两个类型的类加载器是相同的。

3、Java程序对类的使用方式分为:主动使用和被动使用。

主动使用，又分为七种情况:

• 创建类的实例

• 访问某个类或接口的静态变量，或者对该静态变量赋值

• 调用类的静态方法

• 反射（比如:Class.forName ( "com.atguigu. Test") )

• 初始化一个类的子类

• Java虚拟机启动时被标明为启动类的类

• JDK 7 开始提供的动态语言支持: java . lang.invoke.MethodHandle实例的解析结果 REF getStatic、REF putstatic、REF_invokestatic句柄对应的类没有初始化，则初始化

除了以上七种情况，其他使用Java类的方式都被看作是对类的被动使用， 都不会导致类的初始化。

连接（Linking）

验证（Verify）

目的在于确保class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全。 主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证。

文件格式验证

CA FE BA BE(魔数，Java虚拟机识别)

主次版本号

常量池的常量中是否有不被支持的常量类型

指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量

元数据验证

对字节码描述的信息进行语义分析，保证描述符合Java规范

类是否有父类，除了Object之外，所有的类都应该有父类

类的父类是否继承了不允许被继承的类（被final修饰的类）

如果这个类不是 抽象类，是否实现了其父类或接口中要求实现的所有方法。

类的字段，方法是否与父类的产生矛盾。例如方法参数都一样，返回值不同

字节码验证

通过数据流分析和控制流分析，确定程序语义是合法的，符合逻辑的。

对类的方法体，进行校验分析，保证在运行时不会做出危害虚拟机的行为

保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，不会出现类似于在操作数栈放了一个int类型的数据，使用时却按照long类型加载到本地变量表中的情况。

保障任何跳转指令都不会跳转到方法体之外的字节码指令上。

符号引用验证

通过字符串描述的全限定名是否能找到对应的类

符号引用中的类、字段、方法的可访问性是否可被当前类访问

准备（Prepare）

为类变量分配内存并且设置该类变量的默认初始值，即零值。

这里不包含用final修饰的static，因为final在编译的时候就会分配了，准备阶段会显式初始化

这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中。

解析（Resolve）

将常量池内的符号引用转换为直接引用的过程。

事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行。

符号引用就是一组符号来描述所引用的目标。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class info、CONSTANT_Fieldref info、CONSTANT_Methodref_info等。

初始化（Initialization）

初始化阶段就是执行类构造器方法<clinit>()的过程。

此方法不需定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。

构造器方法中指令按语句在源文件中出现的顺序执行。

<clinit>()不同于类的构造器。（关联：构造器是虚拟机视角下的<init> () ）

若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit> ()已经执行完毕。

虚拟机必须保证一个类的<clinit> ()方法在多线程下被同步加锁。

补充说明

·加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的。

·解析阶段不一定，在某些情况下可以在初始化阶段之后再开始，为了支持Java语言的运行时绑定特性（也称为动态绑定或晚期绑定）

·Java虚拟机规范严格规定了，有且只有六种情况，必须立即对类进行初始化

1、遇到new,getstatic，putstatic或invokestatic这四条字节码指令时。

·使用new关键字实例化对象

·读取或设置一个类型的静态字段（final修饰已在编译期将结果放入常量池的静态字段除外）

·调用一个类型的静态方法的时候

2、对类型进行反射调用，如果类型没有经过初始化，则需要触发初始化

3、初始化类的时候，发现父类没有初始化，则先触发父类初始化

4、虚拟机启动时，用户需要指定一个要执行的主类（包含main方法的那个类），虚拟机会初始化这个主类

5、只用JDK7中新加入的动态语言支持，如果一个java.lang.invoke.MethodHandler实例最后的解析结果为REF_getStatic,REF_putStatic,REF_invokeStatic，REF_newInvokeSpecial四种类型的方法句柄，并且这个方法对应的类没有进行初始化，则先触发其初始化。

6、当一个接口中定了JDK8新加入的默认方法时，如果这个接口的实现类发生了初始化，要先将接口进行初始化

除了以上几种情况，其他使用类的方式被看做是对类的被动使用，都不会导致类的初始化