jvm2-类加载子系统

类加载子系统，

 

1 类加载子系统负责从文件系统加载Class文件， class文件在文件开头要有特定的文件标识

2 类加载子系统只负责class文件的加载，至于他是否可以运行，这个要看执行引擎来决定

(理解，Class文件是一个程序猿，类加载系统是你的七大姑八大姨。我只负责把你介绍(加载)，给相亲对象面前，至于你能不能拿下，这就不是我的事情了，是相亲对象(执行引擎)人家同意不同意)

3 加载的类信息存放在了一块被成为方法区的空间，这个方法区在jdk8又称为元空间。

除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量

public class JVMTest {
    public static void main(String[] args) {
        System.out.println("helloworld");
    }
}

执行main()方法(静态方法)就需要加载main 所在类JVMTest

加载成功才进行链接，初始化等操作，完成后调用JVMTest类中的静态方法main

如果加载失败就抛出去异常。

这段代码，是我们一般学习java第一天就看到的，那么

它的加载过程是怎么样的呢?

 

主要其实就是三步

第一步加载阶段

 1通过这个全限定的类名获取这个类的二进制的字节流

 2 将这个字节流所代表的静态存储结构转换为方法区(jdk7之前叫永久代，jdk8开始叫元空间)的运行时时数据结构。

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

主要就是生成了一个大的Class对象文件

说白了，就干了一个事情，将java类变成了一个大的Class对象

链接阶段

链接分为了三个子阶段 验证->准备->解析

验证->(Verify)

1 目的在于确保Class文件的字节流中包含信息符合当前虚拟机的要求，要保证加载类的正确性，不会危害虚拟机自身的安全。

2 主要保证四种验证：方式文件格式验证，元数据验证，字节码验证，符号引用验证

我举一个字节码验证的例子

使用 二进制(BinaryViewer)软件查看字节码文件，其开头均为 CAFE BABE，(咖啡baby)如果出现不合法的字节码文件，那么将会验证不通过。

 

准备阶段：

1 为类变量(static变量) 分配内存并且设置类变量的默认初始值，如零值，如null 值。

2 这里不包括用final修饰的static变量，因为final在编译的时候就会分配好了默认值，准备阶段就会初始化。

 

 

因为是在编译阶段赋值的null 所以我们用jclasslib查看的时候，并没有查看到默认值，但是确实是有的。

解析(Resolve)(了解)

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

就一个helloworld 的类，默认引用了 自己的类，Object类，System类，打印流

 

2 解析操作往往会伴随着JVM在执行完初始化之后再执行

类的初始化阶段：

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

注意：这个执行类构造器方法不是类的构造器，是classinit的缩写。

这个方法是不需要我们程序猿自己定义，是javac编译后自动收集类中所有类变量(static)的赋值动作和静态代码块语句合并出来。也就是说，当我们代码中包含static变量的时候，就会有clinit方法

 

 

 

 

先赋值为number= 20 然后再次赋值为10

语法可以 ，编译通过， 因为在连接阶段 number =0，-> number =20 -> 10

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

类的构造器也就是平时我们的构造方法。

3 如果这个类中具有父类，JVM会保证子类的<clinit>执行之前，父类的<clinit>方法已经执行完毕了。

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

类的加载器的分类

1：JVM严格来讲支持两种类型的类加载器 。分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）、

2：第一印象，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器

3：无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有3个，如下所示

 

扩展类加载器：Extension ClassLoader

应用程序类加载器（也称为系统类加载器，AppClassLoader）

举个例子

 

注意：尝试获取引导类加载器，获取到的值为 null ，

这并不代表引导类加载器不存在,因为引导类加载器是由C/C++ 语言，我们获取不到

那么扩展类加载器和系统类加载器在哪呢？

在我的jdk里面jre的lib目录中的

D:\develop\Java\jdk1.8.0_271\jre\lib\rt.jar

 

扩展类加载器,和系统类加载器也是间接的继承了ClassLoader这个类

 

现在 有一个问题，java核心类库中的类是用什么类加载器加载的，而我们自定义的类加载器，又是用什么类加载器加载的呢？

 

虚拟机自带的类的加载器：

上面呢三个类的加载器的简单介绍：

1启动类加载器 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等开头的类

2扩展类加载器   ExtClassLoader

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

派生于ClassLoader类

父类加载器为启动类加载器

从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录（扩展目录）下加载类库。

注意：如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载

3系统类加载器

是java语言编写，由sun.misc.LaunchersAppClassLoader实现

派生于ClassLoader类(间接继承了ClassLoader)

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

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

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

通过classLoader.getSystemclassLoader()方法可以获取到该类加载器

查看一下没个类加载器 加载那些路径下的类

 

从上面的路径中随意选一个类,看看他的类加载器是什么:引导类(启动类)加载器

ClassLoader classLoader = Provider.class.getClassLoader();
System.out.println(classLoader);  //null    import java.security.Provider;

在获取一下扩展类加载器加载的路径

之后简单的介绍一下ClassLoader

ClassLoader类，它是一个抽象类，其后所有的类加载器都继承自ClassLoader（不包括启动类加载器）BootstrapClassLoader

获取ClassLoader途径

 

第四种方式用DriverManager 获取 获取不到，

 

//4 获取调用者的ClassLoader    获取不到

ClassLoader myLoder = Class.forName("com.microsofts.qlserver.jdbc.SQLServerDriver").getClassLoader();

System.out.println(myLoder);

ClassLoader callerCL = DriverManager.getCallerClassLoader();

百度上有这样的代码，而我遇见的问题

上面确实可以获取到classLoader 并且为null

但是 就算用 内部ClassName内部自己调用的类和方法 也没有这个APi的

Class<?> callerClass = Reflection.getCallerClass();//这个是不行的，这步开始报错
ClassLoader classLoader123 = callerClass.getClassLoader();
System.out.println(classLoader123);

会包一个内部误差错误， 就算加上了@CallerSensitive注解和同步方法也是不可以的，目前我认为DriverManager的这个api 在jdk8环境下是不可以获取ClassLoader对象的。

原因：

@CallerSensitive

 jdk内有些方法，jvm的开发者认为这些方法危险，不希望开发者调用，就把这种危险的方法用 @CallerSensitive修饰，并在“jvm”级别检查。

·否则 报异常 Exception in thread "main" java.lang.InternalError: CallerSensitive annotation expected at frame 1