JVM之类加载机制

Android类加载器

理解类加载

Eclipse使用第三方的插件其实就是动态加载Jar包里的Class字节码进行工作。这其实非常好理解,编写程序就是编写类,运行程序也就是运行类,Java代码经过编译器编译后变成Class字节码。程序运行在虚拟机上时,虚拟机把需要的Class加载进来才能创建实例对象并工作,而完成这一个加载工作的角色就是ClassLoader。

什么是类加载机制?

引用周志明的《 深入理解java虚拟机》的一句话:

虚拟机把描述类的数据文件(字节码)加载到内存,并对数据进行验证、准备、解析以及类初始化,最终形成可以被虚拟机直接使用的java类型(java.lang.Class对象),这就是java虚拟机的类加载机制。

类的生命周期

从类被加载进内存开始直到卸载出内存为止,类的生命周期包括装载、验证、准备、解析、初始化、使用和卸载7个过程,其中验证、准备、解析三个过程统称为链接。

JVM之类加载机制_第1张图片
Java类的生命周期

这7个过程会按顺序开始,但无需等到上一个过程结束下一个过程才能开始运行,实际上他们通常都是相互交叉混合着运行。

在Java中,类的加载和链接过程都是在程序运行期间完成的。另外,Java可以动态扩展的语言特性就是依赖运行期间动态加载、动态链接这个特点实现的。

接下来我们先从类的生命周期第一个阶段开始。

类的装载阶段

在此阶段,虚拟机需要完成以下三件事情:

  1. 通过“类全名”来获取定义此类的二进制字节流。
  2. 将字节流所代表的静态存储结构转换为方法区的运行时数据结构。
  3. 在内存中生成一个代表这个类的java.lang.Class对象,作为方法区中的这些类型数据的访问入口。

类的链接阶段

验证阶段

验证的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。

准备阶段

为类的静态变量分配内存并将其初始化为默认值,这些内存都将在方法区中进行分配。准备阶段不分配类中的实例变量的内存,实例变量将会在对象实例化时随着对象一起分配在Java堆中。

解析阶段

解析阶段是虚拟机常量池内的符号引用替换为直接引用的过程。

符号引用:
符号引用是一组符号来描述所引用的目标对象,符号可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可。符号引用在Class文件格式中它以CONSTANT_Class_info、CONSTANT_Fieldref_info等类型的常量出现。

直接引用:直接引用可以是直接指向目标对象的指针或是一个能间接定位到目标的句柄。

类的初始化

类的初始化是类加载过程的最后一步,到了初始化阶段,才真正开始执行类中定义的Java程序代码。

初始化阶段是执行类构造器方法的过程。类构造器方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static块)中的语句合并产生的,类变量随着类初始化的完成而完成,先于对象存在。至此,类加载的过程全部完毕,类变量和方法均可以被使用。

特别注意:此处涉及的是类加载的初始化,而不是实例对象的初始化,对应着的是clinit()类构造器和init()实例构造器。

类的主动引用和类的被动引用

类加载过程分为:类的主动引用和类的被动引用
类的主动引用(必须立即对类进行初始化)

  • new一个类的对象
  • 调用类的静态成员(除了final常量)和静态方法
  • 使用java.lang.reflect包的方法对类进行反射调用
  • 当初始化一个类,如果其父类没有被初始化,则先初始化他的父类
  • 当要执行某个程序时,一定先启动main方法所在的类

类的被动引用(不会发生类的初始化)

  • 通过子类引用父类的静态变量,不会导致子类初始化
  • 通过数组定义来引用类,不会触发类的初始化 SuperClasses[] temp = new SuperClasses[10];
  • 引用常量(final类型)不会触发此类的初始化(常量在编译阶段就存入调用类的常量池中了)

Java类加载器

BootstrapClassLoader(启动类加载器)

它是最原始的类加载器,并不是由java代码写的,是由原生代码编写的,负责加载java核心类库(例如rt.jar等)。

执行以下代码可以知道BootstrapClassLoader加载了那些文件:

URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();  
for (URL i : urls)  
     System.out.println(i);  

运行结果:

file:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/resources.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/rt.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/sunrsasign.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/jsse.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/jce.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/charsets.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/jfr.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/classes

ExtensionClassLoader(扩展类加载器)

它用来加载JRE的扩展目录(JAVA_HOME/jre/lib/ext或java.ext.dirs系统属性指定的)JAR的类包。

执行以下代码可以知道ExtensionClassLoader加载了那些文件:

ClassLoader extensionClassLoader = ClassLoader.getSystemClassLoader().getParent();  
System.out.println(extensionClassLoader);  
System.out.println("扩展类加载器路径: " + System.getProperty("java.ext.dirs")); 

运行结果:

sun.misc.Launcher$ExtClassLoader@7852e922
扩展类加载器路径: /Users/yeoggc/Library/Java/Extensions:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/ext:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java

Applicaiton ClassLoader(应用程序类加载器)

加载classpath路径中的类的字节码文件

请看如下例子:

public class 应用程序加载器 {

    public static void main(String[] args) {
        ClassLoader cl = ClassLoader.getSystemClassLoader();
        System.out.println(cl);
    }
    
    /**
     * 输出结果;
     * sun.misc.Launcher$AppClassLoader@2a139a55
     */
}

双亲委派模型

JVM之类加载机制_第2张图片
Java类加载器的体系结构

类加载逻辑代码:

protected Class loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
            // 首先检查class是否已经被加载
            Class c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) { //从父加载器加载
                        c = parent.loadClass(name, false);
                    } else {
                        //从bootstrap loader加载
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }
    
                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    //如果当前这个类加载器所有的父加载器以及顶层的Bootstrap   ClassLoader都不能加载待加载的类 时,那么则调用自己的findClass()方法来加载。
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }

双亲委派模型的工作过程:

  1. 会先查找当前ClassLoader是否加载过此类,有就返回;
  2. 如果没有,查询父ClassLoader是否已经加载过此类,如果已经加载过,就直接返回Parent加载的类;
  3. 如果整个类加载器体系上的ClassLoader都没有加载过,才由当前ClassLoader加载(调用findClass),整个过程类似循环链表一样。

注意

  1. 事实上加载器之间不是通过继承,而是通过组合的方式来实现整个加载过程,即每个加载器都持有上层加载器的引用,所以父加载器是一种笼统的说法

双亲委托机制的作用

  1. 共享功能,一些Framework层级的类一旦被顶层的ClassLoader加载过就缓存在内存里面,以后任何地方用到都不需要重新加载。
  2. 隔离功能,保证java/Android核心类库的纯净和安全,防止恶意加载。

你可能感兴趣的:(JVM之类加载机制)