持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第13天，点击查看活动详情
面试官：JVM中有哪些垃圾回收算法及各自的优劣有了解吗？
复制算法
针对新生代的垃圾回收算法，他叫做复制算法。简单来说，就是首先把新生代的内存分为两块。
接着假设有代码，在方法中创建了对象，此时对象就就会分配在新生代其中一块内存空间里。
而且是由栈内存中的这个方法的栈帧内的局部变量来引用的。假设与此同时，代码在不停的运行，然后大量的对象都分配在了新生代内存的其中一块内存区域里，也只会分配在那块区域里。而且分配过后，很快就失去了局部变量或者类静态变量的引用，成为了垃圾对象。
接着这个时候，新生代内存那块被分配对象的内存区域基本都快满了，再次要分配对象的时候，发现里面内存空间不足了。那么此时就会触发Minor GC去回收掉新生代那块被使用的内存空间的垃圾对象。
复制算法“，把新生代内存划分为两块内存区域，然后只使用其中一块内存，待那块内存快满的时候，就把里面的存活对象一次性转移到另外一块内存区域，保证没有内存碎片，接着一次性回收原来那块内存区域的垃圾对象，再次空出来一块内存区域。
从始至终，就只有一半的内存可以用，这样的算法显然对内存的使用效率太低了。
复制算法的优化
系统运行时，对JVM内存的使用模型，大体上就是我们的代码不停的创建对象然后分配在新生代里，但是一般很快那个对象就没人引用了，成了垃圾对象。
接着一段时间过后，新生代就满了，此时就会回收掉那些垃圾对象，空出来内存空间，给后续其他的对象来使用。但是我们之前分析过，其实绝大多数的对象都是存活周期非常短的对象，可能被创建出来1毫秒之后就没人引用了，他就是垃圾对象了。所以可能一次新生代垃圾回收过后，99%的对象其实都被垃圾回收了，就1%的对象存活了下来，可能就是一些长期存活的对象，或者还没使用完的对象。
所以实际上真正的复制算法会做出如下优化，把新生代内存区域划分为三块：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区去。因为之前分析了，每次垃圾回收可能存活下来的对象就1%，所以在设计的时候就留了一块100MB的内存空间来存放垃圾回收后转移过来的存活对象。比如Eden区+一块Survivor区有900MB的内存空间都占满了，但是垃圾回收之后，可能就10MB的对象是存活的。此时就把那10MB的存活对象转移到另外一块Survivor区域就可以，然后再一次性把Eden区和之前使用的Survivor区里的垃圾对象全部回收掉。
接着新对象继续分配在Eden区和另外那块开始被使用的Survivor区，然后始终保持一块Survivor区是空着的，就这样一直循环使用这三块内存区域。这么做最大的好处，就是只有10%的内存空间是被闲置的，90%的内存都被使用上了。无论是垃圾回收的性能，内存碎片的控制，还是说内存使用的效率，都非常的好。
进入老年代
其实可以理解为我们写的系统刚启动的时候，创建的各种各样的对象，都是分配在新生代里的。然后慢慢系统跑着跑着，新生代就满了，此时就会触发Minor GC，可能就1%的少量存活对象转移到空着的Survivor区中。然后系统继续运行，继续在Eden区里分配各种对象，大概就是这个过程。我们写的系统中有些对象是长期存在的对象，他是不会轻易的被回收掉的。
所以你无论新生代怎么垃圾回收，类似这种对象都不会被回收掉的。此时这类对象每次在新生代里躲过一次GC被转移到一块Survivor区域中，此时他的年龄就会增长一岁。默认的设置下，当对象的年龄达到15岁的时候，也就是躲过15次GC的时候，他就会转移到老年代里去。这个具体是多少岁进入老年代，可以通过JVM参数“-XX:MaxTenuringThreshold”来设置，默认是15岁。
动态对象年龄判断
这里跟这个对象年龄有另外一个规则可以让对象进入老年代，不用等待15次GC过后才可以。他的大致规则就是，假如说当前放对象的Survivor区域里，一批对象的总大小大于了这块Survivor区域的内存大小的50%，那么此时大于等于这批对象年龄的对象，就可以直接进入老年代了。
假设Survivor2区有两个对象，这俩对象的年龄一样，都是2岁，然后俩对象加起来对象超过了50MB，超过了Survivor2区的100MB内存大小的一半了，这个时候，Survivor2区里的大于等于2岁的对象，就要全部进入老年代里去。这就是所谓的动态年龄判断的规则，这条规则也会让一些新生代的对象进入老年代。
其实说白了，无论是15岁的那个规则，还是动态年龄判断的规则，都是希望那些可能是长期存活的对象，尽早进入老年代。既然你是长期存活的，那么老年代才是属于你的地盘，别赖在新生代里占地方了。
大对象直接进入老年代
有一个JVM参数，就是“-XX:PretenureSizeThreshold”，可以把他的值设置为字节数，比如“1048576”字节，就是1MB。
他的意思就是，如果你要创建一个大于这个大小的对象，比如一个超大的数组，或者是别的啥东西，此时就直接把这个大对象放到老年代里去。压根儿不会经过新生代。之所以这么做，就是要避免新生代里出现那种大对象，然后屡次躲过GC，还得把他在两个Survivor区域里来回复制多次之后才能进入老年代，那么大的一个对象在内存里来回复制，不是很耗费时间吗？所以说，这也是一个对象进入老年代的规则。
面试官：Minor GC后的对象太多无法放入Survivor区怎么办？
假设在发生GC的时候，发现Eden区里超过150MB的存活对象，此时没办法放入Survivor区中，此时该怎么办呢？这个时候就必须得把这些对象直接转移到老年代去。
老年代空间分配担保规则
这个时候大家又想提一个问题了，如果新生代里有大量对象存活下来，确实是自己的Survivor区放不下了，必须转移到老年代去。那么如果老年代里空间也不够放这些对象呢？这该咋整呢？
首先，在执行任何一次Minor GC之前，JVM会先检查一下老年代可用的可用内存空间，是否大于新生代所有对象的总大小。因为最极端的情况下，可能新生代Minor GC过后，所有对象都存活下来了，那岂不是新生代所有对象全部要进入老年代？
如果说发现老年代的内存大小是大于新生代所有对象的，此时就可以放心大胆的对新生代发起一次Minor GC了，因为即使Minor GC之后所有对象都存活，Survivor区放不下了，也可以转移到老年代去。
但是假如执行Minor GC之前，发现老年代的可用内存已经小于了新生代的全部对象大小了。
那么这个时候是不是有可能在Minor GC之后新生代的对象全部存活下来，然后全部需要转移到老年代去，但是老年代空间又不够？理论上，是有这种可能的。
所以假如Minor GC之前，发现老年代的可用内存已经小于了新生代的全部对象大小了，就会看一个“-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”内存溢出了。因为内存实在是不够了，你还是要不停的往里面放对象，当然就崩溃了。
老年代垃圾回收算法
老年代触发垃圾回收的时机，一般就是两个：
- Minor GC之前，一通检查发现很可能Minor GC之后要进入老年代的对象太多了，老年代放不下，此时需要提前触发Full GC然后再带着进行Minor GC；
- Minor GC之后，发现剩余对象太多放入老年代都放不下了。
那么对老年代进行垃圾回收采用的是什么算法呢？简老年代采取的是标记整理算法，这个过程说起来比较简单，首先标记出来老年代当前存活的对象，这些对象可能是东一个西一个的。接着会让这些存活对象在内存里进行移动，把存活对象尽量都挪动到一边去，让存活对象紧凑的靠在一起，避免垃圾回收过后出现过多的内存碎片，然后再一次性把垃圾对象都回收掉。
这个老年代的垃圾回收算法的速度至少比新生代的垃圾回收算法的速度慢10倍。如果系统频繁出现老年代的Full GC垃圾回收，会导致系统性能被严重影响，出现频繁卡顿的情况。
其实所谓JVM优化，就是尽可能让对象都在新生代里分配和回收，尽量别让太多对象频繁进入老年代，避免频繁对老年代进行垃圾回收，同时给系统充足的内存大小，避免新生代频繁的进行垃圾回收。
