ClassLoader的机制

程序的运行都是先需要将类加载到内存中，所以可以手动加载Class，达到代码动态加载的目的。

APP里有几个ClassLoader？

一个APP里最基本的有2个ClassLoader。

由于需要使用一些系统的、Framework的类，因此需要java里的java.lang.BootClassLoader，在启动的时候就会创建，从而加载类。

由于android的特殊性，class其实是在dex里，所以app里有一个自己的ClassLoader，来加载这里面的类，即 dalvik.system.PathClassLoader。

可以用下面的代码进行测试：

ClassLoader classLoader = getClassLoader();
        if (classLoader != null){
            Log.i("111", "base: " + classLoader.toString());
            while (classLoader.getParent()!=null){
                classLoader = classLoader.getParent();
                Log.i("111", "parent: " + classLoader.toString());
            }
        }

ClassLoader 双亲代理模型

如何加载一个类？

protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
    Class<?> clazz = findLoadedClass(className);
    if (clazz == null) {
        ClassNotFoundException suppressed = null;
        try {
            clazz = parent.loadClass(className, false);
        } catch (ClassNotFoundException e) {
            suppressed = e;
        }
        if (clazz == null) {
            try {
                clazz = findClass(className);
            } catch (ClassNotFoundException e) {
                e.addSuppressed(suppressed);
                throw e;
            }
        }
    }
    return clazz;
}

可以看出，加载一个类会经过以下几步：

  1. 通过 findLoadedClass(String) 检查类是否已经加载过，加载过了则直接返回
  2. 调用父ClassLoader加载器加载类（java里如果没有找到父加载器，则使用内置在虚拟机中的ClassLoader来加载）
  3. 调用本加载器的findClass(Sting)加载class

这样做有个明显的特点，如果一个类被位于树根的 ClassLoader 加载过，那么在以后整个系统的生命周期内，这个类永远不会被重新加载。

双亲模型有如下2点特别重要的作用

  1. class共享，只要是父类加载器加载过的class，其子类的ClassLoader都能使用。一些 Framework 层级的类一旦被顶层的 ClassLoader 加载过就缓存在内存里面，以后任何地方用到都不需要重新加载。
  2. 隔离作用，不同加载器加载的不是同一个类，这样的限制避免了用户自己的代码冒充核心类库的类访问核心类库包可见成员的情况。

java中，只有当两个实例的类名、包名以及加载其的 ClassLoader 都相同，才会被认为是同一种类型，即：

同一个 Class = 相同的 ClassName + 相同的 PackageName + 相同的 ClassLoader

DexClassLoader 和 PathClassLoader

  • DexClassLoader 可以加载 jar/apk/dex，可以从 SD 卡中加载未安装的 apk
  • PathClassLoader 只能加载系统中已经安装过的 apk

导致二者不同的原因是构造函数，DexClassLoader可以指定路径，而PathClassLoader则不能指定。

java层分析

DexClassLoader：

public class DexClassLoader extends BaseDexClassLoader {
    public DexClassLoader(String dexPath, String optimizedDirectory,
            String libraryPath, ClassLoader parent) {
        super(dexPath, new File(optimizedDirectory), libraryPath, parent);
    }
}

PathClassLoader：

public class PathClassLoader extends BaseDexClassLoader {
    public PathClassLoader(String dexPath, ClassLoader parent) {
        super(dexPath, null, null, parent);
    }

    public PathClassLoader(String dexPath, String libraryPath,
            ClassLoader parent) {
        super(dexPath, null, libraryPath, parent);
    }
}

BaseDexClassLoader：

public class BaseDexClassLoader extends ClassLoader {
    /** originally specified path (just used for {@code toString()}) */
    private final String originalPath;
    /** structured lists of path elements */
    private final DexPathList pathList;

    public BaseDexClassLoader(String dexPath, File optimizedDirectory,
            String libraryPath, ClassLoader parent) {
        super(parent);
        this.originalPath = dexPath;
        this.pathList =
            new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
    }
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        Class clazz = pathList.findClass(name);
        if (clazz == null) {
            throw new ClassNotFoundException(name);
        }
        return clazz;
    }
    ... ...
}

DexFile：

public DexFile(String fileName) throws IOException {
    mCookie = openDexFile(fileName, null, 0);
    mFileName = fileName;
    guard.open("close");
}

native private static int openDexFile(byte[] fileContents);

native private static int openDexFile(String sourceName, String outputName, int flags) throws IOException;

native private static void closeDexFile(int cookie);

public Class loadClass(String name, ClassLoader loader) {
    String slashName = name.replace('.', '/');
    return loadClassBinaryName(slashName, loader);
}

public Class loadClassBinaryName(String name, ClassLoader loader) {
    return defineClass(name, loader, mCookie);
}
private native static Class defineClass(String name, ClassLoader loader, int cookie);

