1.1.1. 考察点：

代码执行顺序
描述java的类加载的过程
双亲委派模型

执行顺序（优先级从高到底）：

静态代码块
main方法
构造代码块
构造方法

其中静态代码块执行一次，构造代码块每次创建都会执行

以上方法从父类到子类，依次执行。如A 的static method

范例:Person person = new Person();为例进行说明。

查找Person.class，并加载到内存中。
执行类里的静态代码块。
在堆内存里开辟内存空间，并分配内存地址。
在堆内存里建立对象的属性，并进行默认的初始化。
对属性进行显示初始化。
对对象进行构造代码块初始化。
调用对象的构造函数进行初始化。
将对象的地址赋值给person变量。

描述一个类的加载过程？Java虚拟机通过装载、连接和初始化一个类型，使该类型可以被正在运行的Java程序使用。

加载：把二进制形式的Java类型读入Java虚拟机中。
连接：把装载的二进制形式的类型数据合并到虚拟机的运行时状态中去。
验证：确保Java类型数据格式正确并且适合于Java虚拟机使用。
准备：负责为该类型分配它所需内存。
解析：把常量池中的符号引用转换为直接引用。(可推迟到运行中的程序真正使用某个符号引用时再解析)
初始化：为类变量赋适当的初始值

1.1.2. 加载

通过该类型的全限定名，产生一个代表该类型的二进制数据流。
解析这个二进制数据流为方法去内的内部数据结构。
创建一个表示该类型的java.lang.Class类的实例。

Java虚拟机在识别Java class文件，产生了类型的二进制数据后，Java虚拟机必须把这些二进制数据解析为与实现相关的内部数据结构。装载的最终产品就是Class实例，它称为Java程序与内部数据结构之间的接口。要访问关于该类型的信息(存储在内部数据结构中)，程序就要调用该类型对应的Class实例的方法。这样一个过程，就是把一个类型的二进制数据解析为方法区中的内部数据结构，并在堆上建立一个Class对象的过程，这被称为"创建"类型。

1.1.3. 验证

确认装载后的类型符合Java语言的语义，并且不会危及虚拟机的完整性。

装载时验证：检查二进制数据以确保数据全部是预期格式、确保除Object之外的每个类都有父类、确保该类的所有父类都已经被装载。
正式验证阶段：检查final类不能有子类、确保final方法不被覆盖、确保在类型和超类型之间没有不兼容的方法声明(比如拥有两个名字相同的方法，参数在数量、顺序、类型上都相同，但返回类型不同)。
符号引用的验证：当虚拟机搜寻一个被符号引用的元素(类型、字段或方法)时，必须首先确认该元素存在。如果虚拟机发现元素存在，则必须进一步检查引用类型有访问该元素的权限。

1.1.4. 准备

当Java虚拟机装载一个类，并执行了一些验证之后，类就可以进入准备阶段。在准备阶段，Java虚拟机为类变量分配内存，设置默认初始值。但在到到初始化阶段之前，类变量都没有被初始化为真正的初始值。

boolean在内部常常被实现为一个int，会被默认初始化为0。

1.1.5. 解析

类型经过连接的前两个阶段--验证和准备--之后，就可以进入第三个阶段--解析。解析的过程就是在类型的常量池总寻找类、接口、字段和方法的符号引用，把这些符号引用替换为直接引用的过程。

类或接口的解析：判断所要转化成的直接引用是数组类型，还是普通的对象类型的引用，从而进行不同的解析。
字段解析：对字段进行解析时，会先在本类中查找是否包含有简单名称和字段描述符都与目标相匹配的字段，如果有，则查找结束；如果没有，则会按照继承关系从上往下递归搜索该类所实现的各个接口和它们的父接口，还没有，则按照继承关系从上往下递归搜索其父类，直至查找结束，

1.1.6. 初始化

