首页 > 代码库 > JVM加载类的过程,双亲委派机制中的方法
JVM加载类的过程,双亲委派机制中的方法
JVM加载类的过程:
1)JVM中类的整个生命周期:
加载＝》验证＝》准备＝》解析＝》初始化＝》使用＝》卸载
1.1、加载
类的加载阶段，主要是获取定义此类的二进制字节流，并将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构，最后在Java堆中生成一个代表这个类的java.lang.Class对象作为方法区这些数据的访问入口。相对于类加载过程的其他阶段，加载阶段是开发期可控性最强的阶段。我们可以通过定制不通的类加载器，也就是ClassLoader来控制二进制字节流的获取方式。
1.2、验证
验证，准备和解析其实都属于连接阶段，而验证就是连接阶段的第一步。这一阶段主要是为了确保Class文件的字节流中包含的信息复合当前虚拟机的要求，并且不会危害虚拟机自身的安全。主要验证过程包括：文件格式验证，元数据验证，字节码验证以及符号引用验证。
1.3、准备
准备阶段正式为类变量分配内存并设置初始值。这里的初始值并不是初始化的值，而是数据类型的默认零值。这里提到的类变量是被static修饰的变量，而不是实例变量。关于准备阶段为类变量设置零值的唯一例外就是当这个类变量同时也被final修饰，那么在编译时，就会直接为这个常量赋上目标值。
1.4、解析
解析时虚拟机将常量池中的符号引用替换为直接引用的过程。
1.5、初始化
在准备阶段，变量已经赋过一次系统要求的初始值，在初始化阶段，则是根据程序员通过程序的主观计划区初始化类变量和其他资源。Java虚拟机规范规定了有4种情况必须立即对类进行初始化（加载，验证，准备必须在此之前完成）
1）当使用new关键字实例化对象时，当读取或者设置一个类的静态字段（被final修饰的除外）时，以及当调用一个类的静态方法时，如果类未初始化，则需先初始化。
2）通过反射机制对类进行调用时，如果类未初始化，则需先初始化。
3）当初始化一个类时，如果其父类未初始化，先初始化父类。
4）用户指定的执行主类（含main方法的那个类）在虚拟机启动时会先被初始化。
除了上面这4种方式，所有引用类的方式都不会触发初始化，称为被动引用。如：通过子类引用父类的静态字段，不会导致子类初始化；通过数组定义来引用类，不会触发此类的初始化；引用类的静态常量不会触发定义常量的类的初始化，因为常量在编译阶段已经被放到常量池中了。
* 以上过程当中，验证，准备和解析完全由Java虚拟机主导和控制。只有加载阶段和初始化阶段程序员可以进行控制。在加载阶段可以通过实现自定义的ClassLoader来加载类的二进制流，在初始化阶段程序员则可完全按照需求来为类变量赋值
2)执行java XXX.class的过程
找到JRE——》找到jvm.dll——》启动JVM并进行初始化——》产生Bootstrap Loader——》载入ExtClassLoader——》载入AppClassLoader——》执行java XXX.class
双亲委派机制:
通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。
双亲委派机制模型中方法:
1、启动类加载器，负责将存放在<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即时放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被java程序直接引用。
2、扩展类加载器：负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用该类加载器。
3、应用程序类加载器：负责加载用户路径上所指定的类库，开发者可以直接使用这个类加载器，也是默认的类加载器。
三种加载器的关系：启动类加载器->扩展类加载器->应用程序类加载器->自定义类加载器。
这种关系即为类加载器的双亲委派模型。其要求除启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不以继承关系实现，而是用组合的方式来复用父类的代码。
双亲委派模型的工作过程：如果一个类加载器接收到了类加载的请求，它首先把这个请求委托给他的父类加载器去完成，每个层次的类加载器都是如此，因此所有的加载请求都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它在搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
好处：java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar中，无论哪个类加载器要加载这个类，最终都会委派给启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果用户自己写了一个名为java.lang.Object的类，并放在程序的Classpath中，那系统中将会出现多个不同的Object类，java类型体系中最基础的行为也无法保证，应用程序也会变得一片混乱。
实现：在java.lang.ClassLoader的loadClass()方法中，先检查是否已经被加载过，若没有加载则调用父类加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父加载失败，则抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。
protected synchronized Class<?> loadClass(String name,boolean resolve)throws ClassNotFoundException{
//check the class has been loaded or not
Class c = findLoadedClass(name);
if(c == null){
try{
if(parent != null){
c = parent.loadClass(name,false);
}else{
c = findBootstrapClassOrNull(name);
}
}catch(ClassNotFoundException e){
//if throws the exception ,the father can not complete the load
}
if(c == null){
c = findClass(name);
}
}
if(resolve){
resolveClass(c);
}
return c;
}
JVM加载类的过程,双亲委派机制中的方法