JVM(二)Java8内存划分

一、永久代

在说java8内存模型之前先说一下永久代的概念。

在Java虚拟机(JVM)内部，class文件中包括类的版本、字段、方法、接口等描述信息，还有运行时常量池，用于存放编译器生成的各种字面量和符号引用。
在过去类大多是”static”的，很少被卸载或收集，因此被称为“永久的(Permanent)”。同时，由于类class是JVM实现的一部分，并不是由应用创建的，所以又被认为是“非堆(non-heap)”内存。

在JDK8之前的HotSpot JVM，存放这些”永久的”的区域叫做“永久代(permanent generation)”。永久代是一片连续的堆空间，在JVM启动之前通过在命令行设置参数-XX:MaxPermSize来设定永久代最大可分配的内存空间，默认大小是64M（64位JVM由于指针膨胀，默认是85M）。永久代的垃圾收集是和老年代(old generation)捆绑在一起的，因此无论谁满了，都会触发永久代和老年代的垃圾收集。不过，一个明显的问题是，当JVM加载的类信息容量超过了参数-XX：MaxPermSize设定的值时，应用将会报OOM的错误

二、jdk1.7与jdk1.8内存变化

那jdk1.7 与jdk1.8内存比有什么变化呢？先看一段代码在说结论。

package demo.com.test.jvm;

import java.util.ArrayList;
import java.util.List;

public class PermTest {
    // -XX:PermSize=4m -XX:MaxPermSize=4m -Xmx=8m 运行时改一下jvm参数
    static String base = "StringPool";
    public static void main(String[] args) {
        List<String> list = new ArrayList<String>();
        for (int i = 0; i < Integer.MAX_VALUE; i++) {
            String str = base + base;
            base = str;
            list.add(str.intern());
        }
    }
}

此段代码在jdk1.7上运行时 报如下错误

Exception in thread “main” java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2367)
at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130)
at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:415)
at java.lang.StringBuilder.append(StringBuilder.java:132)
at demo.com.test.jvm.PermTest.main(PermTest.java:11)

此段代码在jdk1.8上运行时 报如下错误

Exception in thread “main” java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2367)
at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130)
at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:415)
at java.lang.StringBuilder.append(StringBuilder.java:132)
at demo.com.test.jvm.PermTest.main(PermTest.java:11)

我们发现竟然没有报 java.lang.OutOfMemoryError ：PermGen space
那么可以大致得出 JDK 1.7 和 1.8 将字符串常量池由永久代转移到堆中，并且 JDK 1.8 中已经不存在永久代的结论。

接下来我们在jdk1.8下继续运行一段代码。

package demo.com.test.jvm;

import java.io.File;
import java.net.URL;
import java.net.URLClassLoader;
import java.util.ArrayList;
import java.util.List;

