《深刻理解Java虚拟机》读书笔记六

时间 2019-11-11

标签深刻理解Java虚拟机读书笔记栏目 Java 繁體版

原文原文链接

第七章虚拟机类加载机制
html

一、类加载的时机java

虚拟机的类加载机制：程序员

虚拟机把描述类的数据从class文件中加载到内存，并对数据进行校验、转换解析和初始化，最终造成了能够被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
类从被加载到虚拟机内存中开始到卸载出内存为止，他的整个生命周期包括加载、验证、准备、解析、初始化、使用和卸载七个阶段。
加载、验证、准备、初始化和卸载这5个阶段的顺序是肯定的，类加载过程必须按照这种顺序循序渐进的开始。而解析阶段不必定在某种状况下，能够在初始化阶段以后再开始，这是为了支持Java运行时绑定。

类初始化的五种状况：数组

遇到new、getstatic、putstatic和invokestatic这4条指令时，若是类没有初始化时，则须要先触发其初始化。生成这4条指令的最多见Java代码场景是：使用new关键字实例化对象、读取或设置一个类的静态字段(被final修饰、已在编译期把结果放入常量池的静态字段除外)，以及调用一个类的静态方法。
使用java.lang.reflect包的方法对类进行反射调用时候。
当初始化一个类时，发现其父类没有进行初始化，则需先触发其父类的初始化。
当虚拟机启动时，用户须要制定一个要执行的主类（包含main()方法的那个类），当前类须要先初始化
当使用JDK1.7的动态语言支持时，若是一个java.lang.invoke.MethodHandle实例最后的解析结果REF_putStatic、REF_getStatic、REF_invokeStatic的方法句柄，而且此方法句柄所对应的类没有进行初始化时，须要初始化该类。

被动引用：安全

这五种状况被称为对一个类的主动引用，除此以外全部的引用类的方式都不会触发初始化，称为被动引用。

经过子类引用父类的静态字段不会致使初始化。对于静态变量只有直接定义这个类的字段才会被初始化所以经过子类来引用父类中定义的静态变量不会致使子类的初始化。

父类：数据结构

package com.ecut.classload;

public class SuperClass{
    static {
        System.out.println("super init!");
    }

    static int value = 1;
}

子类：多线程

package com.ecut.classload; public class SubClass extends SuperClass{ static { System.out.println("sub init!"); } }

package com.ecut.classload;

/**
 * 经过子类引用父类的静态字段，不会致使初始化
 */
public class NotInitialization1 {
    public static void main(String[] args) {
        System.out.println(SubClass.value);
    }
}

运行结果以下：jvm

........
[Loaded com.ecut.classload.SuperClass from file:/D:/code/java/jvm-test/out/production/jvm-test/]
[Loaded com.ecut.classload.SubClass from file:/D:/code/java/jvm-test/out/production/jvm-test/]
super init!
1
.......

经过数组定义来引用类，不会触发此类的初始化

package com.ecut.classload;

/**
 * 经过数组定义来引用类，不会触发此类的初始化
 * -XX:+TraceClassLoading 
 */
public class NotInitializatio2 {
    public static void main(String[] args) {
        SuperClass[] superClasses  = new SuperClass[10];
    }
}

运行结果以下：ide

.......
[Loaded java.net.Proxy$Type from C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar]
[Loaded com.ecut.classload.SuperClass from file:/D:/code/java/jvm-test/out/production/jvm-test/]
[Loaded java.util.ArrayList$Itr from C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar]
[Loaded sun.net.NetHooks from C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar]
[Loaded java.net.Inet6Address$Inet6AddressHolder from C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar]
[Loaded java.lang.Shutdown from C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar]
[Loaded java.lang.Shutdown$Lock from C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar]
........

常量在编译阶段会存入调用类的常量池中，本质上并无直接引用到定义的常量的类，所以不会触发定义常量的类初始化。

常量类：测试

package com.ecut.classload;

public class ConstClass {

    public static final String HELLOWORD = "hello world";

    static  {
        System.out.println("const init !");
    }
}

测试类：

package com.ecut.classload;

/**
 * 常量在编译阶段会存入调用类的常量池中，本质上并无直接引用到定义的常量的类，所以不会触发定义常量的类初始化
 */