DexPathList：

final class DexPathList {
    private static final String DEX_SUFFIX = ".dex";
    private static final String JAR_SUFFIX = ".jar";
    private static final String ZIP_SUFFIX = ".zip";
    private static final String APK_SUFFIX = ".apk";

    private static DexFile loadDexFile(File file, File optimizedDirectory)
            throws IOException {
        if (optimizedDirectory == null) {
            return new DexFile(file);
        } else {
            String optimizedPath = optimizedPathFor(file, optimizedDirectory);
            return DexFile.loadDex(file.getPath(), optimizedPath, 0);
        }
    }

    public Class findClass(String name) {
        for (Element element : dexElements) {
            DexFile dex = element.dexFile;
            if (dex != null) {
                Class clazz = dex.loadClassBinaryName(name, definingContext);
                if (clazz != null) {
                    return clazz;
                }
            }
        }
        return null;
    }
}

可以看出，类实际的操作是在c层，java层只是给出加载的类路径。

C层分析（非代码级别）

类的加载过程主要包含以下几个步骤：

其中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也成为动态绑定或晚期绑定）。

class类结构可以阅读：class文件结构

加载

加载阶段，虚拟机完成3件事情： **1. 通过一个类的全限定名来获取其定义的二进制字节流

  1. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
  2. 在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口**

加载阶段完成后，虚拟机外部的 二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据。

验证

验证的目的是为了确保Class文件中的字节流包含的信息符合当前虚拟机的要求，而且不会危害虚拟机自身的安全。不同的虚拟机对类验证的实现可能会有所不同，但大致都会完成以下四个阶段的验证：文件格式的验证、元数据的验证、字节码验证和符号引用验证。

  • 文件格式的验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。
  • 元数据验证：对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在不符合Java语法规范的元数据信息。
  • 字节码验证：该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。
  • 符号引用验证：这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：

  1. 仅对类变量进行内存的分配，实例变量不在这个时候分配（随着对象一起分配在java堆中）
  2. 类变量设置的初始值只是基本数据类型的默认值，不是被显示赋予的值（这个是在初始化阶段才赋予的）
  3. 对基本数据类型来说，对于类变量（static）和全局变量，如果不显式地对其赋值而直接使用，则系统会为其赋予默认的零值，而对于局部变量来说，在使用前必须显式地为其赋值，否则编译时不通过。
  4. 对于同时被static和final修饰的常量，必须在声明的时候就为其显式地赋值，否则编译时不通过；而只被final修饰的常量则既可以在声明时显式地为其赋值，也可以在类初始化时显式地为其赋值，总之，在使用前必须为其显式地赋值，系统不会为其赋予默认零值。
  5. 数组初始化时没有对数组中的元素赋值，那么数组中的元素将根据对应的数据类型被赋予缺省的值

解析

解析阶段是JVM将常量池中的符号引用转化为直接引用的过程。

  • 符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到了内存中。
  • 直接引用：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那说明引用的目标必定已经存在于内存之中了。

符号引用不表示数据已经在使用，只是告诉虚拟机目标在哪；而直接引用是真实的使用这个数据了。

解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行，分别对应于常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info四种常量类型。

初始化

到了此阶段，才真正开始执行类中定义的Java程序代码。在准备阶段，类变量已经被赋过一次系统要求的初始值，而在初始化阶段，则是根据程序员通过程序指定的主观计划去初始化类变量和其他资源，或者可以从另一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。

<clinit>()方法的执行规则：

  • <clinit>()方法是编译器自动收集类中的所有类变量的赋值和static块中的语句合并产生的。收集的顺序是按照这些语句出现的顺序，这个很重要，绝定了变量的初始值。
    • static块中能访问且操作static块前定义的变量，但是不能操作后面定义的变量，只能访问
  • <clinit>()方法与构造器<init>()方法不同，它不需要显示的调用父类的<clinit>()方法，JVM会保证在子类的<clinit>()方法执行前，父类的<clinit>()方法已经执行完毕。
  • <clinit>()方法并不是都有的，如果类中没有静态语句块，也没有对类变量的赋值操作，那么编译器就不会生成<clinit>（）方法。
  • 接口也是可以有<clinit>()方法的(可以定义static字段)，只是它的执行逻辑和类的逻辑稍有不同，执行接口的<clinit>（）方法不需要先执行父接口的<clinit>（）方法，只有当父接口中定义的变量被使用时，父接口才会被初始化。
  • JVM保证了<clinit>（）方法多线程执行的安全性，可以保证只有一个线程执行这个<clinit>（）方法，其他线程被自动阻塞。

例子：

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

class Child extends Father{  
    public static int b = a;  
}  

public class ClinitTest{  
    public static void main(String[] args){  
        System.out.println(Child.b);  
    }  
}

results matching ""

    No results matching ""