Java 细聊JVM之堆与GC

JVM内存体系结构

堆体系结构

一个JVM实例只存在一个堆内存，堆内存的大小是可以调节的。类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实信息，以方便执行器执行，堆内存分为三部分：

• Young Generation Space  新生区                    Young/New
• Tenure generation space  养老区                     Old/ Tenure
• Permanent Space              永久区                         Perm

堆内存逻辑上分为三部分：新生+养老+永久，但是物理上只有两部分：新生+养老

新生区

新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。

新生区又分为两部分： 伊甸区（Eden space）和幸存者区（Survivor pace） ，所有的类都是在伊甸区被new出来的。

幸存区有两个： 0区（Survivor 0 space）和1区（Survivor 1 space）。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存 0区。若幸存 0区也满了，再对该区进行垃圾回收，然后移动到 1 区。那如果1 区也满了呢？再移动到养老区。若养老区也满了，那么这个时候将产生MajorGC（FullGC），进行养老区的内存清理。若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryError”。

如果出现 java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。

原因有二：

1. Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。
2. 代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。

GC

GC作用域

GC种类

JVM在进行GC时，并非每次都对上面三个内存区域一起回收的， 大部分时候回收的都是指新生代。
因此GC按照回收的区域又分了两种类型，一种是普通GC (minor GC)，一种是全局GC ( major GC or Full GC)

Minor GC和Full GC的区别

普通GC (minor GC) :只针对新生代区域的GC,指发生在新生代的垃圾收集动作，因为大多数Java对象存活率都不高，所以Minor GC非常频繁，一般回收速度也比较快。

全局GC (major GC or Full GC) :指发生在老年代的垃圾收集动作，出现了Major GC，经常会伴随至少一次的Minor GC (但并不是绝对的)。Major GC的速度- - 般要比Minor GC 慢上10倍以上

堆GC角度划分

1：eden、SurvivorFrom 复制到 SurvivorTo，年龄+1 首先，当Eden区满的时候会触发第一次GC，把还活着的对象拷贝到SurvivorFrom 区，当 Eden 区再次触发 GC 的时候会扫描 Eden 区和 From 区域，对这两个区域进行垃圾回收，经过这次回收后还存活的对象，则直接复制到 To 区域（如果有对象的年龄已经达到了老年的标准，则赋值到老年代区），同时把这些对象的年龄+1

2：清空 eden、SurvivorFrom 然后，清空 Eden 和 SurvivorFrom 中的对象，也即复制之后有交换，谁空谁是to

3：SurvivorTo 和 SurvivorFrom 互换 最后，SurvivorTo 和 SurvivorFrom 互换，原 SurvivorTo 成为下一次 GC时 的 SurvivorFrom区。部分对象会在 From 和 To 区域中复制来复制去，如此交换15次(由JVM参数MaxTenuringThreshold决定，这个参数默认是15)，最终如果还是存活，就存入到老年代

HotSpot虚拟机规范

实际而言，方法区（Method Area）和堆一样，是各个线程共享的内存区域，它用于存储虚拟机加载的：类信息+普通常量+静态常量+编译器编译后的代码等等，虽然JVM规范将方法区描述为堆的一个逻辑部分，但它却还有一个别名叫做Non-Heap(非堆)，目的就是要和堆分开。

对于HotSpot虚拟机，很多开发者习惯将方法区称之为“永久代(Parmanent Gen)” ，但严格本质上说两者不同，或者说使用永久代来实现方法区而已，永久代是方法区(相当于是一个接口interface)的一个实现，jdk1.7的版本中，已经将原本放在永久代的字符串常量池移走。

永久区(元空间)

永久存储区是一个常驻内存区域，用于存放JDK自身所携带的 Class，Interface 的元数据，也就是说它存储的是运行环境必须的类信息，被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭 JVM 才会释放此区域所占用的内存。

堆参数调优

JDK 1.7

JDK 1.8

JDK 1.8之后将最初的永久代取消了，由元空间取代。

在Java8中，永久代已经被移除，被一个称为元空间的区域所取代。元空间的本质和永久代类似。

元空间与永久代之间最大的区别在于： 永久带使用的JVM的堆内存，但是java8以后的元空间并不在虚拟机中而是使用本机物理内存。

