复制算法、Eden区和Survivor区

 

首先我们就来探索一下对于JVM堆内存中的新生代区域，是怎么进行垃圾回收的。

 

实际上JVM是把新生代分为三块区域的：1个Eden区，2个Survivor区。

 

其中Eden区占用80%的内存空间，每块Survivor各占用10%的内存空间。比如Eden区有800M，那么每个Survivor区就有100M。

 

平时可以使用的区域是Eden区和其中一块Survivor区，也就是900M的内存空间。

 

 

 

 

 

 

 

刚开始创建对象的时候，对象都是分配在Eden区中的，如果Eden区快满了，就会触发垃圾回收 Young GC，使用的就是复制算法进行垃圾回收，流程如下：

 

首先会把Eden区中的存活对象一次性转入其中一块空着的Survivor区中。

 

然后清空Eden区，之后新创建的对象就再次被放入了Eden区中了。

 

如果下次Eden区快满了，就会再次触发Young GC，这个时候会把Eden区和存在对象的Survivor区中存活的对象转移到另一块空着的Survivor区中，并清空Eden区和之前存在对象的Survivor区。

 

这就是复制算法的流程。

 

一直要保持一个Survivor区是空的以供复制算法垃圾回收，而这块区域只占用整个内存的10%，其他90%的内存都能被使用，可见内存利用率还是相当高的。

 

 

 

什么时候进入老年代

接下来我们就来看一下什么时候会进入老年代，这个问题上篇文章轻松理解JVM的分代模型中已经简单的介绍过了，今天会对此展开进行详细探索。

 

 

 

1.躲过15次GC后进入老年代

 

在默认的情况下，如果新生代中的某个对象经历了15次GC后，还是没有被回收掉，那么它就会被转入到老年代中。

 

这个具体躲过多少次，是可以自己设置的，通过JVM参数“-XX:MaxTenuringThreshold”来设置，默认是15.

 

2.动态对象年龄判断

 

另一种判断方式也可以进入老年代，是不用等待GC15次的。

 

它的大致规则是，假如一批对象总大小大于了当前Survivor区域内存的大小的50%，那么大于等于这批对象年龄的对象就会被转移到老年代。

 

小伙伴们可能觉得有些没看明白这句话的意思，没关系，我们看一下图

 

 

 

 

 

 

 

 假设Survivor中有两个对象，它们都经历过2次GC，年龄是2岁，而且两个对象加在一起的大小大于50M，也就是超过了Survivor区域内存大小的50%，那么这个时候，Survivor区域中年龄大于等于2岁的对象就要全部转移到老年代中。

 

这就是所谓的动态年龄判断规则。

 

要注意的是，年龄1+年龄2+年龄n的多个年龄对象大小超过Survivor区的50%，此时会把年龄n以上的对象放入老年代。

 

3.大对象直接进入老年代

 

有一个JVM参数"-XX:PretenureSizeThreshold"，默认值是0，表示任何情况都先把对象分配给Eden区。

 

我们可以给他设置一个字节数1048576字节，也就是1M。

 

它的意思就是当要创建的对象大于1M的时候，就会直接把这个对象放入到老年代中，压根不会经过新生代。

 

因为大对象在经历复制算法进行GC的时候是会降低性能的，所以直接放入老年代就可以了。

 

4.Young GC后存活的对象太多无法放入Survivor区

 

还有一种情况，就是Young GC后存活的对象太多，Survivor区放不下了，这个时候就会把这些对象直接转移到老年代中。

 

这里我们就要思考一个问题了，如果老年代也放不下了怎么办呢？

 

 

 

老年代空间分配担保原则

首先，在执行任何一次Young GC之前，JVM都会先检查一下老年代可用的内存空间是否大于新生代所有对象的总大小。

 

为啥要检查这个呢？因为在极端情况下，Young GC后，新生代中所有的对象都存活下来了，那就会把所有新生代中的对象放入老年代中。

 

如果说老年代可用内存大于新生代对象总大小，那么就可以放心的执行Young GC了。

 

但是如果老年代的可用内存小于新生代对象的总大小，这个时候就会看一个参数“-XX:HandlePromotionFailure”是否设置为true了（可以认为jdk7之后，默认设置为true）。

 

如果设置为true，那么进入下一步判断，就是看看老年代可用的内存，是否大于之前每次Young GC后进入老年代对象的平均大小。

 

如果说老年代的可用内存小于平均大小，或者说参数没有设置成true，那么就会直接触发“Full GC”，就是对老年代进行垃圾回收，腾出空间后，再进行Young GC。

 

 

 

如果上边两种情况判断成功，没有执行Full GC，进行了Young GC，有以下几种可能：

 

1.如果Young GC后，存活的对象大小小于Survivor区域的大小，那么直接进入Survivor区域即可。

 

2.如果Young GC后，存活的对象大小大于Survivor区域的大小，但是小于老年代可用内存大小，那就直接进入老年代。

 

3.很不幸，老年代可用空间也放不下这些存活对象了，那就会发生“Handle Promotion Failure”的情况，触发Full GC。

 

 

 

如果Full GC后，老年代可用内存还是不够，那么就会导致OOM内存溢出了。

 

这段内容可能比较繁琐，结合内存模型，多看两遍相信小伙伴们是可以读懂的。

 

 

 

 

 

老年代的垃圾回收算法

接下来我们就来介绍一下老年代的垃圾回收算法，标记整理算法，理解起来还是比较容易的。

 

 

 

 

 

 

 

开始时我们的对象是胡乱分布的，经过垃圾回收后，会标记出哪些是存活对象，哪些是垃圾对象，而后会把这些存活对象在内存中进行整理移动，尽量都挪到一边去靠在一起，然后再把垃圾对象进行清除，这样做的好处就是避免了垃圾回收后产生大片的内存碎片。

 

但是这一过程其实是比较耗时的，至少要比新生代的垃圾回收算法慢10倍。

 

所以如果系统频繁出现Full GC，会严重影响系统性能，出现频繁卡顿。

 

所以JVM优化的一大问题就是减少Full GC频率。

 

 

 

垃圾回收器

新生代和老年代进行垃圾回收的时候是通过不同的垃圾回收器进行回收的。

 

Seral和Seral Old垃圾回收器：分别用于回收新生代和老年代。

 

工作原理是单线程运行，垃圾回收的时候会停止我们系统的其他线程，让系统卡死不动，然后执行垃圾回收，这个现在基本已经不会使用了

 

ParNew和CMS垃圾回收器：分别用于回收新生代和老年代。

 

它们都是多线程并发的，性能更好，现在一般是线上生产系统的标配。

 

G1垃圾回收器：统一收集新生代和老年代，采用了更加优秀的算法机制。

 

 

 

这里只是给大家做一下简单的介绍，更详细的内容以后文章会单独解析。

 

 

 

Stop the World

JVM最大的痛点就是Stop the World了。

 

在垃圾回收的时候，尽可能的要让垃圾回收器专心的去做垃圾回收的操作（防止垃圾回收的时候还在创建新对象，那不就乱套了吗），所以此时JVM会在后台进入Stop the World状态。

 

进入这个状态后，会直接停止我们系统的工作线程，让我们的代码不在运行。

 

接着垃圾回收完成后，会恢复工作线程，代码就可以继续运行了。

 

所以说只要是经历GC，其实就会让系统卡死一段时间，新生代的垃圾回收可能感受不到太多，单老年代的垃圾回收耗时更多，可能会明显的感觉到系统的卡死。

 

所以说无论是新生代的垃圾回收还是老年代的垃圾回收，我们都应该尽量的减少它们的频率。