深入理解Java虚拟机之类加载

Java 深入理解Java虚拟机
深入理解Java虚拟机系列
发布日期:   2023-06-01
文章字数:   2.7k
阅读时长:   10 分
阅读次数:  

类加载机制

类加载时机

一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，其生命周期如图所示：

image-20220124103017142

对于初始化阶段，《Java虚拟机规范》严格规定了有且只有六种情况必须立即对类进行“初始化”，以下行为称为对一个类型的主动引用：

  1. 遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类型没有进行过初始化，则需要先触发其初始化阶段
    • 使用new关键字实例化对象的时候
    • 读取和设置静态字段的时候（被final修饰及已在编译器把结果放入常量池中的静态字段除外）
    • 调用静态方法的时候
  2. 使用反射调用相应类型但其并未进行过初始化的时候
  3. 当初始化某个类，而其父类并未进行过初始化的时候，则先触发父类的初始化
  4. 当虚拟机启动的时候，会先初始化主类（即包含main()方法的那个类）
  5. 当使用JDK 7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化
  6. JDK8中，若某个接口定义了默认方法（default），则当其实现类发生初始化的时候，应先触发接口的初始化

除了主动引用之外，所有引用类型的方式都不会触发初始化，称为被动引用：

  1. 通过子类引用父类的静态字段，不会导致子类初始化
public class SuperClass {
    static {
    	System.out.println("SuperClass init!");
	}
	public static int value = 123;
}
public class SubClass extends SuperClass {
    static {
    	System.out.println("SubClass init!");
    }
}
/**
* 非主动使用类字段演示
**/
public class NotInitialization {
	public static void main(String[] args) {
		System.out.println(SubClass.value);
	}
}

输出结果：
    SuperClass init!
    123
  1. 通过数组定义来引用类，不会触发此类的初始化
public class NotInitialization {
    public static void main(String[] args) {
    	SuperClass[] sca = new SuperClass[10];
    }
}

无输出结果
  1. 常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化
public class ConstClass {
    static {
    	System.out.println("ConstClass init!");
    }
	public static final String HELLOWORLD = "hello world";
}
/**
* 非主动使用类字段演示
**/
public class NotInitialization {
    public static void main(String[] args) {
    	System.out.println(ConstClass.HELLOWORLD);
    }
}

输出结果：
    hello world

类加载过程

  1. 加载：加载二进制然后转换成JVM需要的结构，最后生成对应Class对象

    • 通过一个类的全限定名来获取定义此类的二进制字节流
    • 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
    • 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

    image-20220124155045831

  2. 验证：确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全

    image-20220124160954798

  3. 准备：准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段

    • // 此处准备阶段后初始值为0，需等到初始化阶段后才会赋值为123