为类变量赋予“正确”的初始值。这里的“正确”的初始值是指程序员希望这个类变量所具备的初始值。所有的类变量(即静态量)初始化语句和类型的静态初始化器都被Java编译器收集在一起，放到一个特殊的方法中。 对于类来说，这个方法被称作类初始化方法；对于接口来说，它被称为接口初始化方法。在类和接口的class文件中，这个方法被称为<clinit>。

初始化类的步骤：

1. 如果存在直接父类，且直接父类没有被初始化，先初始化直接父类。
2. 如果类存在一个类初始化方法，执行此方法。

这个步骤是递归执行的，即第一个初始化的类一定是Object。初始化接口并不需要初始化它的父接口。

Java虚拟机必须确保初始化过程被正确地同步。 如果多个线程需要初始化一个类，仅仅允许一个线程来进行初始化，其他线程需等待。

这个特性可以用来写单例模式。

1.1.7. <clinit>()方法

对于静态变量和静态初始化语句来说：执行的顺序和它们在类或接口中出现的顺序有关。
并非所有的类都需要在它们的class文件中拥有<clinit>()方法， 如果类没有声明任何类变量，也没有静态初始化语句，那么它就不会有<clinit>()方法。如果类声明了类变量，但没有明确的使用类变量初始化语句或者静态代码块来初始化它们，也不会有<clinit>()方法。如果类仅包含静态final常量的类变量初始化语句，而且这些类变量初始化语句采用编译时常量表达式，类也不会有<clinit>()方法。只有那些需要执行Java代码来赋值的类才会有<clinit>()
final常量：Java虚拟机在使用它们的任何类的常量池或字节码中直接存放的是它们表示的常量值。

1.1.8. 主动使用和被动使用

所有Java虚拟机实现必须在每个类或接口首次主动使用时初始化。

当创建某个类的新实例时(new、反射、克隆、序列化)
调用某个类的静态方法
使用某个类或接口的静态字段，或对该字段赋值(用final修饰的静态字段除外，它被初始化为一个编译时常量表达式)
当调用Java API的某些反射方法时。
初始化某个类的子类时。
当虚拟机启动时被标明为启动类的类。

除以上六种情况，所有其他使用Java类型的方式都是被动的，它们不会导致Java类型的初始化。

对于接口来说，只有在某个接口声明的非常量字段被使用时，该接口才会初始化，而不会因为事先这个接口的子接口或类要初始化而被初始化。

使用一个非常量的静态字段只有当类或接口的确声明了这个字段时才是主动使用。 比如：类中声明的字段可能被子类引用；接口中声明的字段可能被子接口或实现了这个接口的类引用。对于子类、子接口或实现了接口的类来说，这是被动使用--不会触发它们的初始化。只有当字段的确是被类或接口声明的时候才是主动使用。

1.1.9. 类加载器

类的加载就是虚拟机通过一个类的全限定名来获取描述此类的二进制字节流，而完成这个加载动作的就是类加载器。

类和类加载器息息相关，判定两个类是否相等，只有在这两个类被同一个类加载器加载的情况下才有意义，否则即便是两个类来自同一个Class文件，被不同类加载器加载，它们也是不相等的。

注：这里的相等性保函Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果以及Instance关键字对对象所属关系的判定结果等。

类加载机制：

类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法去内，然后在堆区创建一个java.lang.Class对象，用来封装在方法区内的数据结构。类的加载最终是在堆区内的Class对象，Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。

类加载有三种方式：

命令行启动应用时候由JVM初始化加载
通过Class.forName（）方法动态加载
通过ClassLoader.loadClass（）方法动态加载

类加载器可以分为三类：

启动类加载器（Bootstrap ClassLoader）：负责加载\lib目录下或者被-Xbootclasspath参数所指定的路径的，并且是被虚拟机所识别的库到内存中。
扩展类加载器（Extension ClassLoader）：负责加载\lib\ext目录下或者被java.ext.dirs系统变量所指定的路径的所有类库到内存中。
应用类加载器（Application ClassLoader）：负责加载用户类路径上的指定类库，如果应用程序中没有实现自己的类加载器，一般就是这个类加载器去加载应用程序中的类库。

