类加载时机：
如果类没有进行初始化，则需要先触发其的初始化。有且只**5** 种情况下必须立即对类进行初始化：

• 创建类的实例（new 的方式），访问某个类或者接口静态变量，或者对该静态变量进行赋值，调用类的静态方法（类.xxx调用）
• 反射的方式
• 初始化某个类的子类，其父类也会被初始化
• java虚拟机启动时，被标明为启动类的类直接使用java.exe命令来运行某个主类（包含main方法的那个类）
• 当使用JDL1.7的动态语言支持时

类的生命周期：
包括七个阶段：加载，验证，准备，解析，初始化，使用，卸载，其中（验证，准备，解析）统称为连接。

解析阶段在某些情况下在类的初始化后再开始，这是为了支持java语言的运行时绑定（动态绑定：多态部分）

了解：
Java虚拟机中类加载的全过程：加载，验证，准备，解析，初始化这五个阶段具体执行的动作：

• 加载：
  1.通过一个类的全限定名来获取定义此类的二进制字节流
  2.将这个字节流所代表的静态存储结构转换为方法区的运行是数据结构
  3.在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类各种数据的访问入口
• 验证：
  1.为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全
• 准备：
  1.正式为类变量分配内存并且设置类变量初始值的阶段，这些变量所使用的内存都要在方法区中进行分配

假设一个类变量的定义如下：
public static int value=123;
那变量value在准备阶段过后的初始值为0而不是123，因为这时候尚未开始执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器clinit()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。

• 解析：
  1.虚拟机将常量池中符号引用替换为直接引用的过程
  •符号引用：符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。
  •直接引用：直接引用是和虚拟机实现的内存布局相关的。如果有了直接引用，那引用的目标必定已经在内存中存在。

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

public class Test{static{i=0; //给变量赋值可以正常编译通过System.out.print(i); //这句编译器会提示"非法向前引用"}static int i=1；
}

•clinit()方法与类的构造函数（或者说实例构造器()方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的()方法执行之前，父类的()方法已经执行完毕。因此在虚拟机中第一个被执行的()方法的类肯定是java.lang.Object。

•clinit()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成()方法。

•接口中定义的变量使用时，接口才会初始化：接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生clinit()方法。但接口与类不同的是，执行接口的clinit()方法不需要先执行父接口的clinit()方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的clinit()方法。

•虚拟机会保证一个类的clinit()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的clinit()方法，其他线程都需要阻塞等待，直到活动线程执行clinit()方法完毕。如果在一个类的clinit()方法中有耗时很长的操作，就可能造成多个进程阻塞，在实际应用中这种阻塞往往是很隐蔽的。

类加载器：
类加载器可以分为：启动类加载器（Bootstrap ClassLoader），扩展类加载器（Extension ClassLoader），应用程序类加载器（Application ClassLoader），自定义类加载器。

类加载机制：双亲委派机制
双亲委派模型工作过程：如果一个类加载器收到类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器当中，只有当父类加载器反馈自己无法完成这个请求时（父类加载器的搜索范围内无法找到所需的类），子类加载器才会尝试自己去加载

使用双亲委派机制去组织各种类加载器之间的关系，有一个显而易见的好处是：各个类加载器环境中都是同一个类，如果不使用这种机制那么各个类加载器环境中都是各自加载的类，属于不同类，应用程序会变得混乱

类加载器给⽤用户提供最⼤大的帮助为：可以通过动态的路径进行类的加载操作。

比较两个类相等的前提：必须是由同一个类加载器加载的前提下才有意义。否则，即使两个类来源于同
一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那么这两个类注定不相等。