1.类加载的时机
类的生命周期：加载->连接[验证->准备->解析]->初始化->使用->卸载
必须立即对类进行初始化的5种情况（有且仅有），这5种情况是对类的主动引用：
1）遇到new /getstatic/putstatic/invokestatic这四条字节码指令时，对应到java中，即，使用new实例化对象、读取或设置静态变量（被final修饰的除外，已在编译期写入常量池）、调用静态方法
2）使用java.lang.reflect包的方法对类进行反射调用时
3）对类进行初始化时，若其父类还未初始化，则先触发对父类的初始化
4）虚拟机启动时，会对主类（含有main函数的类）进行初始化
5）使用动态语言时，若解析结果是ref_getstatic/res_putstatic/ref_invokestatic的方法句柄时，则方法句柄对应的类需被初始化
对类的被动引用时，不触发类的初始化，如：
1）通过子类引用父类的静态字段，不会导致子类初始化（super中有static value, 通过subclass.value调用）。
2）通过数组引用类（A[] a=new A[10],A不会被初始化，而是会有newArray指令触发 [A 类的初始化）。
3）被final修饰的常量，在编译阶段会存入常量池，因此访问的时候不会触发其类的初始化。
4）初始化接口类时不要求接口的父类被初始化，只有在真正使用到父类接口时才会初始化父类。
2.类加载的过程
2.1加载
加载过程中，虚拟机需完成：1）通过类的全限定名获取类的二进制字节流。2）将字节流所代表的静态存储结构转换为方法区的运行时数据结构（我的理解是类的元数据）。3）在内存中生成代表这个类的java.lang.class对象，作为方法区这个类的各种数据的访问入口。（class对象是在方法区而非堆中，作为程序访问方法区数据的外部接口）
2.2验证
为了确保class文件符合虚拟机的要求，且不会危害虚拟机的安全。
1.文件格式验证：魔数、主次版本号、常量池中的常量是否有不被支持的常量类型、。。
2.元数据验证：对字节码的语义分析，以符合java规范，主要是类的元数据信息是否符合java规范。类是否有父类、类中的字段和方法是否与父类产生矛盾（如覆盖被final修饰的字段、不规范的方法重载）等
3.字节码验证：主要对类的方法体进行校验分析。如类型转换是否合法等
4.符号引用验证：发生在虚拟机将符号引用转化为直接引用的时候，这个转化发生在解析阶段。校验内容：符号引用中通过字符串描述的全限定名是否能够找到对应的类，符号引用的类、字段、方法的访问性是否可被当前类访问......
验证是重要但非必须阶段，若可以代码已经被反复使用和验证过，可通过关闭验证来缩短虚拟机的类加载时间。
2.3准备
准备阶段是为类变量分配内存并设置类变量的初始值（默认初始值0值，初始化时才会被赋值，除了final常量）。注意：仅仅是类变量，实例变量在实例化对象的时候分配在java堆中。
2.4解析
解析是将常量池中的符号引用替换为直接引用的过程。符号引用与内存布局无关，是定义在class文件格式中的。直接引用则与虚拟机实现的内存布局相关，可以是指向目标的指针、相对偏移量或能够间接定位到目标的句柄。
2.5初始化
准备阶段是对变量分配内存和赋0值，初始化阶段则是为变量赋值为程序指定的值。初始化实际上是执行类构造器
3.类加载器
类加载器这个模块的代码是放在虚拟机之外的，用户可自定义的（可以自定义指定从不同的源获取class文件）。类加载器通过一个类的全限定名来获取描述此类的二进制字节流。
任意一个类，由加载它的类加载器和这个类本身一同确立其在虚拟机中的唯一性。（若一个类被不同加载器加载，则其实例的类型是不同的）
双亲委派模型：
启动类加载器（bootstrap classloader）<-扩展类加载器（extension classloader）<-应用程序类加载器（application classloader）<-自定义类加载器（user classloader），如果一个类加载器收到类加载请求，则会请求委派给其父类加载器，只有当父类加载器反馈自己无法加载请求时（它的搜索范围内没有找到所需的类），子类才会尝试自己加载。
- 启动类加载器（Bootstrap ClassLoader）:这个类加载器负责装载Java API（java 核心类库） 。将存放在\lib 目录中的或者被-Xbootclasspath参数所指定的路径中的，并且是被虚拟机识别的类库加载到虚拟机内存中。这个类加载器是在JVM启动的时候创建的，和其他的类装载器不同的地方在于这个装载器是通过native code来实现的，而不是用Java代码。
- 扩展类加载器（Extension classLoader）：它负责加载\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可用直接使用扩展类加载器。
- 应用程序类加载器（Application ClassLoader）:也称为系统类加载器，它负责加载类路径(ClassPath) 上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
我们的应用程序都是由这3种类加载器互相配合进行加载的，如果有必要，还可以加入自己定义的类加载器
类加载器命名空间：
JAVA中，由不同类加载器加载的类在虚拟机中位于不同的命名空间下，不同命名空间下的类相互不可见。
通常会有一些疑问：如果有一个类A使用了java.util.List类，为什么在运行时会没有错误。因为按照类加载的双亲委派机制，自己写的类A一般由系统类加载器加载，而java.util.List肯定是由启动类加载器(也叫Root类加载器)加载的，所以这两个类应该不在一个命名空间下。那在运行时为什么类A还 是能访问到java.util.List？
如果类A被AppClassLoader加载，那么AppClassLoader就是此A在虚拟机中对应类型的初始类加载器。
所说的“命名空间”，是指jvm为每个类加载器维护的一个“表”,这个表记录了所有以此类加载器为“初始类加载器”（而不是定义类加载器，所以一个类可以存在于很多的命名空间中）加载的类的列表。
根据Java虚拟机规范规定，在这个过程中涉及的所有类加载器–即从AppClassLoader到Bootstrap ClassLoader间，参与过加载的，都被标记为该类型的初始类加载器。实际加载的称为定义类加载器。
所以
再回到刚到A使用java.util.List的例子，当A被加载后，解析到A使用了List，就会请求加载java.util.List。根据类的加载原理及双亲委派机制。会先请类A的类加载器，即AppClassLoader加载java.util.List，AppClassLoader当然加载不了这个List，所以它会委派给自己的父加载器，即ExtClassLoader；同理，最终会由Bootstrap ClassLoader加载这个java.util.List，并成功返回。 所以对于List来说，AppClassLoader是初始类加载器，bootstrap是定义类加载器。List在AppClassloader的命名空间中，所以类A可以访问List。
线程上下文类加载器
双亲委派模型很好地解决了个各类加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载），基础类之所以称为”基础”，是因为他们总是作为被用户代码调用的API，但如果基础类又要调用回用户的代码，那怎么办呢？
比如rt.jar中的spi服务，比如JDBC。它存在的包rt.jar是由BootStrapClassLoader加载的，但是在它的DriverManager中会调用spi具体的实现类，而DriverManager是由BootStrapClassLoader定义的，所以也会用BootStrapClassLoader 来加载实现类 ，但BootStrapClassLoader加载器无法加载这些代码。
为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）,有了线程上下文加载器，spi服务就可以使用contextClassLoader加载器去加载所需要的spi实现类的代码，所以BootStrapClassLoader就是spi实现类的初始加载器，contextClassLoader是spi实现类的定义类加载器，这样的话，在BootStrapClassLoader命名空间中就会有spi实现类，所以DriverManager里面就可以直接访问mysql类了。