类加载子系统
文章目录
1. 内存结构概述
2. 类加载器与类的加载过程
在图3中类加载子系统，有：
- 类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。
- ClassLoader只负责class文件的加载，至于它是否可以运行，则由ExecutionEngine决定。
- 加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量(这部分常量信息是Class文件中常量池部分的内存映射)。
2.1 类加载器ClassLoader角色
- class file 存在于本地硬盘上，可以理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到JVM当中来，根据这个文件实例化出n个一模一样的实例(成员变量和方法相同，但成员变量值可能不同)。
- class file加载到JVM中，被称为DNA元数据模板，放在方法区。
- 在.class文件-> JVM ->最终成为元数据模板，此过程就要一个运输工具(类加载器Class Loader)，扮演一个快递员的角色。
2.2 类的加载过程
图6中各流程的分析如下：
2.2.1 加载
-
通过一个类的全限定名获取定义此类的二进制字节流。
-
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
-
在内存中生成一个代表这个类的java.lang.Class对象！！！！，作为方法区这个类的各种数据的访问入口。
补充：加载.class文件的方式
- 从本地系统中直接加载
- 通过网络获取，典型场景：Web Applet
- 从zip压缩包中读取，成为日后jar、war格式的基础
- 运行时计算生成，使用最多的是：动态代理技术
- 有其他文件生成，典型场景：JSP应用
- 从专有数据库中提取.class文件，比较少见
- 从加密文件中读取，典型的防Class文件被反编译的保护措施
2.2.2 链接
验证(Verify)：
- 目的在于确保Class文件的字节流中包含的信息 符合当前虚拟机的要求（比如java字节码文件起始内容为CA FE BA EE），保证被加载类的正确性，不会危害虚拟机自身安全。
- 主要包括四种验证：文件格式验证、元数据验证、字节码验证、符号引用验证。
准备(Prepare):
-
为类变量分配内存并且设置该类变量的默认初始值，即零值(比如int是0，float是0.0，引用类型是null)。
-
这里不包含用final修饰的static，因为final在编译的时候就会分配了，准备阶段会显式初始化；
-
这里不会为实例变量分配初始化，类变量会分配到方法区中，而实例变量是会随着对象一起分配到java堆中。
public int n1 = 10; public static int n2 = 20; public static final int n3 = 30;在准备阶段，上述代码有：n1 是实例变量，不是静态属性，因此在准备阶段，是不会分配内存。n2是静态变量，分配内存，默认初始化0，而不是20。n3是static final变量，和单纯的静态变量不一样，一旦赋值就不变，n3直接等于30。
解析(Resolve):
- 将常量池内的符号引用转换为直接引用的过程。
- 事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行
- 符号引用就是一组符号来描述所引用的目标。符号应用的字面量形式明确定义在《java虚拟机规范》的Class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
- 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等。
2.2.3 初始化
- 初始化阶段就是执行类构造器方法()的过程
- 此方法不需定义，是Javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。
- 构造器方法中指令按语句在源文件中出现的顺序执行
- ()不同于类的构造器。(关联：构造器是虚拟机视角下的())
- 若该类具有父类，JVM会保证子类的()执行前，父类的()已经执行完毕
- 虚拟机必须保证一个类的()方法在多线程下被同步加锁。如果多个线程同时区初始化一个类，那么只有一个线程去执行这个类的()方法，其他线程都需要阻塞等待。
static{ num = 300;
//sout(num); //非法前向引用 因为后面num还要被赋值
}
static int num = 100;
上述代码，在链接阶段，static类型的num就已经被分配内存，且初始化默认值为0。假设上述代码是定义在类名为B的类中的，那么在执行sout(B.num)时(调用类中静态成员，类会被加载)，会触发类加载，也就是num现在链接阶段赋值为0，最后在初始化阶段，顺序执行()方法中收集的赋值动作和静态代码块中语句。也就是num从0—>300，再从300—>100;最后输出300。（注：若B中存在实例变量(非静态变量num2)，那么不能直接B.num2访问num2，因为num2没在准备阶段分配内存，访问不到，这种变量只有在实例化对象后才会在相应的位置分配内存。用对象名+num2访问(如果权限够的话)）。
public class ClinitTest1 {
public static void main(String[] args) {
Runnable r = () ->{
System.out.println(Thread.currentThread().getName()+"开始");
DeadThread dead = new DeadThread();
System.out.println(Thread.currentThread().getName()+"结束");
};
Thread t1 = new Thread(r, "线程1");
Thread t2 = new Thread(r, "线程2");
t1.start();
t2.start();
}
}
class DeadThread{
static {
if(true){
System.out.println(Thread.currentThread().getName()+"初始化当前类");
while (true){
}
}
}
}
上例中，两个线程同时执行，都去进行DeadThread类加载，由于同时只能有一个线程执行()方法，因此输出
线程1抢到了类加载的机会，线程二在等待线程1将类加载完毕。由于类只能加载一次，当类加载一次后，线程二则不会再执行相同操作，直接跳过类加载部分，如图8所示，当把静态代码块中while循环去掉后，线程二不再执行()方法。
2.2.4 补充
- ==创建子类对象时，顺序如下：==执行父类的()——>执行子类的()——>执行父类的非静态代码块——>执行父类构造函数——>执行子类的非静态代码块——>执行子类的构造函数
public class ClinitTest1 {
public ClinitTest1() {
a = 10;
}
public int a = 1;
public static void main(String[] args) {
System.out.println(new ClinitTest1().a);
}
}
在上述代码中，对于实例变量a，不管public int a = 1;是放在构造器前面还是后面，只要构造器中修改了a的值，那么a的值最终就等于构造器中指定的值。除非构造器中没有指定a的值，a最终的值才会等于public int a = 1中指定的值。也是创建了对象后，先给a分配了内存，并给了值1，然后再执行构造器方法，让a=10。
- 也就是调用顺序为为：①在类加载时，调用静态代码块和静态属性初始化的优先级一样，如果有多个代码块和多个静态变量初始化，则按定义的顺序调用。②在实例化对象时，调用普通代码块和普通属性的初始化，优先级一样，如果有多个，则按定义顺序调用，最后再调用构造器。构造器可以再次修改普通属性或者静态属性的值。
- 普通的代码块，在创建对象实例时，会被隐式调用，被创建一次就调用一次。如果只是使用类的静态成员，普通代码块并不会执行。说白了，静态与类加载有关，普通与对象创建有关。
3. 类加载器分类
-
JVM支持两种类型的类加载器，分别为引导类加载器(Bootstrap ClassLoader)和自定义类加载器(User-Defined ClassLoader)。如图9所示。图9中的四者之间的关系是包含关系，不是上层下层，也不是子父类的继承关系。
-
从概念上讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。如图9中Bootstrap ClassLoader一类，其它为自定义类（Extension 和 System Class Loader间接继承了ClassLoader）。
-
无论类加载器的类型如何划分，在程序中最常见的类加载器始终只有3个。
public class ClassLoaderTest { //获取各种类加载器
public static void main(String[] args) {
//获取系统类加载器
ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
System.out.println(systemClassLoader); //sun.misc.Launcher$AppClassLoader@18b4aac2
//获取其上层:扩展类加载器
ClassLoader exClassLoader = systemClassLoader.getParent();
System.out.println(exClassLoader); //sun.misc.Launcher$ExtClassLoader@1540e19d
//获取其上层:获取不到引导类加载器
ClassLoader bootstrapClassLoader = exClassLoader.getParent();
System.out.println(bootstrapClassLoader); //null
//对于用户自定义类来说:默认使用系统类加载器进行加载
//获取自定义的类ClassLoaderTest是由那个类加载器所加载的
ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
System.out.println(classLoader); //sun.misc.Launcher$AppClassLoader@18b4aac2
//String类使用引导类加载器进行加载的 ---> Java的核心类库都是使用引导类加载器进行加载的
ClassLoader classLoader1 = String.class.getClassLoader();
System.out.println(classLoader1); //null
}
}
3.1 虚拟机自带的加载器
启动类加载器(引导类加载器，Bootstrap ClassLoader)
-
这个类加载使用C/C++语言实现，嵌套在JVM内部
-
它用来加载java的核心库(JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容)，用于提供JVM自身需要的类。
-
并不继承自java.lang.ClassLoader，没有父加载器（用C实现，不继承java类）
-
加载扩展类和应用程序类加载器，并指定为他们的父类加载器
-
出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类
System.out.println("****************启动类加载器****************"); //获取BootstrapClassLoader能够加载的api的路径 URL[] urLs = Launcher.getBootstrapClassPath().getURLs(); for (URL elelment : urLs){ System.out.println(elelment.toExternalForm()); }结果为：
图10 引导类加载器所能加载库的路径
扩展类加载器(Extension ClassLoader)
- Java语言编写，由sun.misc.Launcher$ExtClassLoader实现
- 派生于ClassLoader类
- 父类加载器为启动类加载器
- 从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录(扩展目录)下加载类库。如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载。
应用程序类加载器(系统类加载器，AppClassLoader)
- java语言编写，由sun.misc.Launcher$AppClassLoader实现
- 派生于ClassLoader类
- 父类加载器为扩展类加载器
- 它负责加载环境变量classpath或系统属性 java.class.path指定路径下的类库
- 该类加载时程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载
- 通过ClassLoader.getSystemClassLoader()方法可以获取到该类加载器
3.2 用户自定义类加载器
- 在Java的日常应用程序开发中，类的加载几乎是由上述3中类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。
- 为什么要自定义类加载器
- 隔离加载类
- 修改类加载的方式
- 扩展加载源
- 防止源码泄露
4. 关于ClassLoader
ClassLoader类，是一个抽象类，其后所有的类加载器都继承自ClassLoader(不包括启动类加载器)
获取ClassLoader的途径
- 方式一：获取当前类的ClassLoader clazz.getClassLoader()
- 方式二：获取当前线程上下文的ClassLoader Thread.currentThread().getContextClassLoader()
- 方式三：获取系统的ClassLoader ClassLoader.getSystemClassLoader()
- 方式四：获取调用者的ClassLoader DriverManager.getCallerClassLoader()
5. 双亲委派机制
Java虚拟机对class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式,即把请求交由父类处理,它是一种任务委派模式。
先看一个例子
package java1;
public class StringTest {
public static void main(String[] args) {
String str = new java.lang.String();
System.out.println("hello,atguigu.com");
}
}
package java.lang;
public class String {
static {
System.out.println("我是用户自己定义的String");
}
}
最后的结果输出"hello,atguigu.com"。没有输出"我是用户自己定义的String"，说明main函数中调用的是java核心API中的String类。因为如果使用的是自己定义的String，那么由于类加载了，静态代码块肯定会执行，也就是肯定会输出"我是用户自己定义的String"。
上述情况其实就蕴含了双亲委派机制。如果执行的是自己定义的String类型，那么可能会出问题。因为如果别人接收了自己写的这个项目并加入到他自己的项目中，由于他自己项目中肯定也会用java.lang.String类，那么原本调用的是核心库中的String,现在却变成了自定义的String,整个项目就崩溃了。
5.1 工作原理
- 如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行;
- 如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器;
- 如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。
结合工作原理再回看上述代码，java.lang.String一开始是自己定义的类，那么应该是使用系统类加载器AppClassLoader进行加载。但是由于需要向上委托，所以会先直接委托到引导类加载器Booststrap Classloader。而由3.1中知，启动类加载器会加载java包下的类，java.lang下也正好有一个自带的核心类String，因此最后会由启动类加载器加载系统自带的String类。父类加载完就不会再向下再加载了。
5.2 双亲委派机制举例
public class StringTest {
public static void main(String[] args) {
// String str = new java.lang.String();
// System.out.println("hello,atguigu.com");
StringTest test = new StringTest();
System.out.println(test.getClass().getClassLoader());
}
}
再看这个例子，最后输出“sun.misc.Launcher$AppClassLoader@18b4aac2”。首先由系统类加载器先判断用户自定义的类，然后不断向上委托，引导类加载器发现此类所在的包不再加载范围内，然后向下回溯，拓展类加载器也不再服务范围内，最后系统类加载器发现自己可以加载永和自定义的类，所以由系统类加载了用户自定义的类。
package java.lang;
public class String {
static {
System.out.println("我是用户自己定义的String");
}
public static void main(String[] args) {
System.out.println("hello,String");
}
}
再看一个例子，最后报错了
原因也很简单。也是引导类加载器发现这个包自己可以加载，并且里面的类自己也有，所以加载了核心库里的String，那由于核心库里的String类没有main方法，所以报错了。
package java.lang;
public class String21 {
static {
System.out.println("我是用户自己定义的String");
}
public static void main(String[] args) {
System.out.println("hhh");
}
}
再看上面例子，如果包仍然是java.lang 但是类名换成核心库中没有的类名 运行main方法时会报错，如下图
package java1;
public class StringTest {
public static void main(String[] args) {
String21 str = new String21();
System.out.println("hello,atguigu.com");
StringTest test = new StringTest();
System.out.println(test.getClass().getClassLoader());
}
}
别的类调用java.lang.String21方法也会报错
**也就是说，自己定义的包名不能和启动类加载器、扩展类加载器能引用的包名相同。包名相同的话，如果类名不同运行或者调用就会出错，类名相同就算调用也还是会调用核心库中的类，不会调用自己定义的类。**正好对应了5.4中优势的第二个优势，安全！
5.3 双亲委派机制举例2
现在需要用到SPI接口，SPI接口属于核心API，由双亲委派机制，最终由引导类加载器加载。SPI核心类中存在接口，而接口需要一些具体的实现类，这些实现类就属于第三方的java包了，不属于核心类的java包了。因此就会反向委托，交给系统类加载器加载。
5.4 双亲委派机制优势
- 避免类的重复加载
- 保护程序安全，防止核心API被随意篡改
- 自定义类：java.lang.String
- 自定义类：java.lang.ShkStart
5.5 沙箱安全机制
自定义string类，但是在加载自定义string类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件(rt.jar包中java\lang\string.class)，报错信息说没有main方法就是因为加载的是rt.jar包中的string类。这样可以保证对java核心源代码的保护，这就是沙箱安全机制。
6. 其它
6.1 两个类相同必要条件
在JVM中表示两个class对象是否为同一个类存在两个必要条件
-
类的完整类名必须一致，包括包名。
-
加载这个类的ClassLoader(指ClassLoader实例对象)必须相同
换句话说，在JVM中，即使这两个类对象(class对象)来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的ClassLoader实例对象不同，那么这两个类对象也是不相同的。
比如自定义的java.lang.String和核心库中的String虽然包名和类名相同，但是类加载器不同，前者好像可以通过自定义加载器加载，后者通过引导类加载器加载。加载器不同，所以两个类不同。
6.2 对类加载器的引用
JVM必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的。
6.3 Java程序对类的使用方式
Java程序对类的使用方式为：主动使用和被动使用
- 主动使用，分为七种情况：
- 创建类的实例
- 访问某个类或接口的静态变量，或者对该静态变量赋值
- 调用类的静态方法
- 反射(比如：Class.forName(“com.atguigu.Test”))
- 初始化一个类的子类
- Java虚拟机启动时被标明为启动类的类
- JDK 7开始提供的动态语言支持:java.lang.invoke.MethodHandle实例的解析结果 REFgetstatic、REF_putstatic、REF_invokestatic句柄对应的类没有初始化，则初始化
- 除以上七种情况，其他使Java类的方式都被看做是对类的被动使用，都不会导致类加载过程中的初始化阶段(即2.2.3)。
注意：有网友说“如果子类使用父类的静态属性，会导致父类被初始化，但子类只会被加载，而不会被初始化”。
3034
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
