解密JMV内存区域堆

堆是JVM中相当核心的内容&＃xff0c;因为堆是JVM中管理的最大一块内存区域&＃xff0c;大部分的GC也发生在堆区&＃xff0c;那接下来就让我们深入地探究一下JVM中的堆结构。

需要明确&＃xff0c;一个JVM实例只存在一个堆内存&＃xff0c;堆区在JVM启动的时候就被创建&＃xff0c;其空间大小也被确定下来&＃xff0c;但堆空间的大小是可以通过JVM参数调节的&＃xff0c;所有的线程共享堆。

堆的内存结构

因为堆是垃圾回收的重点区域&＃xff0c;现代垃圾回收器大部分都基于分代收集理论设计&＃xff0c;所以将堆空间分为&＃xff1a;

1. Young Generation Space&＃xff08;新生代&＃xff09;

2. Old Generation Space&＃xff08;老年代&＃xff09;

3. Perm Space&＃xff08;永久代&＃xff09;- 永久代是方法区的一个实现&＃xff08;只有HotSpot JVM才有永久代&＃xff09;&＃xff0c;事实上方法区是逻辑独立的&＃xff0c;即&＃xff1a;从逻辑上来说&＃xff0c;方法区是在堆的外面的

其中新生代又可细分为&＃xff1a;

1. Eden&＃xff08;伊甸园区&＃xff09;

2. Survivor&＃xff08;幸存区&＃xff09;

从JDK1.8开始&＃xff0c;JVM规范摒弃了方法区的概念&＃xff0c;取而代之的是Meta Space&＃xff08;元空间&＃xff09;&＃xff0c;使用的是物理内

存。

通过两个JVM参数可以设置堆的初始内存和最大内存&＃xff1a;

• -Xms&＃xff1a;设置堆的初始内存

• -Xmx&＃xff1a;设置堆的最大内存

我们可以先来看看自己的JVM分配的堆内存情况&＃xff1a;

public static void main(String[] args) {// 获取堆空间的内存总量long totalMemory &＃61; Runtime.getRuntime().totalMemory() / 1024 / 1024;// 获取堆空间试图使用的最大内存long maxMemory &＃61; Runtime.getRuntime().maxMemory() / 1024 / 1024;System.out.println(totalMemory &＃43; "M");System.out.println(maxMemory &＃43; "M");
}

运行结果&＃xff1a;

123M
1799M

默认情况下堆的初始内存大小是物理内存的64分之一&＃xff0c;而最大内存大小是物理内存的四分之一&＃xff0c;但是会发现&＃xff0c;物理内存&＃xff08;8G&＃xff09;的四分之一应该是2G才对&＃xff0c;而堆的最大内存空间并没有到达2G&＃xff0c;这个问题我们留到后面解决&＃xff0c;先来设置一下堆的内存大小&＃xff1a;

在VM options中填入 -Xms600m -Xmx600m &＃xff0c;若是找不到VM options&＃xff0c;则点击右上角的Modify options&＃xff0c;并勾选Add VM options&＃xff0c;此时重新运行程序&＃xff0c;结果为&＃xff1a;

575M
575M

接下来我们来详细地分析一下堆的内存分配情况&＃xff0c;打开cmd窗口&＃xff0c;输入 jps 指令可以查看当前正在运行的Java程序&＃xff0c;所以改造一下刚才的程序&＃xff1a;

public static void main(String[] args) {while (true){}
}

一直让它运行着&＃xff0c;然后输入 jps &＃xff1a;

C:\Users\Administrator>jps
1860 TestDemo
10664 Jps
2568 Launcher
8200

这样便查询到了TestDemo程序的进程id&＃xff0c;然后通过该id查询内存分配情况&＃xff0c;输入 jstat -gc 1860 &＃xff1a;

这里的S0C即为第一块幸存区的总内存&＃xff0c;S1C为第二块幸存区的总内存&＃xff0c;S0U为第一块幸存区使用的内存&＃xff0c;那么S1U就是第二块幸存区使用的内存&＃xff0c;后面的参数同理&＃xff0c;我们将这些区域的总量相加 25600 &＃43; 25600 &＃43; 153600 &＃43; 409600 &＃61; 614400 &＃xff0c;对它除以1024就得到600M&＃xff0c;这与我们之前设置的虚拟机参数就对应上了&＃xff0c;但还是无法解释通过Runtime实例获取的内存总量不足600M的问题。 