public static int value = 123;

      
- ```java
  // 此处准备阶段后初始值为123
  public static final int value = 123;

  4. 解析：解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程

    符号引用：class文件中常量池的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info这几个结构所存储的字符串常量

    直接引用：能定位到所引用的真正内容

    image-20220124171344715

  5. 初始化：该阶段开始真正执行Java程序代码（初始化阶段就是执行类构造器()方法的过程）

    • <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问

      image-20220125094235856

    • 父类的()方法要先于子类的执行

      // 父类的静态语句块要先于子类的赋值操作，因此B的值应是2
static class Parent {
    public static int A = 1;
    static {
    	A = 2;
    }
}
static class Sub extends Parent {
	public static int B = A;
}
public static void main(String[] args) {
	System.out.println(Sub.B);
}

    • 当一个类中没有静态语句块，也没有变量的赋值操作时，编译器是不会为该类生成方法的

    • 接口与类又有不同，只有当父接口中定义的变量被使用时，才会触发父接口的初始化；实现类初始化时也不会执行接口的方法

    • Java虚拟机必须保证一个类的方法在多线程环境下被正确地加锁同步，否则可能会导致线程阻塞

      static class DeadLoopClass {
    static {
        // 如果不加上这个if语句，编译器将提示“Initializer must be able to complete normally” 并拒绝编译
        // 因为如果不加if，就会进入while死循环，虚拟机检查不通过；加了if后，虚拟机就只会单纯地检查if语句，而不会发现内部的死循环
        if (true) {
            System.out.println(Thread.currentThread() + "init DeadLoopClass");
            while (true) {}
        }
    }
}

public static void main(String[] args) {
    Runnable script = new Runnable() {
        public void run() {
            System.out.println(Thread.currentThread() + "start");
            DeadLoopClass dlc = new DeadLoopClass();
            System.out.println(Thread.currentThread() + " run over");
        }
    };
    Thread thread1 = new Thread(script);
    Thread thread2 = new Thread(script);
    thread1.start();
    thread2.start();
}

最终运行结果：
    Thread[Thread-0,5,main]start
	Thread[Thread-1,5,main]start
	Thread[Thread-0,5,main]init DeadLoopClass
一个线程进入了死循环，另一个线程在阻塞等待中

类加载器

类与类加载器

每一个类加载器，都有一个独立的类名称空间。若两个类来自同一个Class文件，被同一个Java虚拟机加载，但类加载器不同，那么这两个类就不相等

  • 不同类加载器对instanceof关键字的影响

    public class ClassLoaderTest {
    public static void main(String[] args) throws Exception {
        // 自定义的类加载器
        ClassLoader myLoader = new ClassLoader() {
            @Override
            public Class<?> loadClass(String name) throws ClassNotFoundException {
                try {
                    // 获取同一路径下的.class文件
                    String fileName = name.substring(name.lastIndexOf(".") + 1)+".class";
                    // 加载.class文件
                    InputStream is = getClass().getResourceAsStream(fileName);
                    if (is == null) {
                        return super.loadClass(name);
                    }
                    byte[] b = new byte[is.available()];
                    is.read(b);
                    return defineClass(name, b, 0, b.length);
                } catch (IOException e) {
                    throw new ClassNotFoundException(name);
                }
            }
        };
        // 采用自定义类加载器加载类并实例化
        Object obj = myLoader.loadClass("org.example.ClassLoaderTest").newInstance();
        System.out.println(obj.getClass());
        System.out.println(obj instanceof org.example.ClassLoaderTest);
    }
}

输出结果：
    class org.example.ClassLoaderTest // 自定义类加载器加载
	false // 一个是自定义类加载器加载，另一个是Java虚拟机默认应用程序类加载器加载，所以类型检查结果不一致

    image-20220125105928093

双亲委派模型

类加载器的双亲委派模型：

image-20220126153048590

其工作过程：

  • 类加载器收到类加载请求后会先把请求委派给父加载器完成，因此所有请求最终都会传达到最顶层的启动类加载器中；只有父加载器无法完成加载抛出异常时，子加载器才会尝试自己去完成加载
  • 目的是为了保证应用程序的稳定有序
// 双亲委派模型源码实现
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);
                }
            } catch (ClassNotFoundException e) {
                // 父加载器无法加载完成，抛出异常
            }

            if (c == null) {
                long t1 = System.nanoTime();
				// 父加载器无法完成，子加载器自己动手加载
                c = findClass(name);

                // this is the defining class loader; record the stats
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

破坏双亲委派模型

  1. 第一次破坏：

    由于双亲委派模型在JDK 1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在，因此为了兼容已有代码，做了一些妥协：即引导大家尽可能地重写java.lang.ClassLoader中的findClass()方法，而不要重写loadClass()方法

    image-20220126154642582

  2. 第二次破坏：

    由于模型自身缺陷导致，基础类基本都能够被上层加载器加载，但当基础类想要调用用户代码的时候，就会存在问题。因此引入了线程上下文类加载器（这个类加载器可以通过java.lang.Thread类的setContext-ClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器）

    以SPI为例：

    SPI全称是 Service Provider Interface，是 Java 提供的一套用来被第三方实现或者扩展的 API，它可以用来启用框架扩展和替换组件。

    简而言之，通过在 META-INF/services 目录下，创建一个以接口全限定名为命名的文件（内容为实现类的全限定名），即可自动加载这一种实现，其主要使用 java.util.ServiceLoader 类进行动态装载

    package java.util;
...
public final class ServiceLoader<S> implements Iterable<S>
{
    private static final String PREFIX = "META-INF/services/";
	...

    ServiceLoader是由启动类加载器加载的，但加载它的同时还需要加载具体的类方法实现，而类方法实现在应用代码，由应用程序类加载器加载，故出现了反向双亲委派的情况

    image-20220126171854523

  3. 第三次破坏：

    由于用户对程序动态性的追求而导致的，即热更新，热部署等。出现了OSGi，其自定义了类加载器机制的实现，不再是双亲委派模型的树形结构，而是更加复杂的网状结构

Java 深入理解Java虚拟机
赏
评论
  目录