JVM的Metaspace：实现类加载器隔离与卸载的内存区域划分与管理 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

JVM Metaspace：类加载器隔离与卸载的内存区域划分与管理

各位听众，大家好！今天我们来深入探讨一下JVM Metaspace，这个与类加载器隔离和卸载密切相关的内存区域。我们将从Metaspace的基本概念入手，详细剖析其内存结构、类加载器隔离机制，以及如何进行有效管理，最终实现类的卸载。

一、Metaspace：永久代的继任者

在Java 8之前，JVM使用永久代（Permanent Generation）来存储类的元数据信息，如类名、字段、方法、常量池等。然而，永久代有一个明显的缺点：其大小是固定的，难以动态调整。这容易导致OutOfMemoryError: PermGen space错误，尤其是在加载大量类或者动态生成类的场景下。

为了解决这个问题，Java 8引入了Metaspace来取代永久代。Metaspace与永久代最大的区别在于，它不再位于JVM堆内存中，而是使用本地内存（Native Memory）。这意味着Metaspace的大小只受操作系统的可用内存限制，理论上可以无限扩展，从而避免了PermGen space错误。

二、Metaspace的内存结构

Metaspace的内存结构可以简单理解为一块连续的虚拟内存空间，由多个Chunk组成。Chunk是Metaspace内存分配的基本单位，通常大小为几MB。

Chunk： 每个Chunk包含元数据和空闲空间。元数据记录了Chunk的大小、状态（是否已分配）以及指向下一个Chunk的指针。
ClassLoaderDataGraph： Metaspace为每个类加载器维护一个ClassLoaderDataGraph，用于跟踪该类加载器加载的类和相关的元数据。ClassLoaderDataGraph是类加载器隔离的关键。
Class： Java类的元数据，包括类名、字段、方法、常量池、父类信息等。这些信息存储在Metaspace中。
Method： Java方法的元数据，包括方法名、参数类型、返回类型、字节码等。
Symbol： 用于存储类名、方法名、字段名等字符串字面量。Symbol采用了String Table，减少了内存占用。

三、类加载器隔离：ClassLoaderDataGraph的功劳

类加载器隔离是Java虚拟机的重要特性之一，它允许不同的类加载器加载同名的类，而不会发生冲突。Metaspace通过ClassLoaderDataGraph实现了类加载器隔离。

每个类加载器都有一个对应的ClassLoaderDataGraph，ClassLoaderDataGraph维护着该类加载器加载的所有类的元数据信息，包括：

ClassLoaderData：记录类加载器的信息，如名称、父类加载器等。
Klass*：指向加载的类的元数据（Class对象）。
Symbol*：指向类中使用的Symbol。

当一个类加载器加载一个类时，JVM会将该类的元数据信息存储到对应ClassLoaderDataGraph中。当需要访问该类的元数据时，JVM会首先找到该类加载器对应的ClassLoaderDataGraph，然后从中查找相应的元数据。

这种隔离机制确保了不同的类加载器加载的类可以拥有独立的元数据信息，即使这些类的名称相同。这对于实现模块化和插件化非常重要。

代码示例：

public class ClassLoaderIsolation {

    public static void main(String[] args) throws Exception {
        // 创建两个类加载器
        ClassLoader classLoader1 = new MyClassLoader("ClassLoader1");
        ClassLoader classLoader2 = new MyClassLoader("ClassLoader2");

        // 使用不同的类加载器加载同一个类
        Class<?> class1 = classLoader1.loadClass("com.example.MyClass");
        Class<?> class2 = classLoader2.loadClass("com.example.MyClass");

        // 验证是否是不同的类
        System.out.println("Classloader1 class: " + class1.getClassLoader());
        System.out.println("Classloader2 class: " + class2.getClassLoader());
        System.out.println("Are the same class: " + (class1 == class2));
        System.out.println("Are the same classloader: " + (class1.getClassLoader() == class2.getClassLoader()));

        // 创建实例并调用方法
        Object instance1 = class1.getDeclaredConstructor().newInstance();
        Object instance2 = class2.getDeclaredConstructor().newInstance();

        class1.getMethod("printClassLoader").invoke(instance1);
        class2.getMethod("printClassLoader").invoke(instance2);

        // 尝试卸载类加载器
        classLoader1 = null;
        classLoader2 = null;

        System.gc(); // 触发GC，观察是否卸载
        Thread.sleep(5000); // 等待一段时间
    }