因此，默认情况下，元空间的大小仅受本地内存限制。类的元数据放入 native memory, 字符串池和类的静态变量放入 java 堆中，这样可以加载多少类的元数据就不再由MaxPermSize 控制, 而由系统的实际可用空间来控制。

参数含义

-Xms	设置初始分配大小，默认为物理内存的“1 / 64”
-Xmx	最大分配内存，默认为物理内存的“1 /4”
-XX:+ PrintGCDetails	输出详细的GC处理日志

 java 出厂默认设置 JVM 内存只占本地内存的 1/4左右

public class Main {
    public static void main(String[] args) {
        long maxMenory = Runtime.getRuntime().maxMemory();// 返回 Java 虚拟机试图使用的最大内存量
        long totalMemory = Runtime.getRuntime().totalMemory(); // 返回 Java 虚拟机中的内存总量
        System.out.println("[-Xmx] MAX_MEMORY = " + maxMenory + "(字节)" + (maxMenory / (double)1024/1024) + "MB");
        System.out.println("[-Xms] TOTAL_MEMORY = " + totalMemory + "(字节)" + (totalMemory / (double)1024/1024) + "MB");
    }
}

调整JVM参数

打开 IDEA，Run-->Edit Configrations修改VM options

-Xms1024m -Xmx1024m -XX:+PrintGCDetails

 然后运行下面从程序：

public class Main {
    public static void main(String[] args) {
        String str = "";
        while(true){
            str += str + new Random().nextInt(99999) + new Random().nextInt(99999);
        }
    }
}

运行结果

从输出结果我们可到以下信息：

1. 代码执行过程中发生了 GC(Yong GC)
2. 代码执行过程中发生了 Full GC
3. 代码报了 java.lang.OutOfMemoryError: Java heap space 异常
4. 报异常前最后执行的是 Full GC
5. 输出了 Heap 区域的内存分配情况

日志分析

Yong GC

[GC (Allocation Failure)

[PSYoungGen: 904K->856K(305664K)] 468915K->468867K(1005056K), 0.0025506 secs]

[Times: user=0.00 sys=0.00, real=0.00 secs] 

Full GC

报异常前的 Full GC

[Full GC (Allocation Failure) 

[PSYoungGen: 0K->0K(292864K)]

[ParOldGen: 489127K->489107K(699392K)] 489127K->489107K(992256K),

[Metaspace: 3482K->3482K(1056768K)], 0.1100469 secs]

[Times: user=0.58 sys=0.03, real=0.11 secs] 

GC分代收集算法

• 次数上频繁收集Young区
• 次数上较少收集Old区
• 基本不动元空间

GC四大算法

1.引用计数法

已经被淘汰，现在已经不用了。

缺点

• 每次对对象赋值时均要维护引用计数器，且计数器本身也有一定的消耗
• 较难处理循环引用

2.复制算法(Copying)

这个算法是GC中最重要的同时也是最常用的算法。