public class NotInitializatio3 {
    public static void main(String[] args) {
        System.out.println(ConstClass.HELLOWORD);
    }
}

虽然在源码中引用了ConstClass类中的常量但其实在编译阶段已将此常量值存储在了main方法所在的常量池中，对常量的引用装换成了对自身常量池的引用。

接口在初始化的时候并不要求其父接口所有要完成初始化，只要在真正使用到的时候才会初始化。

二、类加载的过程

加载：

经过一个类的全局限定名获取定义此类的二进制字节流（将字节码文件( .class ) 读入到 JVM 所管理的内存中）。
将这个字节流锁表明的静态存储结构转换为方法区的运行时数据结构。
在内存中生成一个表明这个类的java.lang.class对象，做为方法区这个类的各类数据的访问入口。

验证：

验证的目的是确保class文件的字节流中包含的信息符合当虚拟机的要求，而且不危害虚拟机自身安全。
验证从总体上来看虚拟机的验证阶段大体能够分为四个阶段的检验工做，文件格式验证，元数据验证，字节码验证，符号引用验证。
文件格式验证，保证输入的字节流能正确的被解析并存储到方法区，这阶段的验证是基于二进制字节流进行的，只有经过了这个阶段的验证，字节流才会进入方法区中进行存储。文件格式验证例子，是不是魔数0xCAFEBABE开头，主次版本号是否在当前虚拟机处理范围以内，常量池的常量中是否有被支持的常量类型。
元数据验证，对字节描述信息进行语义分析，以保证其描述的信息符合Java语言规范的要求，目的是对类的元数据信息进行语义分析校验，保证不存在不符合Java语言规范的元数据信息，是对元数据中的数据类型作校验。元数据验证的例子，这个类是否有父类（除了object类都有父类），这个类是否继承了被final修饰的类。
字节码验证，目的是经过数据流和控制流分析肯定程序语义是否合法符合逻辑，对类的方法进行验证。字节码验证例子，保证跳转指令不会跳转到方法之外的字节码指令上，保证方法体类型转换时有效。
符号引用验证，发生在将符号引用转换成字节引用的时候，这个转换动做将在解析的时候发生，符号引用是对常量池中各类符号引用的信息进行匹配验证。目的是为了解析的过程能够正常进行。

准备：

准备阶段是正式为类变量分配内存并设置类变量初始化值的阶段，这些变量所使用的内存都将在方法区中进行分配。
这个时候进行内存分配的变量仅包括类变量，这里的初始值一般是数据类型的零值，除了final修饰的变量初始化值为所给定的值。

解析：

是虚拟机将常量池中符号引用替换为直接引用的过程。解析动做主要是针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符类符号引用进行。
符号引用以一组符号来描述所引用的目标，符号能够是任何形式的字面量，但各类虚拟机能接受的符号引用是一致的。
直接引用能够直接指向目标的指针，相对偏移量或是一个能间接定位到的句柄（对象的访问定位有两种，使用句柄的访问方式和使用直接指针访问）

初始化：

初始化阶段，根据程序员经过程序制定的主观计划去初始化类变量和其余资源。初始化过程是执行类构造器<client>()方法的过程。
编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块以前的变量，而定义在它以后的变量，在前面的静态语句块能够赋值，但不能访问。
在<client>()方法执行以前，父类的<client>()方法已经执行完毕，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操做。
虚拟机会保证一个类的<client>()方法在多线程环境中被正确的加锁、同步，若是多个线程去初始化一个类，那么只会有一个线程去执行这个类的<client>()方法，其余线程都须要阻塞等待。

三、类加载器

类与类加载器：

虚拟机团队把类加载阶段中的经过类的全限定名获取描述此类的二进制字节流的动做放在Java虚拟机以外来实现，以便让应用程序本身决定如何去获取所需类。这个实现代码模块称为类加载器。

只有两个类是有同一个类加载器，加载的前提下是有意义不然即便来源于同一个class文件被同一个虚拟机加载只要加载他们的类加载器不一样，那这个类一定不相等。

package com.ecut.classload;

import java.io.IOException;
import java.io.InputStream;

