Java8内存模型（关于永久区、元数据Metaspace、老年代、新生代）

一、JVM 内存模型

根据 JVM 规范，JVM 内存共分为虚拟机栈、堆、方法区、程序计数器、本地方法栈五个部分。

　1、虚拟机栈：每个线程有一个私有的栈，随着线程的创建而创建。栈里面存着的是一种叫“栈帧”的东西，每个方法会创建一个栈帧，栈帧中存放了局部变量表（基本数据类型和对象引用）、操作数栈、方法出口等信息。栈的大小可以固定也可以动态扩展。当栈调用深度大于JVM所允许的范围，会抛出StackOverflowError的错误，不过这个深度范围不是一个恒定的值，我们通过下面这段程序可以测试一下这个结果：

栈溢出测试源码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

package com.paddx.test.memory;   public class StackErrorMock {     private static int index = 1;       public void call(){         index++;         call();     }       public static void main(String[] args) {         StackErrorMock mock = new StackErrorMock();         try {             mock.call();         }catch (Throwable e){             System.out.println("Stack deep : "+index);             e.printStackTrace();         }     } }

代码段 1

运行三次，可以看出每次栈的深度都是不一样的，输出结果如下。

至于红色框里的值是怎么出来的，就需要深入到 JVM 的源码中才能探讨，这里不作详细阐述。

虚拟机栈除了上述错误外，还有另一种错误，那就是当申请不到空间时，会抛出 OutOfMemoryError。这里有一个小细节需要注意，catch 捕获的是 Throwable，而不是 Exception。因为 StackOverflowError 和 OutOfMemoryError 都不属于 Exception 的子类。

2、本地方法栈：

　　这部分主要与虚拟机用到的 Native 方法相关，一般情况下， Java 应用程序员并不需要关心这部分的内容。

3、程序计数器（PC 寄存器）：

　　PC 寄存器，也叫程序计数器。JVM支持多个线程同时运行，每个线程都有自己的程序计数器。倘若当前执行的是 JVM 的方法，则该寄存器中保存当前执行指令的地址；倘若执行的是native 方法，则PC寄存器中为空。

程序执行时，PC的初值为程序第一条指令的地址，在顺序执行程序时，控制器首先按程序计数器所指出的指令地址从内存中取出一条指令，然后分析和执行该指令，同时将PC的值加1指向下一条要执行的指令。

4、堆

　　堆内存是 JVM 所有线程共享的部分，在虚拟机启动的时候就已经创建。所有的对象和数组都在堆上进行分配。这部分空间可通过 GC 进行回收。当申请不到空间时会抛出 OutOfMemoryError。下面我们简单的模拟一个堆内存溢出的情况：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