HotSpot JVM把年轻代分为了三部分：1个Eden区和2个Survivor区( 分别叫from和to)。默认比例为8:1:1，般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理)，这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过次Minor GC，年龄就会增加1岁， 当它的年龄增加到一定程度时，就会被移动到年老代中。 因为年轻代中的对象基本都是朝生夕死的(90%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。

在GC开始的时候，对象只会存在于Eden区和名为“From"的Survivor区，Survivor区“To"是空的。 紧接着进行GC，Eden区 中所有存活的对象都会被复制到"To"，而在“From"区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To"区域。经过这次GC后，Eden区和From区已经被清空。这个时候，"From"和"To" 会交换他们的角色，也就是新的"To"就是上次GC前的“From"，新的“From"就是上次GC前的"To"。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直 重复这样的过程，直到"To"区被填满，"To"区被填满之后，会将所有对象移动到年老代中。

因为Eden区对象一般存活率较低，一般的， 使用两块10%的内存作为空闲和活动区间，而另外80%的内存，则是用来给新建对象分配内存的。一旦发生GC，将10%的from活动区间与另外80%中存活的eden对象转移到10%的to空闲区间，接下来，将之前90%的内存全部释放，以此类推。

缺点

1. 它浪费了一半的内存
2. 如果对象的存活率很高，我们可以极端一点，假设是100%存活，那么我们需要将所有对象都复制一遍，并将所有引用地
   址重置一遍。 复制这一工作所花费的时间，在对象存活率达到一定程度时，将会变的不可忽视。所以从以上描述不难看出，复制算法要想使用，最起码对象的存活率要非常低才行，而且最重要的是，我们必须要克服50%内存的浪费。

3.标记清除算法(Mark-Sweep)

老年代一般是由标记清除或者是标记清除与标记整理的混合实现

当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将要回收的对象标记一遍， 最终统一回收这些对象，完成标记清理工作接下来便让应用程序恢复运行。

主要进行两项工作，第一项则是标记，第二项则是清除。

标记：从引用根节点开始标记遍历所有的GCRoots，先标记出要回收的对象。
清除：遍历整个堆，把标记的对象清除。

缺点

1. 它的缺点就是效率比较低(递归与全堆对象遍历)，而且在进行GC的时候，需要停止应用程序，这会导致用户体验非常差劲
2. 主要的缺点则是这种方式清理出来的空闲内存是不连续的，这点不难理解，我们的死亡对象都是随即的出现在内存的各个角落的，现在把它们清除之后，内存的布局自然会乱七八糟。而为了应付这一点，JVM就不得不维持一个内存的空闲列表，这又是一种开销。而且在分配数组对象的时候，寻找连续的内存空间会不太好找。

4.标记压缩算法(Mark-Compact)

这个算法实际就是标记清除算法+压缩(整理)算法。

标记/整理算法不仅可以弥补标记/清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价

缺点

标记/整理算法唯一的缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。
从效率上来说，标记/整理算法要低于复制算法。

5.标记-清除-压缩(Mark-Sweep-Compact)

由于前两种算法都有些不足的地方，所以延伸出来一种新的算法标记-清除-压缩(Mark-Sweep-Compact)，原理如下：

1. Mark- Sweep和Mark-Compact的结合。
2. 和Mark-Sweep- -致,当进行多次GC后才Compact。

总结

内存效率：复制算法>标记清除算法>标记整理算法(此处的效率只是简单的对比时间复杂度，实际情况不一定如此)。
内存整齐度：复制算法= 标记整理算法>标记清除算法。
内存利用率：标记整理算法=标记清除算法>复制算法。

可以看出，效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存，而为了尽量兼顾上面所提到的三个指标，标记/整理算法相对来说更平滑一些，但效率上依然不尽如人意，它比复制算法多了一一个标记的阶段，又比标记/清除多了一个整理内存的过程。

那种算法是最优算法？

没有最好的算法，只有最合适的算法。==========>分代收集算法。

年轻代(Young Gen)

年轻代特点是区域相对老年代较小，对像存活率低。

这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对像大小有关，因而很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。

老年代(Tenure Gen)

老年代的特点是区域较大，对像存活率高。

这种情况，存在大量存活率高的对像，复制算法明显变得不合适。一般是由标记清除或者是标记清除与标记整理的混合实现。

Mark阶段的开销与存活对像的数量成正比，这点上说来，对于老年代，标记清除或者标记整理有一 -些不符，但可以通过多核/线程利用，对并发、并行的形式提标记效率。

Sweep阶段的开销与所管理区域的大小形正相关，但Sweep"就地处决”的特点，回收的过程没有对像的移动。使其相对其它有对像移动步骤的回收算法，仍然是效率最好的。但是需要解决内存碎片问题。

Compact阶段的开销与存活对像的数据成开比，如上一条所描述，对于大量对像的移动是很大开销的，做为老年代的第一 选择并不合适。

基于上面的考虑， 老年代一般是由标记清除或者是标记清除与标记整理的混合实现。以 hotspot 中的 CMS 回收器为例，CMS 是基于 Mark-Sweep 实现的， 对于对像的回收效率很高，而对于碎片问题，CMS 采用基于 Mark-Compact 算法的 Serial Old 回收器做为补偿措施：当内存回收不佳(碎片导致的Concurrent Mode Failure时) ，将采用 Serial Old 执行 Full GC 以达到对老年代内存的整理。