原来&＃xff0c;堆中的两块幸存区是不会被同时使用的&＃xff0c;这涉及到垃圾收集中的复制算法&＃xff0c;该算法总是使用其中一块幸存区空间&＃xff0c;当伊甸园区和该幸存区空间满了以后&＃xff0c;会触发一次GC&＃xff0c;将还存活的对象复制到另一块幸存区上&＃xff0c;然后将之前的空间直接清除。 

当我们减去其中一个幸存区的内存&＃xff1a;614400 - 25600 &＃61; 58800 &＃xff0c;对其除以1024&＃xff0c;得到575M&＃xff0c;这就是为什么程序的运行结果是575M的原因了。

我们也可以使用JVM参数 -XX:&＃43;PrintGCDetails 来查看内存的详细信息&＃xff1a;

记得把死循环删掉再运行程序&＃xff0c;否则就看不到输出结果了&＃xff1a;

HeapPSYoungGen total 179200K, used 9216K [0x00000000f3800000, 0x0000000100000000, 0x0000000100000000)eden space 153600K, 6% used [0x00000000f3800000,0x00000000f41001a0,0x00000000fce00000)from space 25600K, 0% used [0x00000000fe700000,0x00000000fe700000,0x0000000100000000)to space 25600K, 0% used [0x00000000fce00000,0x00000000fce00000,0x00000000fe700000)ParOldGen total 409600K, used 0K [0x00000000da800000, 0x00000000f3800000, 0x00000000f3800000)object space 409600K, 0% used [0x00000000da800000,0x00000000da800000,0x00000000f3800000)Metaspace used 3442K, capacity 4496K, committed 4864K, reserved 1056768Kclass space used 376K, capacity 388K, committed 512K, reserved 1048576K

这里的from和to就是两块幸存区的空间。

堆空间最常见的错误就是 OutOfMemoryError &＃xff0c;我们可以写一段程序来产生这个错误&＃xff1a;

public class TestDemo {public static void main(String[] args) {List list &＃61; new ArrayList<>();while (true) {User user &＃61; new User();list.add(user);}}
}class User {private byte[] bytes;public User() {bytes &＃61; new byte[1024 * 1024];}
}

运行片刻程序就报错了&＃xff1a;

Exception in thread "main" java.lang.OutOfMemoryError: Java heap spaceat com.wwj.jvm.User.(TestDemo.java:21)at com.wwj.jvm.TestDemo.main(TestDemo.java:11)

这里介绍一款JDK提供的工具&＃xff0c;通过它可以更直观地看到堆中的内存分配及变化&＃xff1a;

在其bin目录下有一个jvisualvm.exe的可执行文件&＃xff0c;我们直接双击打开它&＃xff0c;为了不使程序那么快地结束&＃xff0c;在程序中加一个延迟方法&＃xff1a;

public static void main(String[] args) {List list &＃61; new ArrayList<>();while (true) {try {Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}User user &＃61; new User();list.add(user);}
}

将程序重新运行起来&＃xff0c;然后查看jvisualvm工具&＃xff1a;

在下面的视图中&＃xff0c;我们能够清楚地观察到堆中各部分内存的动态变化情况&＃xff1a;

存储在JVM中的Java对象大体可分为两类&＃xff1a;

1. 生命周期较短的瞬时对象&＃xff0c;这类对象的创建和死亡都非常迅速

2. 生命周期很长的对象&＃xff0c;某些对象甚至能够存活到JVM的生命结束

为此&＃xff0c;堆空间才被分为新生代和老年代&＃xff0c;并将生命周期很短的对象放在新生代&＃xff0c;将生命周期很长的对象放在老年代&＃xff0c;因为在每次GC时&＃xff0c;垃圾回收器都会去判断当前对象是否可以被回收&＃xff0c;而这些生命周期很长的对象每次都被垃圾回收器扫描&＃xff0c;但每次都不回收&＃xff0c;故而可以将这些对象放在老年代&＃xff0c;并减少对老年代的GC次数&＃xff0c;从而将GC的重心放在新生代上。 

