垃圾回收算法

上一篇文章我们介绍了堆内存分配、jvm分代模型、垃圾回收触发条件以及jvm的一些核心参数设置，理解了这些内容之后，我们从本文开始介绍jvm的垃圾回收算法。

复制算法

针对新生代的垃圾回收算法叫做。简单来说，首先把新生代的内存分为两块。当有对象被创建就会分配在其中一块内存空间里，对象被方法局部变量来引用。随着系统的运行，大量的对象被创建并分配在新生代的其中一块内存区域里，而且分配过后，很快就失去了局部变量或者类静态变量的引用，成为了垃圾对象。当新生代那块被分配对象的内存区域基本快满了，再次要分配对象的时候发现内存空间不足了，那么此时就会触发Minor GC回收掉新生代那块被使用的内存空间的垃圾对象。

假设现在采用的垃圾回收思路就是直接对被使用的那块内存区域中的垃圾对象进行标记，找出可以被垃圾回收的对象，然后直接对那块内存区域中的对象进行垃圾回收，把内存空出来。
？
用这种思路去做垃圾回收，可能回收完毕之后。那么什么是内存碎片呢？我们下面来看一张图，这样会更加直观，示例图如下：

neicun.jpg

xinshengdai.jpg

eden.jpg

1个Eden区，2个Survivor区，其中Eden区占80%内存空间，每一块Survivor区各占10%内存空间，比如说Eden区有800MB内存，每一块Survivor区就100MB内存。平时可以使用的就是Eden区和其中一块Survivor区，那么相当于就是有900MB的内存是可以使用的。
但是刚开始的时候对象都是分配在Eden区内的，如果Eden区快满了，此时就会触发垃圾回收，就会把Eden区中的存活对象都一次性转移到一块空着的Survivor区。接着Eden区就会被清空，然后再次分配新对象到Eden区，然后Eden区和一块Survivor区里是有对象的，其中Survivor区里放的是上一次Minor GC后存活的对象。
如果Eden区再次被放满，那么再次触发Minor GC就会把Eden区和放着上一次Minor GC后存活对象的Survivor区内的存活对象，转移到另外一块Survivor区里，然后再一次性把Eden区和之前使用的Survivor区里的垃圾对象全部回收掉。

对象什么时候从年轻代进入老年代

。其实大家可以理解为我们写的系统刚启动的时候，创建的各种各样的对象，都是分配在新生代里的，然后随着系统的运行，新生代就满了，此时就会触发Minor GC，可能就1%的少量存活对象转移到空着的Survivor区中。随着系统继续运行，不断重复这个过程。
那么之前给大家讲过，我们写的系统中有些对象是长期存在的，它是不会轻易的被回收掉的，比如下面这段代码：

public class User {
      private static Role role = new Role();
}

只要“User”这个类还存在，那么它的静态变量“role”就会长期引用“Role”实例对象，所以你无论新生代怎么垃圾回收，类似这种对象都不会被回收掉。这类对象每次在新生代里躲过一次GC被转移到一块Survivor区域中后，它的年龄就会增长一岁，默认的设置下，当对象的年龄达到15岁的时候，也就是躲过15次GC的时候，它就会转移到老年代里去。这个具体是多少岁进入老年代，可以通过jvm参数“-XX:MaxTenuringThreshold”来设置，默认是15岁。

根据对象年龄，有另外一个规则可以让对象进入老年代，不用等15次GC过后才可以。大致的规则是，假如说当前放对象的Survivor区域里一批对象的总大小大于这个Survivor区域的内存大小的50%，那么大于等于这批对象年龄的对象就可以直接进入老年代了。举个栗子：假设Survivor区大小100MB，有两个对象，这俩对象的年龄一样，都是2岁，然后两个对象加起来超过了50MB，超过了Survivor区的内存大小的一半了，这个时候，Survivor区里的大于等于2岁的对象就要全部进入老年代。这就是的规则，这条规则也会让一些新生代的对象进入老年代。
实际上这个规则运行的时候是如下逻辑：年龄1+年龄2+年龄N的多个年龄对象总和超过了Survivor区域的50%，此时就会把年龄N以上的对象都放入老年代。
其实说白了，无论是15岁的那个规则，还是动态年龄判断的规则，都是希望那些可能是长期存活的对象尽早进入老年代。

