03-JVM内存模型：堆与方法区

一、堆（heap）

1.1.什么是堆

　　堆是用于存放对象的内存区域。因此，它是垃圾收集器（gc）管理的主要目标。其具有以下特点：

• 堆在逻辑上划分为“新生代”和“老年代”。由于java中的对象大部分是朝生夕灭，还有一小部分能够长期的驻留在内存中，为了对这两种对象进行最有效的回收，将堆划分为新生代和老年代，并且执行不同的回收策略。不同的垃圾收集器对这2个逻辑区域的回收机制不尽相同，在后续的章节中我们将详细的讲解。
• 堆占用的内存并不要求物理连续，只需要逻辑连续即可。
• 堆一般实现成可扩展内存大小，使用“-xms”与“-xmx”控制堆的最小与最大内存，扩展动作交由虚拟机执行。但由于该行为比较消耗性能，因此一般将堆的最大最小内存设为相等。
• 堆是所有线程共享的内存区域，因此每个线程都可以拿到堆上的同一个对象。
• 堆的生命周期是随着虚拟机的启动而创建。

1.2.堆异常

　　当堆无法分配对象内存且无法再扩展时，会抛出outofmemoryerror异常。

　　一般来说，堆无法分配对象时会进行一次gc，如果gc后仍然无法分配对象，才会报内存耗尽的错误。可以通过不断生成新的对象但不释放引用来模拟这种情形：

 1 /**
 2  * java堆溢出demo
 3  * jvm参数：-xms20m -xmx20m -xx:+heapdumponoutofmemoryerror
 4  * created by chenjunyi on 2018/4/25.
 5  */
 6 public class heapoom {
 7 
 8     static class oomobject {
 9     }
10 
11     public static void main(string[] args) {
12         list<oomobject> list = new arraylist<>();
13         //不断创建新对象，使得heap溢出
14         while (true) {
15             list.add(new oomobject());
16         }
17     }
18 
19 }

　　上述代码中对象不断的被创建而不进行引用释放，导致gc无法回收堆内存，最终outofmemoryerror，错误信息：

1 java.lang.outofmemoryerror: java heap space

 

 二、方法区（method area）

2.1.什么是方法区

　　方法区，也称非堆（non-heap），又是一个被线程共享的内存区域。其中主要存储加载的类字节码、class/method/field等元数据对象、static-final常量、static变量、jit编译器编译后的代码等数据，。另外，方法区包含了一个特殊的区域“运行时常量池”，它们的关系如下图所示：

（1）加载的类字节码：要使用一个类，首先需要将其字节码加载到jvm的内存中。至于类的字节码来源，可以多种多样，如.class文件、网络传输、或cglib字节码框架直接生成。
（2）class/method/field等元数据对象：字节码加载之后，jvm会根据其中的内容，为这个类生成class/method/field等对象，它们用于描述一个类，通常在反射中用的比较多。不同于存储在堆中的java实例对象，这两种对象存储在方法区中。
（3）static-final常量、static变量：对于这两种类型的类成员，jvm会在方法区为它们创建一份数据，因此同一个类的static修饰的类成员只有一份；
（4）jit编译器的编译结果：以hotspot虚拟机为例，其在运行时会使用jit即时编译器对热点代码进行优化，优化方式为将字节码编译成机器码。通常情况下，jvm使用“解释执行”的方式执行字节码，即jvm在读取到一个字节码指令时，会将其按照预先定好的规则执行栈操作，而栈操作会进一步映射为底层的机器操作；通过jit编译后，执行的机器码会直接和底层机器打交道。如下图所示：

2.2.运行时常量池

　　在2.1小节中，我们了解到类的字节码在加载时会被解析并生成不同的东西存入方法区。类的字节码中不仅包含了类的版本、字段、方法、接口等描述信息，还包含了一个常量池。常量池用于存放在字节码中使用到的所有字面量和符号引用（如字符串字面量），在类加载时，它们进入方法区的运行时常量池存放。

　　运行时常量池是方法区中一个比较特殊的部分，具备动态性，也就是说，除了类加载时将常量池写入其中，java程序运行期间也可以向其中写入常量：

1 //使用stringbuilder在堆上创建字符串abc，再使用intern将其放入运行时常量池
2 string str = new stringbuilder("abc");
3 str.intern();
4 //直接使用字符串字面量xyz，其被放入运行时常量池
5 string str2 = "xyz";

 2.3.方法区的实现

　　方法区的实现，虚拟机规范中并未明确规定，目前有2种比较主流的实现方式：

（1）hotspot虚拟机1.7-：在jdk1.6及之前版本，hotspot使用“永久代（permanent generation）”的概念作为实现，即将gc分代收集扩展至方法区。这种实现比较偷懒，可以不必为方法区编写专门的内存管理，但带来的后果是容易碰到内存溢出的问题（因为永久代有-xx:maxpermsize的上限）。在jdk1.7+之后，hotspot逐渐改变方法区的实现方式，如1.7版本移除了方法区中的字符串常量池。

（2）hotspot虚拟机1.8+：1.8版本中移除了方法区并使用metaspace（元数据空间）作为替代实现。metaspace占用系统内存，也就是说，只要不碰触到系统内存上限，方法区会有足够的内存空间。但这不意味着我们不对方法区进行限制，如果方法区无限膨胀，最终会导致系统崩溃。

　　我们思考一个问题，为什么使用“永久代”并将gc分代收集扩展至方法区这种实现方式不好，会导致oom？首先要明白方法区的内存回收目标是什么，方法区存储了类的元数据信息和各种常量，它的内存回收目标理应当是对这些类型的卸载和常量的回收。但由于这些数据被类的实例引用，卸载条件变得复杂且严格，回收不当会导致堆中的类实例失去元数据信息和常量信息。因此，回收方法区内存不是一件简单高效的事情，往往gc在做无用功。另外随着应用规模的变大，各种框架的引入，尤其是使用了字节码生成技术的框架，会导致方法区内存占用越来越大，最终oom。

2.4.方法区异常

　　在2.3一节中，我们了解到方法区的2种实现方式最终都会有一个最大值上限，因此若方法区（含运行时常量池）占用内存到达其最大值，且无法再申请到内存时，便会抛出outofmemoryerror。

　　在下面的例子中，我们将使用cglib字节码生成框架不断生成新的类，最终使方法区内存占用满，抛出outofmemoryerror：

 1 /**
 2  * java方法区溢出outofmemoryerror（jvm参数适用于jdk1.6之前，借助cglib）
 3  * jvm参数：-xx:permsize=10m -xx:maxpermsize=10m
 4  * created by chenjunyi on 2018/4/26.
 5  */
 6 public class javamethodareaoom {
 7 
 8     public static void main(string[] args) {
 9         while (true) {
10             enhancer enhancer = new enhancer();
11             enhancer.setsuperclass(oomobject.class);
12             enhancer.setusecache(false);
13             enhancer.setcallback((methodinterceptor) (o, method, objects, methodproxy) -> methodproxy.invokesuper(objects, args));
14             enhancer.create();
15         }
16     }
17 
18     static class oomobject {
19     }
20 
21 }

　　报错信息为：

1 caused by: java.lang.outofmemoryerror: permgen space
2   at java.lang.classloader.defineclass1(native method)
3   ···

　　其实，在日常开发中，不仅仅使cglib字节码生成框架会产生大量的class信息，动态语言、jsp、基于osgi的应用都会在方法区额外产生大量的类信息。