通过这两个区域对象的生命周期不同&＃xff0c;也可以设置不同的垃圾回收算法&＃xff0c;比如对新生代中的对象采用复制算法&＃xff0c;因为该区域的对象生命周期短&＃xff0c;消亡快&＃xff0c;所以当发生GC时并不会存在太多存活的对象&＃xff0c;而对老年代则采用标记-清除算法&＃xff0c;关于垃圾回收的具体内容在后面还会重点介绍。

下面通过一个程序来分析一下新生代与老年代的内存占比&＃xff1a;

public class TestDemo {public static void main(String[] args) {while (true){}}
}

将堆的内存空间设置一下 -Xms600m -Xmx600m &＃xff0c;查看可视化界面&＃xff1a;

新生代的内存空间为 150 &＃43; 25 &＃43;25 &＃61; 200 &＃xff0c;所以新生代与老年代内存空间的默认比例为 1:2 &＃xff0c;我们可以通过虚拟机参数来修改比例&＃xff1a;

-XX:NewRatio&＃61;3

此时表示新生代占1&＃xff0c;老年代占3&＃xff0c;新生代是老年代内存空间的三分之一。而Eden区和两个Survivor区的内存空间占比默认为&＃xff1a;8:1:1 &＃xff0c;也可以通过虚拟机参数修改&＃xff1a;

-XX:SurvivorRatio&＃61;6

此时比例会被修改为 6:1:1 。

需要了解&＃xff1a;几乎所有的Java对象都是在Eden区被创建出来的&＃xff0c;那么有例外情况吗&＃xff1f;当然有&＃xff0c;如果创建的对象所需内存非常大&＃xff0c;以至于Eden区根本放不下&＃xff0c;那么该对象就会直接在老年代创建。

对象创建过程

对象的创建是一个非常复杂的过程&＃xff0c;它的具体流程如下&＃xff1a;

1. 创建的对象首先存放在Eden区

2. 当Eden区的空间满了以后&＃xff0c;此时创建对象便会触发GC&＃xff08;Minor GC&＃xff09;&＃xff0c;将Eden区中存活的对象放入幸存区&＃xff0c;然后清除Eden区

3. 当触发Eden区的GC时&＃xff0c;会将Eden区中还存活的对象放入幸存区S0

4. 当Eden区满了再次触发GC时&＃xff0c;会将Eden区中存活的对象和幸存者S0中仍然存活的对象放入幸存区S1

5. 若再一次触发Eden区的GC&＃xff0c;则将存活的对象又重新放回幸存区S0&＃xff0c;依次循环

6. 存活的对象被放入幸存区一次&＃xff0c;年龄就会加1&＃xff0c;当对象的年龄到达15岁时&＃xff0c;该对象就会被晋升到老年代

注意在这个过程中&＃xff0c;只有Eden区满时才会触发GC&＃xff0c;此时垃圾回收器会对Eden区和Survivor区进行清理&＃xff0c;Survivor区满并不会触发GC&＃xff0c;而且GC完成后&＃xff0c;Eden区是一个空的状态。当要创建的对象内存超过Eden区空间时&＃xff0c;该对象会被直接晋升到老年代&＃xff0c;若是老年代仍然放不下&＃xff0c;则触发一次在老年代的GC&＃xff08;Full GC&＃xff09;&＃xff0c;如果GC完成后还是放不下&＃xff0c;则出现 OutOfMemoryError: Java heap space 错误。

接下来我们就来介绍一下垃圾回收类型&＃xff0c;大体可分为两类&＃xff1a;

1. 部分收集&＃xff08;Partial GC&＃xff09;

2. 整堆收集&＃xff08;Full GC&＃xff09;——针对整个堆结构和方法区的垃圾回收

其中部分收集又分为&＃xff1a;

1. 新生代收集&＃xff08;Minor GC / Young GC&＃xff09;——针对新生代的垃圾回收

2. 老年代收集&＃xff08;Major GC / Old GC&＃xff09;——针对老年代的垃圾回收

