JVM类记载机制介绍
JVM类记载机制就是把描述类的数据从class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型。在Java语言里面，类型的加载、连接和初始化都是在程序运行期间完成的。分为下面3钟
1. 全盘负责，当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入
2. 父类委托，先让父类加载器试图加载该类，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类
3. 缓存机制，缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区。这就是为什么修改了Class后，必须重启JVM，程序的修改才会生效
JVM类加载时机
类的整个生命周期包括：加载（loading）、验证（verification）、准备（preparation）、解析（resolution）、初始化（initialization）、使用（using）和卸载（unloading）7个阶段。其中 验证、准备、解析 3个部分统称连接（linking）。
5种必须立即初始化的情况：
1.遇到new, getstatic, putstatic 或 invokestatic 这4挑字节码指令；
2.使用 java.lang.reflect 包的方法对类进行反射调用；
3.初始化一个类的时候，其父类还没有初始化，必须先触发其父类的初始化；（对于接口，只有在真正用到其父接口的时候才会初始化）
4.虚拟机启动时，用户指定要执行的主类；
5.当使用 JDK 1.7 的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getStatic, REF_putStatic, REF_invokeStatic 的方法句柄，并且这个方法句柄锁对应的类没有进行初始化，则需要先触发其初始化。对于静态字段，只有直接定义这个字段的类才会被初始化。
JVM类加载过程
1.加载
2.验证
1）文件格式验证
2）元数据验证
3）字节码验证
进行数据流和控制流分析，即对类的方法体进行校验分析以保证被校验类的方法在运行时不会做出危害虚拟机安全的行为（如：保证跳转指令不会跳转到方法体以外的字节码指令上等）
即使一个方法通过了字节码验证，也不能说明其一定是安全的（通过程序去校验程序逻辑是无法做到绝对准确的）
4）符号引用验证
3.准备
4.解析
1)符号引用：以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时可以无歧义的定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用目标并不一定已经加载到内存中
2)直接引用：直接指向目标的指针、相对偏移量或一个能间接定位到目标的句柄，直接引用与虚拟机实现的内存布局相关，如果有了直接引用，引用目标必定已经加载到内存中
虚拟机规范并未规定解析动作发生的具体时间，仅要求在执行anewarray、checkcast、getfield、getstatic、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield和putstatic这13个用于操作符号引用的字节码指令之前，先对它们所使用的符号引用进行解析。下面说的很清楚：
在java中，一个java类将会编译成一个class文件。在编译时，java类并不知道引用类的实际内存地址，因此只能使用符号引用来代替。比如org.simple.People类引用org.simple.Tool类，在编译时People类并不知道Tool类的实际内存地址，因此只能使用符号org.simple.Tool(假设)来表示Tool类的地址。而在类装载器装载People类时，此时可以通过虚拟机获取Tool类 的实际内存地址，因此便可以既将符号org.simple.Tool替换为Tool类的实际内存地址，及直接引用地址。
5.初始化
JVM类加载器
虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为类加载器。
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器都拥有一个独立的类名称空间。即比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义。“相等”包括代表类的Class对象的equals()方法、isAssinableFrom()方法、isInstance()方法的返回结果，也包括使用instanceof关键字做对象所属关系判定等情况。
双亲委派模型
从Java虚拟机角度来讲，只存在两种不同的类加载器：一种是启动类加载器，是虚拟机自身的一部分；另一种就是所有其他的类加载器，独立于虚拟机外部，全都继承自抽象类java.lang.ClassLoader。
从Java开发人员的角度来看，类加载器分为3种：
启动类加载器(Bootstrap ClassLoader):这个类存放在<JAVA_HOME>\lib目录中，无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可。
拓展类加载器(Extension ClassLoader):这个类加载器负责加载<JAVA_HOME>\lib\ext目录中的所有类库，开发者可以直接使用。
应用程序类加载器（Application ClassLoader）：这个类加载器是ClassLoader中的getSystemClassLoader（）方法的返回值，所以一般也称它为系统类加载器，负责加载用户类路径上所指定的类库。开发者可以直接使用。
双亲委派模型要求除了顶层的启动类加载器外，其他的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承关系来实现，而是都使用组合关系来复用父加载器的代码。
工作过程：
如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传递到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类Object，它放在rt.jar中，无论哪一个类加载器要加载这个类，最终都是委派给启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。（判断两个类是否相同是通过classloader.class这种方式进行的，所以哪怕是同一个class文件如果被两个classloader加载，那么他们也是不同的类）。
自定义类加载器
通常情况下，我们都是直接使用系统类加载器。但是，有的时候，我们也需要自定义类加载器。比如应用是通过网络来传输 Java 类的字节码，为保证安全性，这些字节码经过了加密处理，这时系统类加载器就无法对其进行加载，这样则需要自定义类加载器来实现。自定义类加载器一般都是继承自 ClassLoader 类，从上面对 loadClass 方法来分析来看，我们只需要重写 findClass 方法即可。下面我们通过一个示例来演示自定义类加载器的流程：
import java.io.*;
public class MyClassLoader extends ClassLoader
{
private String root;
protected Class <? > findClass(String name) throws ClassNotFoundException
{
byte[] classData = loadClassData(name);
if(classData == null)
{
throw new ClassNotFoundException();
}
else
{
return defineClass(name, classData, 0, classData.length);
}
}
private byte[] loadClassData(String className)
{
String fileName = root + File.separatorChar + className.replace('.', File.separatorChar) + ".class";
try
{
InputStream ins = new FileInputStream(fileName);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int bufferSize = 1024;
byte[] buffer = new byte[bufferSize];
int length = 0;
while((length = ins.read(buffer)) != -1)
{
baos.write(buffer, 0, length);
}
return baos.toByteArray();
}
catch(IOException e)
{
e.printStackTrace();
}
return null;
}
public String getRoot()
{
return root;
}
public void setRoot(String root)
{
this.root = root;
}
public static void main(String[] args)
{
MyClassLoader classLoader = new MyClassLoader();
classLoader.setRoot("E:\\temp");
Class <? > testClass = null;
try
{
testClass = classLoader.loadClass("Test2");
Object object = testClass.newInstance();
System.out.println(object.getClass().getClassLoader());
}
catch(ClassNotFoundException e)
{
e.printStackTrace();
}
catch(InstantiationException e)
{
e.printStackTrace();
}
catch(IllegalAccessException e)
{
e.printStackTrace();
}
}
}输入：
自定义类加载器的核心在于对字节码文件的获取，如果是加密的字节码则需要在该类中对文件进行解密。由于这里只是演示，我并未对class文件进行加密，因此没有解密的过程。这里有几点需要注意：
1、这里传递的文件名需要是类的全限定性名称，即com.xxx.Test2格式的，因为 defineClass 方法是按这种格式进行处理的。
2、最好不要重写loadClass方法，因为这样容易破坏双亲委托模式。
3、这类Test 类本身可以被 AppClassLoader 类加载，因此我们不能把 com/xxx/test/classloading/Test2.class 放在类路径下。否则，由于双亲委托机制的存在，会直接导致该类由 AppClassLoader 加载，而不会通过我们自定义类加载器来加载。
JVM类加载方式
类加载有三种方式：
1、命令行启动应用时候由JVM初始化加载
2、通过Class.forName()方法动态加载
3、通过ClassLoader.loadClass()方法动态加载
例子
public class LoadTest
{
public static void main(String[] args) throws ClassNotFoundException
{
ClassLoader loader = Test2.class.getClassLoader();
System.out.println(loader);
//使用ClassLoader.loadClass()来加载类，不会执行初始化块
System.out.println("---使用loadClass加载---");
loader.loadClass("Test2");
//使用Class.forName()来加载类，默认会执行初始化块 //
System.out.println("---使用Class.forName()来加载类---");
Class.forName("Test2");
//使用Class.forName()来加载类，并指定ClassLoader，初始化时不执行静态块
System.out.println("---使用Class.forName()来加载类，并指定ClassLoader---");
Class.forName("Test2", false, loader);
}
}demo类
public class Test2 {
static {
System.out.println("静态初始化块执行了！");
}
}分别切换加载方式，会有不同的输出结果。
在上面的输出中，我们看到使用Class.forName()来加载类，默认会执行初始化块。
Class.forName()和ClassLoader.loadClass()区别
Class.forName()：将类的.class文件加载到jvm中之外，还会对类进行解释，执行类中的static块；
ClassLoader.loadClass()：只干一件事情，就是将.class文件加载到jvm中，不会执行static中的内容,只有在newInstance才会去执行static块。
Class.forName(name, initialize, loader)带参函数也可控制是否加载static块。并且只有调用了newInstance()方法采用调用构造函数，创建类的对象 。