类加载机制指的是将这些.class文件中的二进制数据读入到内存中并对数据进行校验#xff0c;解析和初始化。

最终#xff0c;每一个类都会在方…类加载机制

一、Java类加载机制

java中每一个类或者接口在编译后都会生成一个.class文件。

类加载机制指的是将这些.class文件中的二进制数据读入到内存中并对数据进行校验解析和初始化。

最终每一个类都会在方法去保存一份元数据在堆中创建一个与之对应的Class对象。

类的生命周期经历7个阶段分别是加载验证准备解析初始化使用卸载。

类加载时机

类加载时机也就是.class文件什么时候被读取到虚拟机的内存中并且达到可用的状态。

初始化时机

使用new实例化对象时读取或者设置一个类的静态字段或者方法时。

反射调用时例如Class.forName(“com.xxx.ClassName”)初始化一个类的子类会首先初始化子类的父类Java虚拟机启动时标明的启动类JDK8之后接口中存在default方法这个接口的实现来初始化时接口会在其之前进行初始化。

**注**这五个阶段并不是严格意义上的按顺序完成在类加载过程中这些阶段会互相混合交叉运行最终完成类的加载和初始化。

通过类的全限定名去找到其对应的.class文件将这个.class文件内的二进制数据读取出来转化成方法区的运行时数据结构在java堆中生成一个代表这个类的java.lang.Class对象作为对方法去中这些数据的访问入口

Class文件中的内容是字节码这些内容可以由任何途径产出验证阶段的目的是保证文件内容里边的字节流符合Java虚拟机规范且这些内容信息运行后不会危害虚拟机的自身的安全。

**元数据验证**对字节码描述的元数据信息进行语义分析要符合java语言规范

字节码验证对类的方法体进行校验确保这些方法在运行时是合法的符合逻辑的

验证阶段是非常重要的但不是必须的对程序运行期没有影响如果在保证引用的类经过验证的情况下可以考虑使用-Xverifynone参数来关闭大部分的类验证措施以缩短虚拟机类加载的时间。

1.内存分配仅包括static修饰过的变量而不包含实例变量实例变量得等到对象实例化的时候分配内存2.初始值指的是变量数据类型的默认值而不是被在java代码中显式赋予的值当字段被final修饰成常量时这个初始值就是java代码中显式赋予的值。

例如public

3.在JDK取消永久代后方法区变成了一个逻辑上的区域这些类变量的内存实际上是分配在java堆中的。

这个阶段虚拟机会把这个Class文件中常量池的符号引用转换为直接引用。

主要解析的是类或者接口字段类方法接口方法方法类型方法句柄等符号引用。

符号引用转换为直接应用的过程就是当前加载的这个类和它所引用的类正式进行连接的过程。

java代码在编译期间是不知道最终引用的类型具体指向内存中的哪个位置的此时会用一个符号引用来表示具体引用的目标是谁Java虚拟机规范中明确定义了符号引用的形式符合这个规范的前提下符号引用可以是任意值只要能通过这个值能定位到目标什么是直接引用

类加载的最后一步初始化的过程就是执行类构造器clinit()方法的过程

当初始化完成之后类中static修饰的变量会赋予程序员实际定义的值同时类中如果存在static代码块也会执行这个静态代码里边的代码

在准备阶段已经对类中static修饰的变量赋予了初始值。

clinit()方法的作用就是给这些变量赋予程序员实际定义的值。

同时类中如果存在static代码块也会执行这个静态代码块里边的代码clinit方法是什么

clinit方法和init方法是不同的它们一个是类构造器一个是实例构造器java虚拟机会保证子类clinit方法在执行前父类的clinit已经执行完毕。

而init方法则需要显性的调用父类的构造器

clinit()方法由编译器自动生成但不是必须生成的只有这个类存在static修饰的变量或者类中存在静态代码块的时候才会自动生成clinit方法加载过程总结

当一个符合java虚拟机规范的字节流文件经历加载验证准备解析初始化这些阶段相互协作完成之后加载阶段读取到的Class字节流信息会按虚拟机规定的格式在方法区保存一份然后会在java堆中会创建一个java.lang.Class类的对象这个对象描述了这个类所有信息也提供了这个类在方法区的访问入口。

方法区中使用同一加载器的情况下每个类只会有一份Class字节流信息

Java堆中使用同一加载器的情况下每个类中只会有一份java.lang.Class类的对象类加载器

类加载器就是在加载阶段通过类的全限定名获取该类字节流数据的动作。

三层类加载器介绍

Loader负责加载JAVA_HOME\lib中或者java.ext.dirs指定目录下的jar包由java代码实现。

应用程序类加载器Application

Class

Loader程序开发者开发的应用程序有他加载负责加载ClassPath路径下的所有jar包

双亲委派模型

任何一个类加载器在接到一个类的加载请求时都会先让其父类进行加载只有父类无法加载或者没有父类的情况下才尝试加载

