一、JVM内存模型
内存空间(Runtime Data Area)中可以按照是否线程共享分为两块,线程共享的是方法区(Method Area)和堆(Heap),线程独享的是Java虚拟机栈(Java Stack),本地方法栈(Native Method Stack)和PC寄存器(Program Counter Register)。具体参见下图:
1.虚拟机栈:
每个线程有一个私有的栈,随着线程的创建而创建。栈里面存放着一种叫做“栈帧”的东西,每个方法会创建一个栈帧,栈帧中存放了局部变量表(基本数据类型和对象引用)、操作数栈、方法出口等信息。栈的大小可以固定也可以动态扩展。当栈调用深度大于JVM所允许的范围,会抛出StackOverflowError的错误,不过这个深度范围不是一个恒定的值,我们通过下面这段程序可以测试一下这个结果:
- // 栈溢出测试源码
-
- package com.paddx.test.memory;
-
- /\*\*
- \* Created by root on 2/28/17.
- \*/
- 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();
- }
- }
- }
运行三次,可以看出每次栈的深度都是不一样的,输出结果如下:
查看三张结果图,可以看出每次的Stack deep值都有所不同。究其原因,就需要深入到JVM的源码中才能探讨,这里不作赘述。
虚拟机栈除了上述错误外,还有另一种错误,那就是当申请不到空间时,会抛出OutOfMemoryError。这里有一个小细节需要注意,catch捕获的是Throwable,而不是Exception,这是因为StackOverflowError和OutOfMemoryError都不属于Exception的子类。
2.本地方法栈:
这部分主要与虚拟机用到的Native方法相关,一般情况下,Java应用程序员并不需要关系这部分内容。
3.PC寄存器:
PC寄存器,也叫程序计数器。JVM支持多个线程同时运行,每个线程都有自己的程序计数器。倘若当前执行的是JVM方法,则该寄存器中保存当前执行指令的地址;倘若执行的是native方法,则PC寄存器为空。
4.堆:
堆内存是JVM所有线程共享的部分,在虚拟机启动的时候就已经创建。所有的对象和数组都在堆上进行分配。这部分空间可通过GC进行回收。当申请不到空间时,会抛出OutOfMemoryError。下面我们简单的模拟一个堆内存溢出的情况:
- package com.paddx.test.memory;
-
- import java.util.ArrayList;
- import java.util.List;
-
- /\*\*
- \* Created by root on 2/28/17.
- \*/
- 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); // 记录运行的次数
- }
- }
- }
- }
首先配置运行时虚拟机的启动参数:
然后运行代码,输出结果如下:
注意,这里我们指定了堆内存的大小为16M,所以这个地方显示的Count=13(这个数字不是固定的),至于为什么会是13或其他数字,需要根据GC日志来判断。
5.方法区:
方法区也是所有线程共享的。主要用于存储类的信息、常量池、方法数据、方法代码等。方法区逻辑上属于堆的一部分,但是为了与堆进行区分,通常又叫“非堆”。关于方法区的内存溢出问题会在下文中详细讨论。
二、PermGen(永久代)
绝大部分Java程序员应该都见过“java.lang.OutOfMemoryError: PremGen space”异常。这里的“PermGen space”其实指的就是方法区。不过方法区和“PermGen space”又有着本质的区别。前者是JVM的规范,而后者则是JVM规范的一种实现,并且只有HotSpot才有“PermGen space”,而对于其他类型的虚拟机,如JRockit(Oracle)、J9(IBM)并没有“PermGen space”。由于方法区主要存储类的相关信息,所以对于动态生成类的情况比较容易出现永久代的内存溢出。最典型的场景就是,在JSP页面比较多的情况,容易出现永久代内存溢出。我们现在通过动态生成类来模拟“PermGen space”的内存溢出:
- 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();
- }
- }
- }
- package com.paddx.test.memory;
-
- public class Test {}
运行结果如下:
本例中使用的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(元空间)
其实,移除永久代的工作从JDK 1.7就开始了。JDK 1.7中,存储在永久代的部分数据就已经转移到Java Heap或者Native Heap。但永久代仍存在于JDK 1.7中,并没有完全移除,譬如符号引用(Symbols)转移到了native heap;字面量(interned strings)转移到了Java heap;类的静态变量(class statics)转移到了Java heap。我们可以通过一段程序来比较JDK 1.6、JDK 1.7与JDK 1.8的区别,以字符串常量为例:
- 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和MaxPermSize已经失效。因此,可以大致验证JDK 1.7和JDK 1.8中将字符串常量由永久代转移到堆中,并且JDK 1.8中已经不存在永久代的结论。现在我们来看一看元空间到底是一个什么东西?
JDK1.8对JVM架构的改造将类元数据放到本地内存中,另外,将常量池和静态变量放到Java堆里。HotSpot VM将会为类的元数据明确分配和释放本地内存。在这种架构下,类元信息就突破了原来-XX:MaxPermSize的限制,现在可以使用更多的本地内存。这样就从一定程度上解决了原来在运行时生成大量类造成经常Full GC问题,如运行时使用反射、代理等。所以升级以后Java堆空间可能会增加。
元空间的本质和永久代类似,都是对JVM规范中方法区的实现。不过元空间与永久代之间的最大区别在于:元空间并不在虚拟机中,而是使用本地内存。因此,默认情况下,元空间的大小仅受本地内存限制,但可以通过以下参数指定元空间的大小:
除了上面的两个指定大小的选项外,还有两个与GC相关的属性:-XX:MetaspaceSize,初始空间大小,达到该值就会触发垃圾收集进行类型卸载,同时GC会对改值进行调整:如果释放了大量的空间,就适当降低该值;如果释放了很少的空间,那么在不超过MaxMetaspaceSize时,适当提高该值。
-XX:MaxMetaspaceSize,最大空间,默认是没有限制的。
-XX:MinMetaspaceFreeRatio,在GC之后,最小的Metaspace剩余空间容量的百分比,减少为分配空间所导致的垃圾收集。
-XX:MaxMetaspaceFreeRatio,在GC之后,最大的Metaspace剩余空间容量的百分比,减少为释放空间所导致的垃圾收集。
现在我们在JDK 1.8重新运行一下上面第二部分(PermGen(永久代))的代码,不过这次不再指定PermSize和MaxPermSize。而是制定MetaspaceSize和MaxMetaspaceSize的大小。输出结果如下:
从输出结果,我们可以看出,这次不再出现永久代溢出,而是出现元空间的溢出。
四、总结
通过上面的分析,大家应该大致了解了JVM的内存划分,也清楚了JDK 1.8中永久代向元空间的转换。不过大家应该有一个疑问,就是为什么要做这个转换?以下为大家总结几点原因:
- 字符串在永久代中,容易出现性能问题和内存溢出。
- 类及方法的信息等比较难确定大小,因此对于永久代的大小指定比较困难,太小容易出现永久代溢出,太大则容易出现老年代溢出。
- 永久代会为GC带来不必要的复杂度,并且回收效率偏低。
- Oracle可能会将HotSpot与JRockit合二为一。
五、参考:
1.JVM内存模型——永久代(PermGen)和元空间(Metaspace)(http://www.cnblogs.com/paddix/p/5309550.html)
2.阿里电面试题汇总(http://www.deanwangpro.com/2017/01/31/ali-interview/)