类加载

类从加载到虚拟机内存中开始，到卸载出内存为止，它的证生命周期包括：
加载–验证–准备–解析–初始化–使用–卸载，其中验证–准备–解析成为链接。

在遇到下列情况，若没有初始化，则需要先触发其初始化（加载–验证–准备 自然需要在此之前）

1）

• 1.使用new关键字实例化对象
• 2.读取或设置一个类的静态字段
• 3.调用一个类的静态方法。

2）使用java.lang.reflect包的方法对类进行反射调用时，若类没有进行初始化，则需要触发其初始化。
3）当初始化一个类时，若发现其父类还么有初始化，则要先触发其父类的初始化。
4）党虚拟机启动时，用户需要制定一个执行的主类（有main房的那个类），虚拟机会先初始化这个类。

在加载阶段，虚拟机需要完成下面3件事：
1）通过一个类的全限定名获取定义此类的二进制字节流；
2）将这个字节流所表示的静态存储结构转化为方法区运行时数据结构；
3）在内存中生成一个代表这个类的class对象，作为方法区的各种数据的访问入口。

验证的目的是为了确保class文件的字节流中包含的信息符合当前虚拟机的要求，且不会危害虚拟机自身的安全。验证大致会完成下面4个阶段的检验动作：
1）文件格式验证；
2）元数据验证；
3）字节码验证
4）符号引用验证

字节码验证将对类的方法进行校验分析，保证被校验的方法在运行时不会做出危害虚拟机的事，一个类的方法体的字节码没有通过字节码验证，那一定有问题，但若一个方法通过了验证，也不能说明它一定安全。

准备阶段是正式为类变量分配内存并设置变量的初始化值得到阶段，这些变量所使用的内存都将在方法区中进行分配。（不是实例变量，且是初始化，若 public static int a = 123;准备阶段后a的值为0，而不是123，要在初始化之后才变为123，但若被final修饰，public static final int a = 123;在准备阶段后就变成了123）。

解析阶段是虚拟机将常量池中的符号引用变为直接引用的过程。

静态代码块只能访问在静态代码块之前的变量，在它之后的变量，在前面的静态代码块中可以复制，但是不可以使用。

通过一个类的全限定名来获取定义此类的二进制字节流，实现这个动作的代码就是**“类加载器”。**

比较两个类是否相同，只有这两个类是由同一个类加载器记载的前提下才有意义，否则即使这两个类来源于同一个class文件，被同一个虚拟机加载，只要加载他们的加载器不同，他们就是不同类。

从Java虚拟机的角度来说，只存在两种不同的类加载器：一种是启动类加载器，这个类加载器使用C++实现，是虚拟机自身的一部分。另一种就是所有其他类加载器，这些类加载器都是由Java实现，且全部继承自java.lang.ClassLoader。

从Java开发人员角度，类加载器分为：
1）启动类加载器，这个类加载器负责把<HAVA_HOME>\lib目录中或者-Xbootclasspath下的类库加载到虚拟机内存中，启动了加载器无法被Java程序直接引用。
2）扩展类加载器，负责加载<HAVA_HOME>\lib\ext下或者java.ext.dirs系统变量指定路径下all类库，开发者可以直接使用扩展类加载器。
3）应用程序类加载器，负责加载用户路径classpath上指定的类库，开发者可以直接使用这个类加载器，若应用程序没有定义过直接的类加载器，一般情况下，这个就是程序默认的类加载器。

双亲委派模型：若一个类加载器收到了类加载请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给福利加载器去完成，每一层的加载器都是如此，因此all加载请求最终都是应该传送到顶级的启动类加载器。只有当父类加载器反馈自己无法加载时（他的搜索范围中没有找到所需的类）时，字加载器才会尝试自己去加载。

双亲委派模型的好处：eg,object类。它存在rt.jar中，无论哪个类加载器要加载这个类，最终都是委派给处于模型顶端的启动类加载器加载，因此object类在程序的各种加载环境中都是同一个类。

当运行一个程序时，JVM启动，运行bootstrap classloader。该classloader加载核心API（Ext classloader 和app classloader也在此时被加载），then调用ext classloader加载扩展API，最后app classloader加载classpath目录下定义的class，这就是一个程序最基本的加载流程。

通过classloader加载类实际上就是加载的时候并不对该类进行解析，因此也不会初始化，而class类的forName方法则相反，使用forName方法加载的时候回将class进行解析与初始化。