3. 混合收集&＃xff08;Mixed GC&＃xff09;——针对整个新生代以及部分老年代的垃圾回收

前面也提到了&＃xff0c;对于Minor GC&＃xff0c;只有当新生代中的Eden区满时才会触发&＃xff0c;Survivor区满是不会触发GC的&＃xff0c;Minor GC会将Eden区进行清空同时也会回收Survivor区中的垃圾&＃xff1b;注意Minor GC会引发STW&＃xff08;Stop The World&＃xff09;&＃xff0c;即&＃xff1a;Minor GC在进行垃圾回收时会暂停其它用户线程&＃xff0c;等垃圾回收结束&＃xff0c;用户线程才恢复运行。

而对于Major GC&＃xff0c;只有当老年代内存不足时才会触发该GC&＃xff0c;而通常情况下&＃xff0c;Major GC触发之前会伴随着至少一次的Minor GC&＃xff0c;这是因为在老年代空间满了之后&＃xff0c;会先尝试触发Minor GC&＃xff0c;当Minor GC结束后空间仍然不足&＃xff0c;则会触发Major GC&＃xff08;但这也并不是绝对的&＃xff0c;比如在Parallel Scavenge收集器的收集策略中就有直接进行Major GC的策略选择&＃xff09;。Major GC的速度一般会比Minor GC慢10倍甚至更多&＃xff0c;STW的时间也会更长&＃xff0c;当Major GC后空间仍然不足时&＃xff0c;就会产生 OutOfMemoryError 。

最后是Full GC&＃xff0c;它触发的情况有以下五种&＃xff1a;

1. 调用System类的gc()方法&＃xff0c;但这只是告诉JVM应该进行GC&＃xff0c;并不代表JVM会立马执行Full GC

2. 老年代内存不足

3. 方法区内存不足

4. Minor GC过后进行老年代的平均大小 大于 老年代的可用内存

5. 由Eden区、From区向To区复制时&＃xff0c;对象大小大于To区可用内存&＃xff0c;则把该对象晋升到老年代&＃xff0c;而老年代也没有足够的内存存放该对象

细心的同学应该发现了&＃xff0c;对于两块幸存区&＃xff0c;有时候叫它S0和S1&＃xff0c;而有时候又叫他们From和To&＃xff0c;这是什么情况呢&＃xff1f; 

事实上&＃xff0c;S0就是From区&＃xff0c;S1就是To区&＃xff0c;但由于复制-清除算法的过程&＃xff0c;它会将第一次Minor GC后存活的对象放入From区&＃xff0c;此时To区是空的&＃xff1b;当第二次Minor GC时&＃xff0c;垃圾回收器会扫描Eden区和From区&＃xff0c;并将还存活的对象放入To区&＃xff0c;然后清空Eden和From区&＃xff0c;此时From区会和To区做一个交换&＃xff0c;这样空的From区就会作为下一次GC的To区继续放置存活的对象&＃xff0c;即&＃xff1a;复制之后有交换&＃xff0c;谁空谁就做To区 。 

因为Full GC覆盖的范围比较广&＃xff0c;损耗的时间也是比较长的&＃xff0c;所以在开发中应该尽量避免Full GC的发生。

下面例举一些堆中常用的设置参数&＃xff1a;

• -XX:&＃43;PrintFlagsInitial&＃xff1a;查看所有的参数默认值

• -XX:&＃43;PrintFlagsFinal&＃xff1a;查看所有的参数最终值

• -Xms&＃xff1a;设置初始堆内存

• -Xmx&＃xff1a;设置最大堆内存

• -Xmn&＃xff1a;设置新生代的内存

• -XX:NewRatio&＃xff1a;配置新生代与老年代在堆结构的占比

• -XX:SurvivorRatio&＃xff1a;配置新生代中Eden区与Survivor区的占比

• -XX:MaxTenuringThreshold&＃xff1a;设置新生代垃圾的最大年龄

• -XX:&＃43;PrintGCDetails&＃xff1a;输出GC的详细日志