package com.paddx.test.memory;   import java.util.ArrayList; import java.util.List;   public class HeapOomMock {     public static void main(String[] args) {         List<byte[]> list = new ArrayList<byte[]>();         int i = 0;         boolean flag = true;         while (flag){             try {                 i++;                 list.add(new byte[1024 * 1024]);//每次增加一个1M大小的数组对象             }catch (Throwable e){                 e.printStackTrace();                 flag = false;                 System.out.println("count="+i);//记录运行的次数             }         }     } }

代码段 2

运行上述代码，输出结果如下：　　

　　　

注意，这里我指定了堆内存的大小为16M，所以这个地方显示的count=14（这个数字不是固定的），至于为什么会是14或其他数字，需要根据 GC 日志来判断，具体原因会在下篇文章中给大家解释。

5、方法区：

　　方法区也是所有线程共享。主要用于存储类的信息、常量池（链接：https://blog.csdn.net/kdy527/article/details/86511410）、方法数据、方法代码等。方法区逻辑上属于堆的一部分，但是为了与堆进行区分，通常又叫“非堆”。 关于方法区内存溢出的问题会在下文中详细探讨。

二、PermGen（永久代）

　　绝大部分 Java 程序员应该都见过 "java.lang.OutOfMemoryError: PermGen space "这个异常。这里的 “PermGen space”其实指的就是方法区。不过方法区和“PermGen space”又有着本质的区别。前者是 JVM 的规范，而后者则是 JVM 规范的一种实现，并且只有 HotSpot 才有 “PermGen space”，而对于其他类型的虚拟机，如 JRockit（Oracle）、J9（IBM） 并没有“PermGen space”。由于方法区主要存储类的相关信息，所以对于动态生成类的情况比较容易出现永久代的内存溢出。最典型的场景就是，在 jsp 页面比较多的情况，容易出现永久代内存溢出。我们现在通过动态生成类来模拟 “PermGen space”的内存溢出：

 代码段 3

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

package com.paddx.test.memory;   import java.io.File; import java.net.URL; import java.net.URLClassLoader; import java.util.ArrayList; import java.util.List;   public class PermGenOomMock{     public static void main(String[] args) {         URL url = null;         List<ClassLoader> classLoaderList = new ArrayList<ClassLoader>();         try {             url = new File("/tmp").toURI().toURL();             URL[] urls = {url};             while (true){                 ClassLoader loader = new URLClassLoader(urls);                 classLoaderList.add(loader);                 loader.loadClass("com.paddx.test.memory.Test");             }         } catch (Exception e) {             e.printStackTrace();         }     } }

运行结果如下：

　　本例中使用的 JDK 版本是 1.7，指定的 PermGen 区的大小为 8M。通过每次生成不同URLClassLoader对象来加载Test类，从而生成不同的类对象，这样就能看到我们熟悉的 "java.lang.OutOfMemoryError: PermGen space " 异常了。这里之所以采用 JDK 1.7，是因为在 JDK 1.8 中， HotSpot 已经没有 “PermGen space”这个区间了，取而代之是一个叫做 Metaspace（元空间） 的东西。下面我们就来看看 Metaspace 与 PermGen space 的区别。

三、Metaspace（元空间）

　　其实，移除永久代的工作从JDK1.7就开始了。JDK1.7中，存储在永久代的部分数据就已经转移到了Java Heap或者是 Native Heap。但永久代仍存在于JDK1.7中，并没完全移除，譬如符号引用(Symbols)转移到了native heap；字面量(interned strings)转移到了java heap；类的静态变量(class statics)转移到了java heap。我们可以通过一段程序来比较 JDK 1.6 与 JDK 1.7及 JDK 1.8 的区别，以字符串常量为例：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

package com.paddx.test.memory;   import java.util.ArrayList; import java.util.List;   public class StringOomMock {     static String  base = "string";     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());         }     } }

这段程序以2的指数级不断的生成新的字符串，这样可以比较快速的消耗内存。我们通过 JDK 1.6、JDK 1.7 和 JDK 1.8 分别运行：

JDK 1.6 的运行结果：

JDK 1.7的运行结果：

JDK 1.8的运行结果：

　　从上述结果可以看出，JDK 1.6下，会出现“PermGen Space”的内存溢出，而在 JDK 1.7和 JDK 1.8 中，会出现堆内存溢出，并且 JDK 1.8中 PermSize 和 MaxPermGen 已经无效。因此，可以大致验证 JDK 1.7 和 1.8 将字符串常量由永久代转移到堆中，并且 JDK 1.8 中已经不存在永久代的结论。现在我们看看元空间到底是一个什么东西？

　　元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小：

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

　　除了上面两个指定大小的选项以外，还有两个与 GC 相关的属性：
　　-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集
　　-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集

现在我们在 JDK 8下重新运行一下代码段 4，不过这次不再指定 PermSize 和 MaxPermSize。而是指定 MetaSpaceSize 和 MaxMetaSpaceSize的大小。输出结果如下：

从输出结果，我们可以看出，这次不再出现永久代溢出，而是出现了元空间的溢出。

MaxMetaspaceSize的调优

• -XX:MaxMetaspaceSize={unlimited}
• 元空间的大小受限于你机器的内存
• 限制类的元数据使用的内存大小，以免出现虚拟内存切换以及本地内存分配失败。如果怀疑有类加载器出现泄露，应当使用这个参数；32位机器上，如果地址空间可能会被耗尽，也应当设置这个参数。
• 元空间的初始大小是21M——这是GC的初始的高水位线，超过这个大小会进行Full GC来进行类的回收。
• 如果启动后GC过于频繁，请将该值设置得大一些
• 可以设置成和持久代一样的大小，以便推迟GC的执行时间

CompressedClassSpaceSize的调优

Klass Metaspace:Klass Metaspace就是用来存klass的，klass是我们熟知的class文件在jvm里的运行时数据结构，不过有点要提的是我们看到的类似A.class其实是存在heap里的，是java.lang.Class的一个对象实例。可通过-XX:CompressedClassSpaceSize参数来控制，这个参数前面提到了默认是1G，但是这块内存也可以没有。

• 只有当-XX:+UseCompressedClassPointers开启了才有效
• -XX:CompressedClassSpaceSize=1G
• 由于这个大小在启动的时候就固定了的，因此最好设置得大点。
• 没有使用到的话不要进行设置
• JVM后续可能会让这个区可以动态的增长。不需要是连续的区域，只要从基地址可达就行；可能会将更多的类元信息放回到元空间中；未来会基于PredictedLoadedClassCount的值来自动的设置该空间的大小

正如前面提到了，Metaspace VM管理Metaspace空间的增长。但有时你会想通过在命令行显示的设置参数-XX:MaxMetaspaceSize来限制Metaspace空间的增长。默认情况下，-XX:MaxMetaspaceSize并没有限制，因此，在技术上，Metaspace的尺寸可以增长到交换空间，而你的本地内存分配将会失败。

每次垃圾收集之后，Metaspace VM会自动的调整high watermark，推迟下一次对Metaspace的垃圾收集。

这两个参数，-XX：MinMetaspaceFreeRatio和-XX：MaxMetaspaceFreeRatio,类似于GC的FreeRatio参数，可以放在命令行。

Metaspace可以使用的工具

针对Metaspace，JDK自带的一些工具做了修改来展示Metaspace的信息：

• jmap -clstats :打印类加载器的统计信息(取代了在JDK8之前打印类加载器信息的permstat)。
• jstat -gc :Metaspace的信息也会被打印出来。
• jcmd GC.class_stats:这是一个新的诊断命令，可以使用户连接到存活的JVM，转储Java类元数据的详细统计。

四、总结为什么用元空间Metaspace取代永久代

　　通过上面分析，大家应该大致了解了 JVM 的内存划分，也清楚了 JDK 8 中永久代向元空间的转换。不过大家应该都有一个疑问，就是为什么要做这个转换？所以，最后给大家总结以下几点原因：

　　1、字符串存在永久代中，容易出现性能问题和内存溢出。

　　2、类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。

　　3、永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。

　　4、Oracle 可能会将HotSpot 与 JRockit 合二为一。

五、年轻代、老年代和永久代的内存分配、JVM堆内存相关的启动参数

1，为什么需要把堆分代？

分代的唯一理由就是优化GC性能

• 如果没有分代，所有的对象都在一块，GC的时要找到哪些对象是没用的，这样就会对堆的所有区域进行扫描。而我们的很多对象都是朝生夕死的。
• 如果分代的话，把新创建的对象放到某一地方，当GC的时先把这块存“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。

2，Minor GC、Major GC和Full GC之间的区别

• 从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC。
• Major GC 是清理老年代。
• Full GC 是清理整个堆空间—包括年轻代和老年代。

3，年轻代中的GC

3,1，HotSpot JVM把年轻代分为了三部分：

1个Eden区和2个Survivor区（分别叫from和to）。默认比例为8：1

3,2，年轻和老年代的关系

一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后，
如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，
当它的年龄增加到一定程度时，就会被移动到年老代中。

3,3，年轻代采用复制算法回收对象

因为年轻代中的对象基本都是朝生夕死的(80%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，

将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。
复制算法不会产生内存碎片。

3,4，年轻代回收的步骤：

1，在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。
2，紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，
3，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。
   年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。
4，经过这次GC后，Eden区和From区已经被清空。
   这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。
   不管怎样，都会保证名为To的Survivor区域是空的。
5，Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。

4.有关年轻代的JVM参数

1)-XX:NewSize和-XX:MaxNewSize

用于设置年轻代的大小，建议设为整个堆大小的1/3或者1/4,两个值设为一样大。

2)-XX:SurvivorRatio