    // 自定义类加载器
    static class MyClassLoader extends ClassLoader {
        private String name;
        public MyClassLoader(String name) {
            this.name = name;
        }

        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            try {
                // 从指定位置读取类文件
                byte[] classBytes = loadClassBytes(name);
                if (classBytes != null) {
                    return defineClass(name, classBytes, 0, classBytes.length);
                }
            } catch (Exception e) {
                throw new ClassNotFoundException(name, e);
            }
            return super.findClass(name);
        }

        private byte[] loadClassBytes(String className) throws Exception{
            String classFilePath = className.replace('.', '/') + ".class";

            try (java.io.InputStream is = this.getClass().getClassLoader().getResourceAsStream(classFilePath);
                 java.io.ByteArrayOutputStream byteStream = new java.io.ByteArrayOutputStream()) {

                if (is == null) {
                    return null;
                }

                int nextValue = 0;
                while ((nextValue = is.read()) != -1) {
                    byteStream.write(nextValue);
                }
                return byteStream.toByteArray();
            }
        }

        @Override
        public String toString() {
            return name;
        }
    }

    // 假设的MyClass类，需要放在resources目录下，并编译好。
    // package com.example;
    // public class MyClass {
    //    public void printClassLoader() {
    //        System.out.println("ClassLoader: " + this.getClass().getClassLoader());
    //    }
    // }
}

MyClass.java (放在resources/com/example目录下)：

package com.example;
public class MyClass {
    public void printClassLoader() {
        System.out.println("ClassLoader: " + this.getClass().getClassLoader());
    }
}

运行步骤：

编译： 编译 MyClass.java 和 ClassLoaderIsolation.java.
放置： 将编译好的 MyClass.class 放置到项目的 resources/com/example 目录下。
运行： 运行 ClassLoaderIsolation.java。

预期输出：

Classloader1 class: ClassLoaderIsolation$MyClassLoader@63961c42
Classloader2 class: ClassLoaderIsolation$MyClassLoader@65b54a60
Are the same class: false
Are the same classloader: false
ClassLoader: ClassLoaderIsolation$MyClassLoader@63961c42
ClassLoader: ClassLoaderIsolation$MyClassLoader@65b54a60

这个例子演示了如何使用两个不同的类加载器加载同一个类，并验证它们是不同的类。每个类都属于自己的类加载器，拥有独立的元数据信息。

四、类的卸载：GC的参与

类的卸载是指将Metaspace中不再使用的类元数据信息从内存中移除。类的卸载是一个复杂的过程，需要满足以下条件：

该类的所有实例都已被回收。
加载该类的ClassLoader实例已被回收。
该类的java.lang.Class对象没有在任何地方被引用。

当以上条件都满足时，JVM才可能对该类进行卸载。类的卸载依赖于垃圾回收器（Garbage Collector, GC）。当GC发现一个类满足卸载条件时，它会将该类的元数据信息从Metaspace中移除。

卸载过程简述：

可达性分析： GC首先进行可达性分析，判断哪些对象是存活的，哪些对象是垃圾。
类卸载判断： 对于每个ClassLoaderDataGraph，GC会检查其对应的类加载器是否存活，以及该类加载器加载的类是否满足卸载条件。
元数据移除： 如果一个类满足卸载条件，GC会将该类在ClassLoaderDataGraph中的引用移除，并释放该类在Metaspace中占用的内存。
ClassLoaderDataGraph回收： 如果一个ClassLoaderDataGraph中所有的类都已被卸载，且对应的类加载器已被回收，那么该ClassLoaderDataGraph也可以被回收。

代码示例： (延续上面的ClassLoaderIsolation.java)

