Java的ClassLoder的父子关系如下：Bootstrap--ExtClassClassLoader---AppClassLoader。

JVM启动时先运行启动类加载器Bottstrap，主要加载Java核心API；然后加载扩展类加载器ExtClassLoder，该加载器加载rt.jar中的class；然后再加载应用类加载器AppClassLoader，该加载器加载当前应用CLASS_PATH下的Class文件。一般我们自定义的类记载器的Parent都是AppClassLoader。

Android的ClassLoader关系如下：

BootClassLoader：启动了加载器，和Java虚拟机不同，BootClassLoader是由Java代码实现，而不是C++实现。

BaseDexClassLoader：用于加载dex文件，PathClassLoader和DexClassLoader是它的两个实现类。它的构造函数如下：

其中dexPath指目标类所在的apk或jar文件，类装载器从该路径查找指定的类，该路径必须是apk或者jar的全路径；optomizedDirectory指的是dex的释放路径，由于dex包含在apk或者jar包中，因此需要需要先进行解压，该路径就是dex解压后存放的路径；libraryPath表示C/C++等SO库存放的路径；parent指的是该加载器的父加载器，可以使用context.getClassLoader(默认为PathClassLoader)作为父加载器。

DexClassLoader:支持加载APK、dex、jar，也可以从SD卡加载。

PathClassLoader:该加载器将optomizedDirectory设置为null，默认路径为/data/dalvik-cache目录，即加载已经安装的应用。

Java Class的加载过程：

可以看出Java的类加载使用双亲委派机制，即先到父加载器进行加载，加载不到才使用自己进行加载。这样做是为了安全性，例如用户自己定义一个String.java，采用双亲机制可以保证用户在使用String的时候使用的是java.lang.String，而不是自己定义的String。

Android 类加载机制和android一样，也是双亲委派机制，BaseDexClassLoader继承与ClassLoader，loadClass的实现和java的loadClass实现一样，基于双亲委派机制，最终会调用到BaseDexClassLoader的findClass函数；下图所示为BaseDexClassLoader的findClass实现。

BaseDexClassLoader.findClass会去调用pathList的findClass，pathList类型为DexPathList，里面存放着dex数组，类型为Element，Element里面存储DexFile。DexPathList的findClass如下：

findClass的时候就是调用按顺序调用Element数组的每个Element的findClass方法，所以我们可以看到，要想动态替换某个class，可以修改Element数组，将新的class对应的Element放到数组第一个。Element的findClass实现如下：

Element的findClass会调用dexFile的loadClassBinaryName，最终调用dexFile的defineClass，实现如下：

class加载流程：

1、加载类：根据类的全限定名，获取类的二进制数据流；解析类的而紧凑数据流为方法区数据结构，也就是将类文件放入方法区；创建java.lang.Class类的实例。

2、连接：验证字节码文件是否符合规范。

3、准备：正式为类变量（static变量）分配内存，并设置初始值，这些内存都将在方法区进行分配。这里只分配类变量，不包含实例变量，实例变量将会在对象实例化时一起分配在堆上。

4、解析：将类、接口、字段和方法的符号引用转为直接引用

5、初始化：开始执行class字节码。

父类静态代码块和父类静态成员初始化；子类静态代码块和子类静态成员初始化；父类非静态代码块和普通成员初始化；父类构造函数执行；子类非静态代码块和普通成员执行；子类构造函数执行。

static静态代码块和类的static静态成员(这两个按照代码的先后顺序执行)；非静态代码块和普通成员初始化(在执行new关键字创建对象的时候才执行)；构造函数执行(new对象的时候先执行普通成员的初始化，然后执行构造函数)

Note：当具有过个静态成员和静态代码块时，初始化顺序和成员在程序中申明的顺序一致；当有多个普通成员时，初始化普通成员的顺序和申明顺序一致。静态成员只会进行一次初始化，类的多个实例共享一个静态成员。

WHY：

类的初始化收到JVM类加载机制的控制，类的加载机制包括加载、验证、解析、初始化等不住。不管在继承还是非继承关系中，类的初始化主要受到JVM类加载时机、解析和cinit初始化规则的影响。

加载是类加载机制的第一个节点，只有在主动引用的情况下才会触发类的机制，如下：程序启动需要触发main方法的时候，虚拟机会先触发这个类的初始化；使用new关键字实例化对象、读取或设置一个类的静态字段(被final修饰、JIT时放入常量池的静态字段除外)、调用一个类的静态方法会触发初始化；当初始化一个类的时候，如果其父类还没有初始化，则先触发其父类初始化。

类加载机制的解析阶段将常量池中的符号音乐替换为直接引用，主要针对的是类或者接口、字段、类方法、方法类型、方法句柄和调用点限定符。在字段解析、类方法解析、方法类型解析中，遵守承关系中自下而上递归搜索解析的规则，由于递归的特性(栈的后进先出的特性)，所有初始化过程则是由下而上、从父类到子类的初始化顺序。

初始化阶段是执行类构造器方法clinit()的过程，clinit()是编译器自动收集类中的所有类变量(静态变量)的赋值动作和静态代码块合并生成的函数。编译器收集的顺序是由语句在源文件中出现的顺序决定的。JVM会保证在子类的clinit()方法执行之前父类的clinit()方法已经执行完毕。因此所有的初始化过程都是在clinit中，保证了静态变量和静态代码块总数最先初始化。

Init和clinit的区别：

init是对象构造器方法，也就是说在程序执行new一个对象调用该对象的constructor时才会执行init方法；而clint是类的构造器方法，也就是在jvm进行类的加载—验证—解析—初始化中的的方法，在class文件的初始化节点jvm会调用clinit方法。

init是instance实例构造器，对非静态变量进行初始化；而clinit是class类构造器，对静态变量、静态代码块进行初始化。

clinit详解：在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类的变量和其他资源，或者可以从另一个角度来表达：初始化阶段是执行类构造器()方法的过程。该方法是由编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态代码块只能访问到定义在静态代码块之前的变量，定义在她之后的变量，在前面的静态代码块可以赋值，但是不能访问：

JVM会保证在子类执行之前，父类的方法已经执行完毕，因此，虚拟机中第一个被执行的方法是Object的，由于父类的方法先执行，也就意味着父类中定义的静态代码块优先于子类的变量赋值操作，如下代码，字段B的值将会是2，而不是1。

接口中不能使用静态代码块，但仍然有变量初始化赋值操作，因此接口和类一样会生成方法，但与类不同的是，执行接口的方法不需要先执行父接口的方法，只有当父接口中定义的变量使用时父接口才会初始化。另外，接口的实现类在初始化的时候也一样不会执行接口的方法。接口中的属性都是static final类型的变量，在准备阶段就已经初始化完成。

class卸载：

class卸载需要如下条件：class所有的实例已经被回收、加载该类的ClassLoader已经被回收、该类的对象没有被引用了。