public class ClassLoaderTest {
    public static void main(String[] args) throws ClassNotFoundException, IllegalAccessException, InstantiationException {
        ClassLoader myClassLoder = new ClassLoader() {
            @Override
            public Class<?> loadClass(String name) throws ClassNotFoundException {
                try {
                    String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";
                    InputStream is = getClass().getResourceAsStream(fileName);
                    if (is == null) {
                        return super.loadClass(name);
                    }

                    byte[] b = new byte[is.available()];
                    is.read(b);
                    return this.defineClass(name, b, 0, b.length);
                } catch (IOException e) {
                    throw new ClassNotFoundException(name);
                }
            }
        };

        Object object = myClassLoder.loadClass("com.ecut.classload.ClassLoaderTest").newInstance();
        System.out.println(object instanceof  com.ecut.classload.ClassLoaderTest);
    }
}

运行结果以下：

false

类加载器的分类：

启动类加载器（根加载器，Bootstrap ClassLoader）：由C++语言实现（针对HotSpot）,负责将存放在<JAVA_HOME>\lib目录或-Xbootclasspath参数指定的路径中的类库加载到内存中。
扩展类加载器（Extension ClassLoader）：负责加载<JAVA_HOME>\lib\ext目录或java.ext.dirs系统变量指定的路径中的全部类库。
应用程序类加载器（系统类加载器，Application ClassLoader）。负责加载用户类路径（classpath）上的指定类库，咱们能够直接使用这个类加载器。通常状况，若是咱们没有自定义类加载器默认就是用这个加载器。

双亲委派模型：

双亲委派模型要求除了顶层的启动类加载器外，其他的类加载器都应当有本身的父类加载器。
工做过程是若是一个类加载器收到类加载的请求，先不会本身去尝试加载这个类，而是把这个请求委派个父类加载器，每个层级都是这样，所以全部的加载请求最终都会送至顶层启动类中，只有父类加载器没法完成这个请求，才会由子加载器尝试去加载。
做用：对于任意一个类，都须要由加载它的类加载器和这个类自己一同确立其在虚拟机中的惟一性，每个类加载器，都拥有一个独立的类名称空间。类随着它的类加载器一块儿具有了一种带有优先级的层次关系。不管哪一个一个类加载器加载object类都由根加载器完成，所以object在程序中各种加载器环境都是同一个类。

双亲委派机制的是实现原理：

public Class<?> loadClass(String name) throws ClassNotFoundException {
        return loadClass(name, false);
    }
    
    protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // 首先，检查类是否已经加载。
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        c = parent.loadClass(name, false);//看父类加载器有没有加载该类（父委托机制）
                    } else {
                        c = findBootstrapClassOrNull(name);//父类加载器为空，看根加载器（Bootstrap Loader）有没有加载
                    }
                } catch (ClassNotFoundException e) {

                    //若是类没有发现抛出ClassNotFoundException 
                }

                if (c == null) {
                    //若是仍然没有找到，而后调用findClass为了找到类。 
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // 这是定义类装入器；记录统计数据
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }
    
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
    }

先检查是否被加载过，若没有被加载过调用父类的loadclass方法，若父加载器为空则默认使用启动类加载器为父加载器，若是父加载器加载失败就抛出ClassNotFoundException ，再调用本身的findClass方法进行加载。

破坏双亲委派机制模型：

第一次破坏：因为双亲委派模型是在JDK1.2以后才被引入的，而类加载器和抽象类java.lang.ClassLoader则在JDK1.0时代就已经存在，为了向前兼容若是父加载器加载失败就抛出ClassNotFoundException ，再调用本身的findClass方法进行加载。这样就能够保证新写出来的类加载器符合双亲委派规则的。
第二次破坏：这个模型自身的缺陷所致使的，基础类没法调用用户的代码。为了解决这个困境，Java设计团队只好引入了一个不太优雅的设计：线程上下文件类加载器(Thread Context ClassLoader)。
第三次破坏：因为用户对程序的动态性的追求致使的，例如OSGi的出现。在OSGi环境下，类加载器再也不是双亲委派模型中的树状结构，而是进一步发展为网状结构。

转载请于明显处标明出处

http://www.javashuo.com/article/p-kclxzdac-p.html