用于设置Eden和其中一个Survivor的比值，这个设置新生代中1个Eden区与1个Survivor区的大小比值。在hotspot虚拟机中，新生代 = 1个Eden + 2个Survivor。如果新生代内存是10M，SurvivorRatio=8，那么Eden区占8M，2个Survivor区各占1M。

3)-XX:+PrintTenuringDistribution

这个参数用于显示每次Minor GC时Survivor区中各个年龄段的对象的大小。

4).-XX:InitialTenuringThreshol和-XX:MaxTenuringThreshold

用于设置晋升到老年代的对象年龄的最小值和最大值，每个对象在坚持过一次Minor GC之后，年龄就加1。

5)-Xms 和 -Xmx (-XX:InitialHeapSize 和 -XX:MaxHeapSize)：

指定JVM初始占用的堆内存和最大堆内存。JVM也是一个软件，也必须要获取本机的物理内

存，然后JVM会负责管理向操作系统申请到的内存资源。JVM启动的时候会向操作系统申请 -Xms 设置的内存，JVM启动后运行一段时间，如果发现内存空间

不足，会再次向操作系统申请内存。JVM能够获取到的最大堆内存是-Xmx设置的值。

6)-XX:OldSize：

设置JVM启动分配的老年代内存大小，类似于新生代内存的初始大小-XX:NewSize。

5.查看JVM参数

通过jps命令获取到进程pid，然后通过jmap -heap pid就可以查看内存分配和使用情况。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

>jmap -heap 8912 Attaching to process ID 8912, please wait... Debugger attached successfully. Client compiler detected. JVM version is 24.60-b09   using thread-local object allocation. Mark Sweep Compact GC   Heap Configuration:    MinHeapFreeRatio = 40    MaxHeapFreeRatio = 70    MaxHeapSize      = 209715200 (200.0MB)    NewSize          = 104857600 (100.0MB)    MaxNewSize       = 104857600 (100.0MB)    OldSize          = 62914560 (60.0MB)    NewRatio         = 3    SurvivorRatio    = 8    PermSize         = 52428800 (50.0MB)    MaxPermSize      = 52428800 (50.0MB)