解密 JVM内存区域 堆详解以及如何设置大小

解密 JVM内存区域 堆详解以及如何设置大小

一个java进程对应一个JVM，一个JVM实例只存在一个堆内存，堆区在JVM启动的时候就被创建，其空间大小也被确定下来，但堆空间的大小是可以通过JVM参数调节的，所有的线程共享堆。

堆的内存结构

• Young Generation Space（新生代）
• Old Generation Space（老年代）
• Perm Space（永久代）-

其中新生代又可细分为：

• Eden（伊甸园区）
• Survivor（幸存区）

从JDK1.8开始，JVM规范摒弃了方法区的概念，取而代之的是Meta Space（元空间），使用的是物理内
存。

通过两个JVM参数可以设置堆的初始内存和最大内存：
-Xms：设置堆的初始内存
-Xmx：设置堆的最大内存
我们可以先来看看自己的JVM分配的堆内存情况：

public static void main(String[] args) {// 获取堆空间的内存总量long totalMemory = Runtime().totalMemory() / 1024 / 1024;// 获取堆空间试图使用的最大内存long maxMemory = Runtime().maxMemory() / 1024 / 1024;System.out.println(totalMemory + "M");System.out.println(maxMemory + "M");
}
运行结果：123M
1799M

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

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

575M
575M

我们运行一个java 进程TestDemo，然后通过该id查询内存分配情况，输入 jstat -gc 1860 ：

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

原来，堆中的两块幸存区是不会被同时使用的，这涉及到垃圾收集中的复制算法，该算法总是使用其中一块幸存区空间，当伊甸园区和该幸存区空间满了以后，会触发一次GC，将还存活的对象复制到另一块幸存区上，然后将之前的空间直接清除。
当我们减去其中一个幸存区的内存：614400 - 25600 = 58800 ，对其除以1024，得到575M，这就是为什么程序的运行结果是575M的原因了。

我们也可以使用JVM参数 -XX:+PrintGCDetails 来查看内存的详细信息：

再次运行java程序，可以看到输入结果：

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就是两块幸存区的空间。

介绍一款JDK提供的工具，通过它可以更直观地看到堆中的内存分配及变化：

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

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

将程序重新运行起来，然后查看jvisualvm工具：

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

新生代与老年代

存储在JVM中的Java对象大体可分为两类：

• 生命周期较短的瞬时对象，这类对象的创建和死亡都非常迅速
• 生命周期很长的对象，某些对象甚至能够存活到JVM的生命结束

为此，堆空间才被分为新生代和老年代，并将生命周期很短的对象放在新生代，将生命周期很长的对象放在老年代，因为在每次GC时，垃圾回收器都会去判断当前对象是否可以被回收，而这些生命周期很长的对象每次都被垃圾回收器扫描，但每次都不回收，故而可以将这些对象放在老年代，并减少对老年代的GC次数，从而将GC的重心放在新生代上。
通过这两个区域对象的生命周期不同，也可以设置不同的垃圾回收算法，比如对新生代中的对象采用复制算法，因为该区域的对象生命周期短，消亡快，所以当发生GC时并不会存在太多存活的对象，而对老年代则采用标记-清除算法。

新生代与老年代内存空间的默认比例为 1:2 ，我们可以通过虚拟机参数来修改比例：

-XX:NewRatio=3

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

-XX:SurvivorRatio=6

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

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

对象创建过程

对象的创建是一个非常复杂的过程，它的具体流程如下：

1. 创建的对象首先存放在Eden区
2. 当Eden区的空间满了以后，此时创建对象便会触发GC（Minor GC），将Eden区中存活的对象放入幸存区，然后清除Eden区
3. 当触发Eden区的GC时，会将Eden区中还存活的对象放入幸存区S0
4. 当Eden区满了再次触发GC时，会将Eden区中存活的对象和幸存者S0中仍然存活的对象放入幸存区S1
5. 若再一次触发Eden区的GC，则将存活的对象又重新放回幸存区S0，依次循环
6. 存活的对象被放入幸存区一次，年龄就会加1，当对象的年龄到达15岁时，该对象就会被晋升到老年代

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

接下来我们就来介绍一下垃圾回收类型，大体可分为两类：

• 部分收集（Partial GC）
• 整堆收集（Full GC）——针对整个堆结构和方法区的垃圾回收

其中部分收集又分为：

• 新生代收集（Minor GC / Young GC）——针对新生代的垃圾回收
• 老年代收集（Major GC / Old GC）——针对老年代的垃圾回收
• 混合收集（Mixed GC）——针对整个新生代以及部分老年代的垃圾回收

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

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

最后是Full GC，它触发的情况有以下五种：

1. 调用System类的gc()方法，但这只是告诉JVM应该进行GC，并不代表JVM会立马执行Full GC
2. 老年代内存不足
3. 方法区内存不足
4. Minor GC过后进行老年代的平均大小 大于 老年代的可用内存
5. 由Eden区、From区向To区复制时，对象大小大于To区可用内存，则把该对象晋升到老年代，而老年代也没有足够的内存存放该对象

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

事实上，S0就是From区，S1就是To区，但由于复制-清除算法的过程，它会将第一次Minor GC后存活的对象放入From区，此时To区是空的；当第二次Minor GC时，垃圾回收器会扫描Eden区和From区，并将还存活的对象放入To区，然后清空Eden和From区，此时From区会和To区做一个交换，这样空的From区就会作为下一次GC的To区继续放置存活的对象，即：复制之后有交换，谁空谁就做To区 。
因为Full GC覆盖的范围比较广，损耗的时间也是比较长的，所以在开发中应该尽量避免Full GC的发生。

下面例举一些堆中常用的设置参数：
-XX:+PrintFlagsInitial：查看所有的参数默认值
-XX:+PrintFlagsFinal：查看所有的参数最终值
-Xms：设置初始堆内存
-Xmx：设置最大堆内存
-Xmn：设置新生代的内存
-XX:NewRatio：配置新生代与老年代在堆结构的占比
-XX:SurvivorRatio：配置新生代中Eden区与Survivor区的占比
-XX:MaxTenuringThreshold：设置新生代垃圾的最大年龄
-XX:+PrintGCDetails：输出GC的详细日志