在上面的例子中，最后我们尝试了卸载类加载器。虽然我们设置 classLoader1 = null; 和 classLoader2 = null;，并调用了 System.gc();，但并不能保证类立刻被卸载。类的卸载是一个由GC控制的过程，通常需要多次GC才能完成。为了更好地观察卸载过程，你可以：

使用 -XX:+TraceClassUnloading JVM参数运行程序，以便在类被卸载时输出信息。
增加循环次数，创建更多实例，增加GC的压力，更有可能触发卸载。
确保没有其他地方引用了这些类加载器和类，否则无法卸载。

重点： 类的卸载是一个概率事件，受到GC策略和内存压力的影响。System.gc() 只是建议JVM进行垃圾回收，并不一定会立即执行，更不一定会卸载类。

五、Metaspace的管理与调优

Metaspace的大小可以通过以下JVM参数进行控制：

参数	说明
`-XX:MetaspaceSize`	Metaspace的初始大小，即触发GC的阈值。
`-XX:MaxMetaspaceSize`	Metaspace的最大大小，如果没有设置，则只受操作系统的可用内存限制。
`-XX:MinMetaspaceFreeRatio`	GC后，Metaspace最小的空闲比例，用于控制Metaspace的扩容。
`-XX:MaxMetaspaceFreeRatio`	GC后，Metaspace最大的空闲比例，用于控制Metaspace的收缩。
`-XX:+UseCompressedOops`	启用压缩对象指针，可以减少堆内存的占用，从而间接影响Metaspace的使用。
`-XX:+UseCompressedClassPointers`	启用压缩类指针，可以减少Metaspace的占用，建议开启。

调优建议：

设置合适的MetaspaceSize和MaxMetaspaceSize： MetaspaceSize应该根据应用的实际情况进行调整，避免频繁的GC。MaxMetaspaceSize应该设置一个合理的值，防止Metaspace无限扩展，占用过多的本地内存。
开启压缩类指针： 建议开启-XX:+UseCompressedClassPointers，可以显著减少Metaspace的占用。
监控Metaspace的使用情况： 可以使用JConsole、VisualVM等工具监控Metaspace的使用情况，及时发现问题。
避免类加载器泄漏： 类加载器泄漏是指类加载器被创建后，由于某些原因无法被回收，导致其加载的类也无法被卸载，最终导致Metaspace溢出。应该避免这种情况的发生。

六、常见问题与解决方案

OutOfMemoryError: Metaspace： 表明Metaspace空间不足。可以尝试增加MaxMetaspaceSize，或者检查是否存在类加载器泄漏。
频繁的Full GC： 可能是MetaspaceSize设置过小，导致频繁触发GC。可以尝试增加MetaspaceSize。
类卸载失败： 类的卸载受到GC策略和内存压力的影响，可能需要多次GC才能完成。可以尝试增加GC的压力，或者检查是否存在对类加载器或类的引用。

七、其他注意事项

Metaspace使用的是本地内存，而不是堆内存。这意味着Metaspace的大小只受操作系统的可用内存限制。
Metaspace的默认大小是动态调整的，JVM会根据实际情况自动调整Metaspace的大小。
Metaspace的GC是由Full GC触发的，因此应该尽量避免频繁的Full GC。
类的卸载是一个概率事件，受到GC策略和内存压力的影响。

总结

Metaspace是JVM中用于存储类元数据信息的内存区域，它取代了永久代，并使用本地内存进行存储。Metaspace通过ClassLoaderDataGraph实现类加载器隔离，并依赖GC进行类的卸载。合理配置Metaspace的大小，避免类加载器泄漏，可以有效地提高JVM的性能和稳定性。

对Metaspace的内存结构，类加载隔离与类卸载进行回顾

本文详细阐述了JVM Metaspace的内存结构，它通过ClassLoaderDataGraph实现类加载器隔离，并依赖GC进行类的卸载。了解Metaspace的原理和使用方法，有助于我们更好地理解JVM的运行机制，并进行性能调优。

JVM Metaspace：类加载器隔离与卸载的内存区域划分与管理

发表回复 取消回复

发表回复取消回复