有一个jvm参数叫“-XX:PretenureSizeThreshold”，可以把它的值设置为字节数，比如“1048576”字节，就是1MB。它的意思是如果你要创建一个大于这个大小的对象，比如一个超大的数组，此时就直接把这个大对象放到老年代，压根就不会经过新生代。之所以这么做，就是要避免新生代里出现那种大对象，屡次躲过GC，还得把他在两个Survivor区里来回复制多次之后才能进入老年代，那么大的一个对象在内存里来回复制，是相当耗费时间的。所以说这也是一个对象进入老年代的规则。

现在有一个比较大的问题，就是如果在Minor GC之后发现剩余的存活对象太多了，无法放入另外一块Survivor区怎么办？假设Survivor区有100MB内存，发生GC的时候发现Eden区里有超过150MB的存活对象，没办法放入Survivor区里，此时怎么办？

老年代空间分配担保规则。
这个时候大家又想提另外一个问题，如果老年代里的空间也不够放这些对象呢？别急，我们来一步一步分析。首先，在执行任何一次Minor GC之前，jvm会先检查一下老年代可用的内存空间是否大于新生代所有对象的总大小。为什么检查这个呢？因为最极端的情况下，可能新生代Minor GC过后所有对象都存活了下来，那岂不是新生代所有对象全部要进入老年代？
如果说发现老年代的可用内存大小是大于新生代所有对象的，此时就可以放心大胆的对新生代发起一次Minor GC了，因为即使Minor GC之后所有对象都存活了，Survivor区放不下了，也可以转移到老年代里去。假设执行Minor GC之前发现老年代的可用内存已经小于了新生代的全部对象大小了，那么这个时候是不是有可能发生在Minor GC之后新生代的对象全部存活下来，然后全部需要转移到老年代，但是老年代空间又不够的情况？理论上是有这种可能的！

这个时候jvm就会看一个叫“-XX:-HandlePromotionFailure”的参数是否设置了，如果有这个参数，那么就会继续进行下一步判断，就是看老年代的内存大小是否大于之前每一次Minor GC后进入老年代的对象的平均大小。

举个栗子，之前每次Minor GC后，平均有10MB左右的对象会进入老年代，那么此时老年代可用内存大于10MB，这就说明，很可能这次Minor GC过后也是差不多10MB左右的对象会进入老年代，此时老年代空间是够的。

如果上面那个步骤判断失败了，或者是“-XX:-HandlePromotionFailure”参数没设置，此时就会直接出发一次 “Full GC”，就是对老年代进行垃圾回收，尽量腾出来一些内存空间，然后再执行Minor GC。如果上面两个步骤都成功了，那么就是说可以冒点风险尝试一下Minor GC。此时进行Minor GC有几种可能。

第一种可能，Minor GC过后，剩余的存活对象的大小，小于Survivor区的内存空间，那么此时存活对象进入Survivor区域即可。
第二种可能，Minor GC过后，剩余的存活对象的大小，大于Survivor区域的内存空间，但是小于老年代可用内存空间，此时直接进入老年代即可。
第三种可能，Minor GC过后，剩余的存活对象的大小，大于Survivor区域的内存空间，也大于老年代可用内存空间，此时老年代都放不下这些存活对象了，就会发生“Handle Promotion Failure”的情况，这个时候就会触发一次“Full GC”。

Full GC就是对老年代进行垃圾回收，同时也一般会对新生代进行垃圾回收。因为这个时候必须把老年代里没人引用的对象给回收掉，然后才可能让Minor GC过后剩余的存活对象进入老年代里。如果Full GC过后老年代还是没有足够的空间存放Minor GC过后的剩余存活对象，那么此时就会导致所谓的“OOM”内存溢出了。

适合老年代垃圾回收的算法——标记整理算法

简单来说，老年代采取的是。大家看下图：

lnd.jpg