JVM入个门（1）

JVM

什么是JVM

JVM全称Java Virtual Machine，Java虚拟机是运行在操作系统之上的，不与硬件直接交互，中间由操作系统帮我们完成和硬件的交互工作

JVM的体系结构

要了解JAVA文件如何被执行，先要了解整个JVM的体系结构如下所示

黄色区域：表示所有线程共享，存在垃圾回收。

灰色区域：表示线程私有，内存占用较少。

类加载器

什么是类加载器

类加载器就是将编译之后的class字节码文件加载到内存中，并将这些内存转换为方法区中的运行时数据结构，注意类加载器只负责class文件的加载，至于是否可以运行需要由Execution Engin决定。

如下所示，一个Car.class二进制文件，通过类加载器初始化一个类模板，后面通过这个类模板来实例化得到各个car实例对象。

类加载器的类型

类加载器分为四种，根加载器、扩展类加载器、应用类加载器、自定义加载器，那么这四种加载器有什么关系呢？

public static void main(String[] args) {
    Car car = new Car("奇瑞QQ");
    Class<? extends Car> carClass = car.getClass();

    // 获取class的加载器 sun.misc.Launcher$AppClassLoader@18b4aac2
    System.out.println(carClass.getClassLoader());

    // 获取当前class类加载器的父加载器 sun.misc.Launcher$ExtClassLoader@7ef20235
    System.out.println(carClass.getClassLoader().getParent());

    // 获取当前class类的加载器的父加载器的父加载器 null
    System.out.println(carClass.getClassLoader().getParent().getParent());
}

从上述代码可以得出，Car类的加载器是应用类加载器，而父加载器是扩展类加载器，而扩展类加载器的父加载器是null，null是不是证明没有这个加载器呢？其实不是，这个null证明是根加载器，其实现语言是C/C++，JVM不允许程序员获取该类，所以才是null。

自定义类加载器

为什么需要自定义类加载器

系统自带的类加载器有三种应用类加载器、扩展类加载器、根加载器应该来说能满足日常开发需求了，为什么还需要自定义类加载器呢？可能有如下场景使用

• 一些公司的核心类库的字节码可能通过了加密，那么就需要自定义加载器去将加密后的字节码解密，然后加载到内存。

• 字节码文件可能来自网络、数据库、硬盘等场景需要自定义类加载器去加载字节码文件。

• 可以解决项目多模块之间的依赖版本冲突。

那么自定义类加载器如何使用呢？

核心思想就是两步

• 继承ClassLoader类

• 重写findClass方法

public class CustomClassLoader extends ClassLoader {
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        try {
            // 指定类加载路径 name是具体的类的全限定类名
            String cname = "E:\\ideaProject\\demo\\src\\main\\java\\" + name.replace('.', '/') + ".class";
            // 获取class类的所有字节数组
            byte[] classBytes = Files.readAllBytes(Paths.get(cname));
            Class<?> cl = defineClass(name, classBytes, 0, classBytes.length);
            if (cl == null) {
                throw new ClassNotFoundException(name);
            }
            return cl;
        } catch (IOException e) {
            System.out.print(e);
            throw new ClassNotFoundException(name);
        }
    }
}

随便实现一个加载类

public class Car {
    private String name;

    public Car(String name) {
        this.name = name;
    }

    public void getCar(){
        System.out.println("Car is Name "+getName());
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

在Car类的文件夹执行javac Car.java命令，手动编译，生成Car.class文件后，删除Car.java文件保留Car.class文件，这样做的目的是防止应用加载器加载到Car类。

编写类加载器调用类

public class ClassLoaderTest {
    public static void main(String[] args) {
        try {
            ClassLoader loader = new CustomClassLoader();
            // 加载Car类
            // 当其它加载器无法加载到该类，会调用自定义加载器的findClass方法
            Class<?> c = loader.loadClass("com.example.demo.testjvm.Car");
            System.out.println("类加载器==="+c.getClassLoader());
            // 反射执行方法
            // 构造器有参数这里构造
            Constructor<?> constructor = c.getDeclaredConstructor(String.class);
            // 构造对象
            Object o = constructor.newInstance("宝马");
            Method m = c.getMethod("getCar");
            m.invoke(o);
        } catch (Throwable e) {
            System.out.println(e);
        }
    }
}

执行结果

双亲委派机制

上面自定义类加载器，在加载类时调用了loadClass方法，我们可以看看这个方法的具体实现

// ClassLoader类的loadClass方法
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 {
                    // 递归出口
                    // 如果parent是null代表是根加载器，相当于所有的类都会找到根加载器尝试加载
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
            }
   // 如果父加载器加载失败，那么当前加载器尝试加载（扩展类加载器、应用类加载器、自定义加载器）
            if (c == null) {
                // 如果一直没有找到该类那么按顺序调用当前加载器的findClass方法
                // to find the class.
                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;
    }
}

从上面的代码可以看出，当一个加载器收到类加载请求后，并不会自己去加载这个类，而是将这个类委派给父类去完成，每个层次类加载器都是这样，因此所有的类加载请求都会经过根加载器，只有当父加载器无法完成这个类的加载时，当前加载器才会自己尝试加载，这就是双亲委派机制，总结下来就是向上委派、向下执行。

为什么需要这么做呢？就是为了保证安全，如下举例，我们知道根加载器是加载rt.jar里面的类，里面加载了String、Object等等这些jdk自带的类，如果我们在代码里面定义了相同包名的String类是否能让根加载器加载器自定义的String类呢？

// 定义相同的包名
package java.lang;

// 定义相同的类名
public class String {
    public String toString() {
        return "hello";
    }

    public static void main(String[] args) {
        // 这里调用的是自身的String类
        String str = new String();
        str.toString();
    }
}

执行结果

这就是采用双亲委派机制原理，当应用类加载器收到这个类的加载请求时，向上委托顺序就是

应用类加载器—>扩展类加载器---->根加载器

根加载器在尝试加载这个类时，发现存在同包同名的String类，所以根加载器加载成功，加载的还是rt.jar中的String类，这样做的好处就是所有jvm运行重要的类其它加载器没有机会再去加载，在一定程度上可以避免危险代码的植入。