GC实现机制

一、GC实现机制-我们为什么要去了解GC和内存分配？

说道这个问题，我有一个简单的回答：在真实工作中的项目中，时不时的会发生内存溢出、内存泄露的问题，这也是不可避免的Bug，这些潜在的Bug在某些时候会影响到项目的正常运行，如果你的项目没有合理的进行业务内存分配，将会直接影响到的项目的并发处理，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节，而了解了GC实现机制则是我们一切监控和调节的前提。

二、GC实现机制-Java虚拟机将会在什么地方进行垃圾回收？

说起垃圾回收的场所，了解过JVM（Java Virtual Machine Model）内存模型的朋友应该会很清楚，堆是Java虚拟机进行垃圾回收的主要场所，其次要场所是方法区。

三、GC实现机制-Java虚拟机具体实现流程

我们都知道在Java虚拟机中进行垃圾回收的场所有两个，一个是堆，一个是方法区。在堆中存储了Java程序运行时的所有对象信息，而垃圾回收其实就是对那些“死亡的”对象进行其所侵占的内存的释放，让后续对象再能分配到内存，从而完成程序运行的需要。关于何种对象为死亡对象，在下一部分将做详细介绍。Java虚拟机将堆内存进行了“分块处理”，从广义上讲，在堆中进行垃圾回收分为新生代（Young Generation）和老生代（Old Generation）；从细微之处来看，为了提高Java虚拟机进行垃圾回收的效率，又将新生代分成了三个独立的区域（这里的独立区域只是一个相对的概念，并不是说分成三个区域以后就不再互相联合工作了），分别为：Eden区（Eden Region）、From Survivor区（Form Survivor Region）以及To Survivor（To Survivor Region），而Eden区分配的内存较大，其他两个区较小，每次使用Eden和其中一块Survivor。Java虚拟机在进行垃圾回收时，将Eden和Survivor中还存活着的对象进行一次性地复制到另一块Survivor空间上，直到其两个区域中对象被回收完成，当Survivor空间不够用时，需要依赖其他老年代的内存进行分配担保。当另外一块Survivor中没有足够的空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老生代，在老生代中不仅存放着这一种类型的对象，还存放着大对象（需要很多连续的内存的对象），当Java程序运行时，如果遇到大对象将会被直接存放到老生代中，长期存活的对象也会直接进入老年代。如果老生代的空间也被占满，当来自新生代的对象再次请求进入老生代时就会报OutOfMemory异常。新生代中的垃圾回收频率高，且回收的速度也较快。就GC回收机制而言，JVM内存模型中的方法区更被人们倾向的称为永久代（Perm Generation），保存在永久代中的对象一般不会被回收。其永久代进行垃圾回收的频率就较低，速度也较慢。永久代的垃圾收集主要回收废弃常量和无用类。以String常量abc为例，当我们声明了此常量，那么它就会被放到运行时常量池中，如果在常量池中没有任何对象对abc进行引用，那么abc这个常量就算是废弃常量而被回收；判断一个类是否“无用”，则需同时满足三个条件：

（1）、该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例；

（2）、加载该类的ClassLoader已经被回收

（3）、该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

虚拟机可以对满足上述3个条件的无用类进行回收，这里说的是可以回收而不是必然回收。

大多数情况下，对象在新生代Eden区中分配，当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC；同理，当老年代中没有足够的内存空间来存放对象时，虚拟机会发起一次Major GC/Full GC。只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full CG。

虚拟机通过一个对象年龄计数器来判定哪些对象放在新生代，哪些对象应该放在老生代。如果对象在Eden出生并经过一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并将该对象的年龄设为1。对象每在Survivor中熬过一次Minor GC，年龄就增加1岁，当他的年龄增加到最大值15时，就将会被晋升到老年代中。虚拟机并不是永远地要求对象的年龄必须达到MaxTenuringThreshold才能晋升到老年代，如果在Survivor空间中所有相同年龄的对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需等到MaxTenuringThreshold中要求的年龄。

四、GC实现机制-Java虚拟机如何实现垃圾回收机制

（1）、引用计数算法（Reference Counting）

给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的，这就是引用计数算法的核心。客观来讲，引用计数算法实现简单，判定效率也很高，在大部分情况下都是一个不错的算法。但是Java虚拟机并没有采用这个算法来判断何种对象为死亡对象，因为它很难解决对象之间相互循环引用的问题。

public class ReferenceCountingGC{
public Object object = null;
private static final int OenM = 1024 * 1024;
private byte[] bigSize = new byte[2 * OneM];
public static void testCG(){
ReferenceCountingGC objA = new ReferenceCountingGC();
ReferenceCountingGC objB = new ReferenceCountingGC();
objA.object = null;
objB.object = null;
System.gc();
}
}