public class PermTest2 {
    public static void main(String[] args) {
        // -XX:PermSize=4m -XX:MaxPermSize=4m -Xmx=8m 运行时改一下jvm参数
        URL url = null;
        List<ClassLoader> classLoaderList = new ArrayList<ClassLoader>();
        try {
            url = new File("C:\\Users\\lenovo\\Desktop\\blok").toURI().toURL();
            URL[] urls = { url };
            while (true) {
                ClassLoader loader = new URLClassLoader(urls);
                classLoaderList.add(loader);
                loader.loadClass("demo.com.test.jvm.PermTest2");
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

本例中使用的 JDK 版本是 1.8，指定的 PermGen 区的大小为 4M。通过每次生成不同URLClassLoader对象来加载PermTest2类，从而生成不同的类对象，运行一段时间发现没有报”java.lang.OutOfMemoryError: PermGen space ” 异常。同时发现本地的内存直线上升。如下图

此时我们也可以得出一个结论在jdk1.8中没有永久代的概念，并且存放类相关信息的地方也不在heap（堆）中。那这部分在那里呢 ? 在元空间里。

三、Metaspace（元空间）

3.1 metaspace的组成

metaspace其实由两大部分组成
● Klass Metaspace
● NoKlass Metaspace

Klass Metaspace就是用来存klass的，klass是我们熟知的class文件在jvm里的运行时数据结构，不过有点要提的是我们看到的类似A.class其实是存在heap里的，是java.lang.Class的一个对象实例。这块内存是紧接着Heap的，和我们之前的perm一样，这块内存大小可通过-XX:CompressedClassSpaceSize参数来控制，这个参数前面提到了默认是1G，但是这块内存也可以没有，假如没有开启压缩指针就不会有这块内存，这种情况下klass都会存在NoKlass Metaspace里，另外如果我们把-Xmx设置大于32G的话，其实也是没有这块内存的，因为会这么大内存会关闭压缩指针开关。还有就是这块内存最多只会存在一块。

NoKlass Metaspace专门来存klass相关的其他的内容，比如method，constantPool（常量池）等，这块内存是由多块内存组合起来的，所以可以认为是不连续的内存块组成的。这块内存是必须的，虽然叫做NoKlass Metaspace，但是也其实可以存klass的内容，上面已经提到了对应场景。

Klass Metaspace和NoKlass Mestaspace都是所有classloader共享的，所以类加载器们要分配内存，但是每个类加载器都有一个SpaceManager，来管理属于这个类加载的内存小块。如果Klass Metaspace用完了，那就会OOM了，不过一般情况下不会，NoKlass Mestaspace是由一块块内存慢慢组合起来的，在没有达到限制条件的情况下，会不断加长这条链，让它可以持续工作。

3.2 metaspace主要相关参数

• UseLargePagesInMetaspace
• InitialBootClassLoaderMetaspaceSize
• MetaspaceSize
• MaxMetaspaceSize
• CompressedClassSpaceSize
• MinMetaspaceExpansion
• MaxMetaspaceExpansion
• MinMetaspaceFreeRatio
• MaxMetaspaceFreeRatio

下面介绍一下常用的几个

• MetaspaceSize

默认20.8M左右(x86下开启c2模式)，主要是控制metaspaceGC发生的初始阈值，也是最小阈值。

• MaxMetaspaceSize

默认基本是无穷大，但是我还是建议大家设置这个参数，因为很可能会因为没有限制而导致metaspace被无止境使用(一般是内存泄漏)而被OS Kill。这个参数会限制metaspace被committed的内存大小，会保证committed的内存不会超过这个值，一旦超过就会触发GC，这里要注意和MaxPermSize的区别，MaxMetaspaceSize并不会在jvm启动的时候分配一块这么大的内存出来，而MaxPermSize是会分配一块这么大的内存的。

• MinMetaspaceFreeRatio

MinMetaspaceFreeRatio和下面的MaxMetaspaceFreeRatio，主要是影响触发metaspaceGC的阈值默认40

• MaxMetaspaceFreeRatio

默认70，这个参数和上面的参数基本是相反的，是为了避免触发metaspaceGC的阈值过大，而想对这个值进行缩小。

3.3 Metaspace的内存分配与管理

Metaspace VM利用内存管理技术来管理Metaspace。这使得由不同的垃圾收集器来处理类元数据的工作，现在仅仅由Metaspace VM在Metaspace中通过C++来进行管理。Metaspace背后的一个思想是，类和它的元数据的生命周期是和它的类加载器的生命周期一致的。也就是说，只要类的类加载器是存活的，在Metaspace中的类元数据也是存活的，不能被释放。

每个类加载器存储区叫做“a metaspace”。这些metaspaces一起总体称为”the Metaspace”。仅仅当类加载器不在存活，被垃圾收集器声明死亡后，该类加载器对应的metaspace空间才可以回收。Metaspace空间没有迁移和压缩。但是元数据会被扫描是否存在Java引用。

Metaspace VM使用一个块分配器(chunking allocator)来管理Metaspace空间的内存分配。块的大小依赖于类加载器的类型。其中有一个全局的可使用的块列表（a global free list of chunks）。当类加载器需要一个块的时候，类加载器从全局块列表中取出一个块，添加到它自己维护的块列表中。当类加载器死亡，它的块将会被释放，归还给全局的块列表。块（chunk）会进一步被划分成blocks,每个block存储一个元数据单元(a unit of metadata)。Chunk中Blocks的分配线性的（pointer bump）。这些chunks被分配在内存映射空间(memory mapped(mmapped) spaces)之外。在一个全局的虚拟内存映射空间（global virtual mmapped spaces）的链表，当任何虚拟空间变为空时，就将该虚拟空间归还回操作系统。

3.4 Metaspace VM内存碎片问题

先前提到的，Metaspace VM使用块分配器(chunking allocator)。chunk的大小取决于类加载器的类型。由于类class并没有一个固定的尺寸，这就存在这样一种可能：可分配的chunk的尺寸和需要的chunk的尺寸不相等，这就会导致内存碎片。Metaspace VM还没有使用压缩技术，所以内存碎片是现在的一个主要关注的问题。

3.5 参数应用

改变一下jvm参数 -XX:MaxMetaspaceSize=4m -XX:MetaspaceSize=4m
在次运行 PermTest2 类 会发现，程序会报异常，说明参数有效。
D:>java -XX:MaxMetaspaceSize=4m -XX:MetaspaceSize=4m PermTest2
Error occurred during initialization of VM
OutOfMemoryError: Metaspace

四、总结

其实，移除永久代的工作从JDK1.7就开始了。JDK1.7中，存储在永久代的部分数据就已经转移到了Java Heap或者是 Native Heap。但永久代仍存在于JDK1.7中，并没完全移除，譬如符号引用(Symbols)转移到了native heap；字面量(interned strings)转移到了java heap；类的静态变量(class statics)转移到了java heap。
元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过参数来指定元空间的大小。

为什么要将永久代替换成Metaspace？可能的原因有：
　　1、字符串存在永久代中，容易出现性能问题和内存溢出。
　　2、类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。
　　3、永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。
　　4、Oracle 可能会将HotSpot 与 JRockit 合二为一。

五、java8内存模型图

六、应该掌握的知识

1.在 JDK 1.7 和 1.8 中将字符串常量池由永久代转移到堆中

2.存放类相关信息的地方也不在heap（堆）中。在元空间里。

3.在jdk1.8中没有永久代的概念，

4.metaspace其实由两大部分组成

● Klass Metaspace
存放klass的，klass是我们熟知的class文件在jvm里的运行时数据结构，这个空间的默认大小是1G

● NoKlass Metaspace
专门来存klass相关的其他的内容，比如method，constantPool（常量池）等，这块内存是由多块内存组合起来的，所以可以认为是不连续的内存块组成的。这块内存是必须的

● Klass Metaspace和NoKlass Mestaspace都是所有classloader共享的，所以类加载器们要分配内存，但是每个类加载器都有一个SpaceManager，来管理属于这个类加载的内存小块。如果Klass Metaspace用完了，那就会OOM了，不过一般情况下不会，NoKlass Mestaspace是由一块块内存慢慢组合起来的，在没有达到限制条件的情况下，会不断加长这条链，让它可以持续工作。

5.metaspace主要相关参数

-XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。

-XX:MaxMetaspaceSize，最大空间，默认是没有限制的。

-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集

-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集

6 Metaspace的内存分配与管理 都应该清楚

7为什么要将永久代替换成Metaspace？

• 1、字符串存在永久代中，容易出现性能问题和内存溢出。
• 2、类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困
  难，太小容易出现永久代溢出，太大则容易导致老年代溢出。
• 3、永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。
• 4、Oracle 可能会将HotSpot 与 JRockit 合二为一。

七、参考

http://lovestblog.cn/blog/2016/10/29/metaspace/
http://www.cnblogs.com/paddix/p/5309550.html