jvm类加载器学习笔记

classloader 类加载器学习笔记

内存结构

类加载器子系统

类加载器子系统作用

类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。
ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。
加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）

类加载器

class file存在于本地硬盘上，可以理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。
class file加载到JVM中，被称为DNA元数据模板，放在方法区。
在.class文件 –> JVM –> 最终成为元数据模板，此过程就要一个运输工具（类装载器Class Loader），扮演一个快递员的角色。

类加载的过程

public class MyClassloader{
  public static void main(String [] args){
    System.out.print("hello world... ... ");
  }
}

以上代码的加载过程：

执行 main( ) 方法（静态方法）就需要先加载承载类 MyClassloader
加载成功，则进行链接、初始化等操作，完成后调用 MyClassloader 类中的静态方法 main
加载失败则抛出异常

即：加载 --> 链接 --> 初始化，链接又分为三步（验证 --> 准备 --> 解析）

加载(Loading)阶段

通过一个类的全限定名获取定义此类的二进制字节流
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

加载.class文件的方式

从本地系统中直接加载

通过网络获取，典型场景：Web Applet

从zip压缩包中读取，成为日后jar、war格式的基础

运行时计算生成，使用最多的是：动态代理技术

由其他文件生成，典型场景：JSP应用从专有数据库中提取.class文件，比较少见

从加密文件中获取，典型的防Class文件被反编译的保护措施

链接(Linking)阶段

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

验证

目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全
主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证。
使用 BinaryViewer 查看字节码文件，其开头均为 CAFE BABE ，如果出现不合法的字节码文件，那么将会验证不通过

准备

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

类型	默认值
int，short，byte ，long	0
double，float	0.0
char	\u0000
boolean	false

这里不包含用final修饰的static，因为final在编译的时候就会分配好了默认值，准备阶段会显式初始化
注意：这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中

// 在准备阶段会先把a赋值0，然后在将a赋值为1，因为int默认值就是0
public class HelloTest{

  private static int a = 1;

  public static void main(String [] args){
    System.out.print(a);
  } 
}

// b值的变化， 0 -->  20 -->  2 所以，最后输出的b应该是2.
public class HelloTest{

  private static int a = 1;
  static{
    a = 10;
    b = 20;// 准备阶段已经设置了初始值，所以这里不会报错 。
  }
  private static int b = 2;
  public static void main(String [] args){
    System.out.print(a);
    System.out.print(b);
  } 
}

解析

将常量池内的符号引用转换为直接引用的过程
事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行
符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等

初始化(Initialization)阶段

初始化阶段就是执行类构造器方法clinit()的过程
此方法不需定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。也就是说，当我们代码中包含static变量的时候，就会有clinit( )方法；如果当前类不存在static变量，那么它的字节码文件是不会存在clinit( )
clinit()方法中的指令按语句在源文件中出现的顺序执行
clinit()不同于类的构造器。（关联：构造器是虚拟机视角下的init()）
若该类具有父类，JVM会保证子类的clinit()执行前，父类的clinit()已经执行完毕
虚拟机必须保证一个类的clinit()方法在多线程下被同步加锁

当代码中存在static的变量的时候，字节码文件就会有clinit方法，如果不存在static变量，字节码文件没有clinit方法。clinit方法中的指令按语句在源文件中出现的顺序执行，即从上往下执行

// b值的变化， 0 -->  20 -->  2 所以，最后输出的b应该是2.
public class HelloTest{

  private static int a = 1;
  static{
    a = 10;
    b = 20;// 准备阶段已经设置了初始值，所以这里不会报错 。
    // 这里会报错 ，因为在这之前是没有声明b变量。
    System.out.print(b);
  }
  private static int b = 2;
  public static void main(String [] args){
    System.out.print(a);
    System.out.print(b);
  } 
}

构造器是虚拟机视角下的init(),任何一个类声明后，内部至少有一个类的构造器。若该类具有父类，jvm会保证在子类的clint()执行前父类的clinit()已经执行完毕

public class Test{

  static class Father{
    public static int a = 1;
    static {
      a = 2;
    }
  }

  static class Son extends Father{
    public static int b = a;
  }
   public static void main(String [] args){
    System.out.print(Son.b);// = 2
  } 
}

// 代码执行流程如下
1. 首先，执行 main( ) 方法需要加载 Test 类
2. 获取 Son.B 静态变量，需要加载 Son 类
3. Son 类的父类是 Father 类，所以需要先执行 Father 类的加载，再执行 Son 类的加载
所以，执行顺序是  Test --> Father --> Son

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

类加载器分类

JVM支持两种类型的类加载器。分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）
从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器
无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有3个，如下所示

规范定义：所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器
引导类加载器是由 C/C++ 语言构成的

启动类加载器(引导类加载器)

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

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

Java语言编写，由sun.misc.LaunchersAppClassLoader实现
派生于ClassLoader类
父类加载器为扩展类加载器
它负责加载环境变量 classpath 或系统属性java.class.path指定路径下的类库
该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载的
通过classLoader.getSystemclassLoader( )方法可以获取到该类加载器

加载器加载流程图

关于classloader

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

方法名称	描述
getParent( )	返回该类加载器的超类加载器
loadClass(String name)	加载名称为name的类，返回结果为java.lang.Class类的实例
findClass(String name)	查找名称为name的类，返回结果为java.lang.Class类的实例
findLoadedClass(String name)	查找名称为name的已经被加载过的类，返回结果为java.lang.Class类的实例
defineClass(String name,byte[ ] b,int len)	把字节数组b中的内容转换为一个Java类，返回结果为java.lang.Class类的实例
resolveClass(Class<?> c)	连接指定的一个Java类

双亲委派机制

双亲委派机制原理

Java虚拟机对 class 文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的 class 文件加载到内存中生成 class 对象。而且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式
如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行；
如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；
如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。
父类加载器一层一层往下分配任务，如果子类加载器能加载，则加载此类，如果将加载任务分配至系统类加载器也无法加载此类，则抛出异常

可以参考加载器加载流程图

优势

避免类的重复加载
保护程序安全，防止核心api被随意修改

沙箱安全机制

在加载自定义类的时候，如果类加载器没有加载过该类，会依次向上直到引导类加载器，如果引导类加载器加载过该类，会优先使用引导类加载器(Bootstrap ClassLoader)加载，而引导类加载器只加载包名为java、javax、sun等开头的类保证了对java核心源代码的保护，这就是沙箱安全机制。