这么多类加载器，那么当类在加载的时候会使用哪个加载器呢？

1.1.10. 双亲委派模型

这个时候就要提到类加载器的双亲委派模型，流程图如下所示：

双亲委派模型的整个工作流程非常的简单，如下所示：

如果一个类加载器收到了加载类的请求，它不会自己立去加载类，它会先去请求父类加载器，每个层次的类加器都是如此。层层传递，直到传递到最高层的类加载器只有当 父类加载器反馈自己无法加载这个类，才会有当子类加载器去加载该类。

流程分析

每个ClassLoader实例都有一个父类加载器的引用（不是继承的关系，是一个包含的关系），虚拟机内置的类加载器（Bootstrap ClassLoader）本身没有父类加载器，但可以用作其它ClassLoader实例的的父类加载器。

当一个ClassLoader实例需要加载某个类时，它会在试图搜索某个类之前，先把这个任务委托给它的父类加载器，这个过程是由上至下依次检查的，首先由最顶层的类加载器Bootstrap ClassLoader试图加载，如果没加载到，则把任务转交给Extension ClassLoader试图加载，如果也没加载到，则转交给App ClassLoader 进行加载，如果它也没有加载得到的话，则返回给委托的发起者，由它到指定的文件系统或网络等待URL中加载该类。

如果它们都没有加载到这个类时，则抛出ClassNotFoundException异常。否则将这个找到的类生成一个类的定义，将它加载到内存当中，最后返回这个类在内存中的Class实例对象。

为什么要使用双亲委托这种模型呢？

因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要让子ClassLoader再加载一次。

考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义的类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已经在启动时就被引导类加载器（BootstrcpClassLoader）加载，所以用户自定义的ClassLoader永远也无法加载一个自己写的String，除非你改变JDK中ClassLoader搜索类的默认算法。

但是JVM在搜索类的时候，又是如何判定两个class是相同的呢？

JVM在判定两个class是否相同时，不仅要判断两个类名否相同，而且要判断是否由同一个类加载器实例加载的。

只有两者同时满足的情况下，JVM才认为这两个class是相同的。就算两个class是同一份class字节码，如果被两个不同的ClassLoader实例所加载，JVM也会认为它们是两个不同class。

比如网络上的一个Java类org.classloader.simple.NetClassLoaderSimple，javac编译之后生成字节码文件NetClasLoaderSimple.class，ClassLoaderA和ClassLoaderB这个类加载器并读取了NetClassLoaderSimple.class文件并分别定义出了java.lang.Class实例来表示这个类，对JVM来说，它们是两个不同的实例对象，但它们确实是一份字节码文件，如果试图将这个Class实例生成具体的对象进行转换时，就会抛运行时异常java.lang.ClassCastException，提示这是两个不同的类型。

Android类加载器

对于Android而言，最终的apk文件包含的是dex类型的文件，dex文件是将class文件重新打包，打包的规则又不是简单地压缩，而是完全对class文件内部的各种函数表进行优化，产生一个新的文件，即dex文件。因此加载某种特殊的Class文件就需要特殊的类加载器DexClassLoader。

可以动态加载Jar通过URLClassLoader

1.ClassLoader 隔离问题：JVM识别一个类是由 ClassLoaderid + PackageName + ClassName。

2.加载不同Jar包中的公共类：

让父ClassLoader加载公共的Jar，子ClassLoader加载包含公共Jar的Jar，此时子ClassLoader在加载Jar的时候会先去父ClassLoader中找。(只适用Java)
重写加载包含公共Jar的Jar的ClassLoader，在loClass中找到已经加载过公共Jar的ClassLoader，是把父ClassLoader替换掉。(只适用Java)
在生成包含公共Jar的Jar时候把公共Jar去掉。

1-04.Java类加载