protected

findBootstrapClassOrNull(name);}}

catch

使用双亲委派模型可以保证每一个类只会有一个类加载器例如java最基础的Object类它存放在rt.jar中这是Bootstrap的职责范围当向上委派到Bootstrap时就会被加载但是如果没有双亲委派模型可以任由自定义类加载器加载的话Java的核心api就会被随意篡改

1、类加载器类型

Android跟java有很大的渊源基于jvm的java应用是通过classLoader来加载应用中的class的Android对jvm优化过使用的是dalvik虚拟机且class文件会被打包进一个dex文件中底层虚拟机有所不同那么它们的类加载器也会有区别。

BootClassLoader:

Framework层的class字节码文件类似java的BootStrapClassLoaderPathClassLoader:

加载已经安装到系统中的APK的class字节码文件类似java的App

ClassLoaderDexClassLoader:加载指定目录的class字节码文件类似java中的Custom

ClassLoader

2、PathClassLoader与DexClassLoader的区别

1使用场景

只能加载已经安装到Android系统的apk文件data/app下的dex/jr/zip文件比PathClassLoader更灵活

2代码差异

PathClassLoader与DexClassLoader都继承于BaseDexClassLoaderPathClassLoader与DexClassLoader在构造函数中都调用了父类的构造函数但DexClaccLoader多传了一个optimizeDirectory

3、BaseDexClassLoader

parent){super(parent);this.pathList

new

dexPath:要加载的程序文件一般是dex文件也可以是jar/apk/zip文件所在因为在加载jar/apk/zip等压缩格式的文件时会解压出其中的dex文件该目录就是专门用于存放这些被解压出来的dex文件liraryPath加载程序文件时需要用到的库路径parent:父加载器

pathClassLoader只会加载已安装包中的dex文件而dexClassLoader不仅仅可以加载dex文件还可以加载jar,apk,zip中的dex。

jar

apk

zip就是一些压缩格式要拿到压缩包里边的dex文件就需要解压。

所以DexClassLoader在调用父构造函数时会指定一个解压目录

findClass()

类加载器会提供一个方法来供外界找到它所加载的class,该方法就是findClass()。

private

实质是通过pathList的对象findClass()方法来获取classClass

null)

可以看到BaseDexClassLoader的findClass()方法实际上是通过DexPathList对象的findClass()方法来获取class,而这个DexPathLIst对象恰好在之前的BaseDexClassLoader构造函数中就已经被创建好了。

4.DexPathList

definingContext;this.dexElements

makeDexElements(splitDexPath(dexPath),

optimizedDirectory,suppressedExceptions);...

构造函数中保存了当前类加载器definingContext并调用的makeDexElements()得到Element集合

通过对splitDexPath(dexPath)的源码追溯发现该方法的作用其实就是将dexPath拼接起来的字符串(如/data/dexdir1:/data/dexdir2:…)。

makeDexElements()方法

2.遍历所有dex文件也可能是jar、apk或zip文件for

(File

如果是apk、jar、zip文件这部分在不同的Android版本中处理方式有细微差别}

else

3.将dex文件或压缩文件包装成Element对象并添加到Element集合中if

((zip

4.将Element集合转成Element数组返回return

elements.toArray(new

总体来说DexPathList的构造函数是将一个个的程序文件可能是dex、apk、jar、zip封装成一个个Element对象最后添加到Element集合中。

Android的类加载器不管是PathClassLoader还是DexClassLoader它们最后只认dex文件而loadDexFile()是加载dex文件的核心方法可以从jar、apk、zip中提取出dex

findClass()

(dexElementsSuppressedExceptions

null)

{suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));}return

null;

DexPathList的findClass()方法很简单就只是对Element数组进行遍历一旦找到类名与name相同的类时就直接返回这个class找不到则返回null。

调用DexFile的loadClassBinaryName()方法来加载class这是因为一个Element对象对应一个dex文件而一个dex文件则包含多个class。

也就是说Element数组中存放的是一个个的dex文件而不是class文件。

这可以从Element这个类的源码和dex文件的内部结构看出。

根据前面的分析我们总结下android与java在类加载上的异同

Android类加载器和Java的类加载器工作机制是类似的使用双亲委托机制

Android虚拟机运行的是dex字节码Java虚拟机运行的class字节码。

类加载器不同以及类加载器的类体系结构不同

如上面的类加载器结构图BootClassLoader和Java的BootStrapClassLoader区别Android虚拟机中BootClassLoader是ClassLoader内部类由java代码实现而不是c实现是Android平台上所有ClassLoader的最终parent这个内部类是包内可见,所以我们没法使用。

Java虚拟机中BootStrapClassLoader是由原生代码(C)编写的负责加载java核心类库(例如rt.jar等)ClassLoader类中的findBootstrapClassOrNull方法android

sdk直接返回nulljdk会去调用native方法findBootstrapClass如下源码