在上述代码段中，objA与objB互相循环引用，没有结束循环的判断条件，运行结果显示Full GC，就说明当Java虚拟机并不是使用引用计数算法来判断对象是否存活的。
（2）、可达性分析算法（Reachability Analysis）

这是Java虚拟机采用的判定对象是否存活的算法。通过一系列的称为“GC Roots"的对象作为起始点，从这些结点开始向下搜索，搜索所走过的路径称为饮用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。可作为GC Roots的对象包括：虚拟机栈中引用的对象、方法区中类静态属性引用的对象、方法区中常量引用的对象。本地方法栈JNI引用的对象。

在上图可以看到GC Roots左边的对象都有引用链相关联，所以他们不是死亡对象，而在GCRoots右边有几个零散的对象没有引用链相关联，所以他们就会别Java虚拟机判定为死亡对象而被回收。

五、GC实现机制-何为死亡对象？

Java虚拟机在进行死亡对象判定时，会经历两个过程。如果对象在进行可达性分析后没有与GC Roots相关联的引用链，则该对象会被JVM进行第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法，如果当前对象没有覆盖该方法，或者finalize方法已经被JVM调用过都会被虚拟机判定为“没有必要执行”。如果该对象被判定为没有必要执行，那么该对象将会被放置在一个叫做F-Queue的队列当中，并在稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行它，在执行过程中JVM可能不会等待该线程执行完毕，因为如果一个对象在finalize方法中执行缓慢，或者发生死循环，将很有可能导致F-Queue队列中其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃。如果在finalize方法中该对象重新与引用链上的任何一个对象建立了关联，即该对象连上了任何一个对象的引用链，例如this关键字，那么该对象就会逃脱垃圾回收系统；如果该对象在finalize方法中没有与任何一个对象进行关联操作，那么该对象会被虚拟机进行第二次标记，该对象就会被垃圾回收系统回收。值得注意的是finaliza方法JVM系统只会自动调用一次，如果对象面临下一次回收，它的finalize方法不会被再次执行。

六、再探GC实现机制-垃圾收集算法

（1）、标记-清除算法（Mark-Sweep）

用在老生代中， 先对对象进行标记，然后清楚。标记过程就是第五部分提到的标记过程。值得注意的是，使用该算法清楚过后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

（2）、复制算法（Copying）

用在新生代中，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活的对象复制到另外一块上，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可。

七、空间分配担保策略-GC过程中的内存担保机制

当出现大量对象在Minor GC后仍然存活的情况，就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。与生活中的银行贷款类似，老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会存活下来在实际完后才能内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多空间。如果出现担保失败，就只好重新发起一次Full GC来进行内存的分配。

内存分配与回收策略

Java 技术体系中所提倡的自动内存管理最终可以归结为自动化地解决两个问题：给对象分配内存以及回收分配对对象的内存。

对象优先在Eden分配

大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次 Minor Gc.

大对象直接进入老年代

所谓大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是字节数组等。

长期存活的对象将进入老年代

虚拟机给每个对象定义了一个对象年龄的计数器。如果对象在Eden出生并经过Minor Gc仍然存活，并且能够被Survior容器容纳，将被移到Survivior空间中，并且年龄设置为1.对象在Survivor区中每“熬过”一次Minor Gc，年龄就增加1岁，当它的年龄达到一定程度（默认为15岁），就被晋升到老年代中。

动态对象年龄判断

如果在Survivor 空间中相同年龄的对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需等到MaxTenringThreshold中要求的年龄。

空间分配担保

在发生Minor Gc之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象的总空间，如果这个条件成立，那么Minnor Gc可用确保是安全的。如果不成立，则虚拟机会查看HandlePromotyionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试一次 Minnor Gc；如果小于，或者HandlePromotyionFailure设置不允许冒险，那么这时要进行一次Full Gc.

下面解释一下“冒险”是冒了什么风险，前面提到过，新生代使用复制收集算法，但为了内存利用率，只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。与生活中的贷款担保类似，老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行Full Gc来让老年代腾出更多的空间。

取平均值进行比较其实仍然是一种动态概率的手段，也就是说，如果某次Minor GC存活后的对象突增，远远高于平均值的话，依然会导致担保失败（Handle Promotion Failure）。如果出现了HandlePromotionFailure失败，那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子是最大的，但大部分情况下都还是会将HandlePromotionFailure开关打开，避免Full Gc过于频繁。