说到对象的内存分配&＃xff0c;我们理所当然地会认为对象是在堆中分配内存的&＃xff0c;那么它是对象存储的唯一选择吗&＃xff1f;答案是否定的&＃xff0c;它有一种特殊情况&＃xff0c;即&＃xff1a;如果经过 逃逸分析 后发现&＃xff0c;一个对象并没有逃逸出方法的话&＃xff0c;那么就可能被优化成栈上分配&＃xff0c;这样就无需在堆上分配内存&＃xff0c;那么什么又是逃逸分析呢&＃xff1f;逃逸分析的基本行为是分析对象的动态作用域&＃xff1a;

1. 当一个对象在方法中被定义后&＃xff0c;对象只在方法内部使用&＃xff0c;则认为没有发生逃逸

2. 当一个对象在方法中被定义后&＃xff0c;它被外部方法所引用&＃xff0c;则认为发生逃逸&＃xff0c;例如&＃xff1a;作为调用参数传递到其它方法中

public void test(){User user &＃61; new User();
}

在这样的一个方法中&＃xff0c;User对象在方法内部创建&＃xff0c;外部方法没有使用到该对象&＃xff0c;而且该对象也没有提供给外部访问&＃xff0c;因此该对象是没有逃逸出方法的&＃xff0c;可以将该对象放在栈上分配内存&＃xff0c; 此时它与栈帧共存亡&＃xff0c;当创建栈帧后&＃xff0c;User对象随着被分配内存&＃xff0c;栈帧被压入虚拟机栈&＃xff0c;方法调用结束后&＃xff0c;栈帧被弹出虚拟机栈&＃xff0c;User对象也随之消亡了。

public StringBuffer test(){StringBuffer sb &＃61; new StringBuffer();sb.append("hello");sb.append("world");return sb;
}

在这段程序中&＃xff0c;因为该方法将内部的StringBuffer对象作为返回值提供给外部使用了&＃xff0c;所以该对象是发生了逃逸的&＃xff0c;那么它就不能放在栈上分配内存&＃xff0c;我们可以改进一下这个程序&＃xff0c;使其内部对象不发生逃逸&＃xff1a;

public String test(){StringBuffer sb &＃61; new StringBuffer();sb.append("hello");sb.append("world");return sb.toString();
}

但事实上&＃xff0c;HotSpot虚拟机并未实现这一点&＃xff0c;它是通过 标量替换 的方式来提升性能&＃xff0c;意思是&＃xff1a;

某些对象可能不需要作为一个连续的内存结构存在也可以被访问&＃xff0c;那么对象的部分或全部就可以不存储在堆中&＃xff0c;而是存储在栈中

这里我们需要理解两个概念&＃xff1a;

1. 标量&＃xff1a;指的是一个无法再被分解的数据&＃xff0c;Java中的原始数据就是标量

2. 聚合量&＃xff1a;可以被细分成更小数据的数据称为聚合量&＃xff0c;比如Java中的对象

比如&＃xff1a;

public static void main(String[] args){User user &＃61; new User("zhangsan",20);
}class User{private String name;private Integer id;public User(String name,Integer age){this.name &＃61; name;this.age &＃61; age;}
}

首先对User对象进行逃逸分析&＃xff0c;发现该对象并不会发生逃逸&＃xff0c;所以我们可以考虑对其进行标量替换&＃xff0c;即&＃xff1a;将聚合量肢解成标量&＃xff1a;

public static void main(String[] args){String name &＃61; "zhangsan";Integer age &＃61; 20;
}

此时这些数据就会被放置在栈帧中的局部变量表中&＃xff0c;无需考虑GC问题&＃xff0c;也就提升了性能。

既然标量替换只是将聚合量替换成了标量&＃xff0c;那么对于最开始的问题&＃xff1a;堆是不是分配对象存储的唯一选择&＃xff0c;答案就是肯定的了&＃xff0c;聚合量被替换后已经不是对象了&＃xff0c;它是以一种特殊的方式将 "对象" 存储在栈上&＃xff0c;注意这个对象打了引号&＃xff0c;其实栈上存储的并不是对象&＃xff0c;而是对象肢解后的标量&＃xff0c;所以对象还是只能存储在堆上&＃xff0c;我们只能期待这方面的技术成熟&＃xff0c;能够真正实现对象在栈上的存储。