JDK 方法区变迁史：版本间的差异与改进-51CTO.COM

经常看到初学JVM的读者会因为方法区这一概念提出下面这些混淆的问题和概念：

什么是方法区？
方法区和永久代还有元空间是什么关系？
JDK8版本的常量和静态变量是在堆区？永久代？还是方法区？还是元空间？

所以，笔者这里就以这篇文章来帮助读者梳理一下JVM中方法区的概念。

详解各版本JVM方法区

方法区简介

方法区其实是一个《Java虚拟机规范》一个逻辑上的概念，对于不同版本的JVM都有不同的实现，就以我们常用的HotSpot JVM而言，方法区还有一个别名叫Non-Heap，即非堆内存，这么定义的目的自然是要让Java开发者明白方法区和堆是一块独立于Java堆的内存空间，而这里笔者也列出方法区几个通用的概念：

方法区和Java堆内存一样也是属于各个线程共享的内存区域。
方法区在JVM启动就时创建，并且它实际的物理内存空间和Java堆内存一样可以是不连续的，注意笔者所说，可以是不连续的。
方法区内存大小也可以选择固定大小或者可扩展。
方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，同样会出现内存溢出的问题，可能是java.lang.OutOfMemoryError:PermGen space(永久代空间满了)，也可能是java.lang.OutOfMemoryError:Metaspace(元空间满了)，这一点笔者会在后文中方法区在各个版本中的实现进行拓展说明。

这里我们补充说明一下，后文所涉及的不同版本的JVM版本都是以HotSpot虚拟机展开探讨。

JDK7之前的版本

先来在JDK7之前的版本内存结构图，在这些版本上逻辑上方法区和堆区在逻辑上是连续的，实际上在物理内存上来说，它们却可是一块连续的内存。在JDK7之前的版本，它们都用的是一个名为PermGen(永久代)的虚作为方法区的实现。这也是为什么很多读者会把永久代和老年代混淆，实际上这两个完全不是一个概念，在JDK7之前的版本，永久代仅仅是作为方法区的实现并和老年代捆绑在一起，当老年代或者永久代任何一个内存空间满了的时候，都会触发一次垃圾收集。

在这些个版本的JVM，方法区即永久代存储的是:

类信息
字段信息
方法信息
常量
静态变量
即时编译器编译后的代码缓存等数据

JDK7版本的变化

JDK7则是基于原有的内存结构的基础上将部分数据进行转移：

将符号引用(Symbols)转移到Native Memory(本地内存)，可能很多读者经常听到本地内存这一概念，这里笔者进行拓展解释一下，本地内存即JVM运行时内存，它是不受GC管理的一块内存区域，是直接由操作系统分配给JVM的一块内存，需要程序手动进行获取和释放。
因为永久代的GC是跟随着老年代触发的，所以考虑到垃圾回收的效率，JDK7将所有字符串常量的信息都直接移动到Java Heap中。
类的静态变量转移到Java Heap中。

JDK8版本对于方法区的实现

最后我们再来说说现主流的JDK8版本，它基于JDK7的存储方式，将永久代(Perm Gen) 改为元空间(Metaspace) 作为方法区的实现，同时元空间不再与堆内存连续，是一个划分在本地内存(Native memory) 的一块内存区域，这也就意味着JDK8版本实现的方法区不参与Java Heap的GC，仅仅处理元数据空间那些已卸载类的垃圾回收。

所以JDK8版本的内存结构最终如下图所示，这也就意味着JDK7版本对永久代的设置参数(-XX:MaxPermSize) 变为无效参数，取而代之的是对元空间空间大小设置的参数(-XX:MetaspaceSize)。

实践验证观点

接下来我们通过几段代码来印证笔者的观点，来看看这段代码，笔者这里直接声明了一段最大长度的静态数组，这个数组长度为Integer.MAX_VALUE，粗略估算这个数组大致需要占用4G左右的内存空间。

//声明一个静态数组
 public static int[] arr=new int[Integer.MAX_VALUE];

    public void test(){
        for (int i = 0; i < arr.length; i++) {
            System.out.println(arr[i]);
        }
    }

    public static void main(String[] args) {
       new Main().test();
    }1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

输出结果如下，可以看到直接抛出了OOM异常，这也就意味着静态变量在JDK8版本的堆内存中。

java.lang.OutOfMemoryError: Requested array size exceeds VM limit
 at com.sharkChili.webTemplate.Main.<clinit>(Main.java:16)
Exception in thread "main" 1.
2.
3.

同理的再来看看这段代码。笔者声明了一个常量数组，如果它也存在于堆内存中的话，那么它的运行结果也是OOM：

//常量全局数组
 final int[] arr = new int[Integer.MAX_VALUE];

    public void test() {
        for (int i = 0; i < arr.length; i++) {
            System.out.println(arr[i]);
        }
    }

    public static void main(String[] args) {
        new Main().test();
    }1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

意料之内，在JDK8版本常量也是分配于堆内存中：

Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit
 at com.sharkChili.webTemplate.Main.<init>(Main.java:15)
 at com.sharkChili.webTemplate.Main.main(Main.java:25)1.
2.
3.

接下来这个实验比较特殊，我们都知道CGLIB是一个强大且高性能的字节码生成库，它支持运行时扩展Java类或接口实现，本质上就是动态生成一个子类并覆盖要代理的类。所以为了验证JDK8版本的类信息是否是存于堆区还是方法区，我们就基于一个CGLIB通过无限循环去创建无数的代理类，让JVM去存储这些类定义的信息，看看最终抛出的是OOM还是元空间不足。

为了能够更快看到效果，笔者手动调整了一下元空间的大小：

-XX:MetaspaceSize=100m -XX:MaxMetaspaceSize=100m1.

示例代码如下，通过无限循环生成代理类并创建EmptyObject的代理对象：

public static void main(String[] args) {
       while (true){
           Enhancer enhancer = new Enhancer();
           //设置代理目标
           enhancer.setSuperclass(EmptyObject.class);
   //不生成同属性类的静态缓存
           enhancer.setUseCache(false);

           //设置单一回调对象，在调用中拦截对目标方法的调用
           enhancer.setCallback((MethodInterceptor) (o, method, objects, methodProxy) -> methodProxy.invokeSuper(objects, args));
   //如有必要，生成一个新类，并使用指定的回调（如果有的话）创建一个新的对象实例。
           enhancer.create();
       }

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

启动后我们使用jvisualvm查看当前程序的GC情况，可以看到Java Heap运行正常，即时创建的无用代理对象都会被回收掉：

再来看看元空间，可以看到随着实践的推移，无数个全新的代理类的信息存到元空间，因为元空间不受GC管理，所以使用内存不断增加：

最终如预期所说出现java.lang.OutOfMemoryError: Metaspace：

Exception in thread "main" java.lang.OutOfMemoryError: Metaspace
 at net.sf.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:345)
 at net.sf.cglib.proxy.Enhancer.generate(Enhancer.java:492)
 at net.sf.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:114)
 at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:291)
 at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:480)
 at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:305)
 at com.sharkChili.webTemplate.Main.main(Main.java:39)1.
2.
3.
4.
5.
6.
7.
8.

常见面试题

1.为什么JDK8要将取消永久代的概念

大体来说取消永久代有以下两个原因：

首要原因是Hotspot和JRockit代码合并，前者并没有所谓的永久代。
为了提高垃圾的回收的效率。我们都知道在JDK8版本之前老年代和永久代内存空间是连续的，任何一个满了都可能触发GC，这种做法对于永久代来说回收效率偏低(每次GC基本回收不了多少垃圾)，且Hotspot为了做到这一点还需要专门对元数据信息进行特殊处理，所以为了简化GC处理，JDK8版本就将方法区改为使用元空间实现，如此后续对于元数据内存优化可以专门处理而无需考虑对于堆空间的影响。

2.什么是方法区？是如何实现的？

方法区是Java虚拟机规范中定义的一块用于存储类信息、常量、静态变量以及编译器便后的代码数据的逻辑内存区域，注意这里笔者所强调的是逻辑内存逻辑区域，而非物理形式的内存区域，而对应的内存实现，在不同的JDK版本不同的实现：

在JDK6的版本方法区都是通过永久代进行实现，存储类信息、常量池(包括字符串常量池)、静态变量和JIT编译器编译后的代码等数据。
JDK7方法区还是永久代实现，只不过将字符串常量池和静态变量都存放到堆内存中，主要原因是永久代GC效率太低，只有在full gc的时候才会回收，所以将字符串常量池放到堆区保证高效的回收字符串。
从JDK8开始方法区的实现直接用元空间来实现，而元空间使用的即native memory，也就是本地内存，而本地内存即动态向操作系统获取的内存空间，需要程序手动进行获取和释放，从Java的角度来说就是不受JVM虚拟机所约束的内存空间。也正是因为这几个特点，保证元空间可以根据应用程序的需求动态调整大小，避免永久代内存溢出问题的同时还减少的GC回收的压力。