重识JVM（四）：GC

垃圾收集（GC）是java的重中之重，相信大家很多人喜欢使用java语言进行开发，就是因为喜欢这一特性吧。

要了解垃圾收集，那么我们肯定得弄明白三个问题：

（1）哪些内存需要回收？

（2）什么时候回收？

（3）如何回收？

1.哪些内存需要回收？

堆里存放着几乎所有对象实例，垃圾收集器在堆上进行回收之前，一定要做的事就是要确认哪些对象还“存活”，而哪些对象已经“死亡”了，这些已经死亡的对象无疑就是要回收的了。如何判断对象已经死亡了呢？

1.1引用计数法

给对象添加一个引用计数器，每当有一个地方引用它时，计数器就加1；当引用失效时，计数器值就减1；任何时刻计算器为0 的对象就是不可能再被使用的。
主流的Java 虚拟机中没有选用计数算法来管理内存，最主要的原因是它很难就解决对象之间相互循环引用的问题。A引用B，B引用A，除此之外再无引用，但是计数器不为0，所以就不会被回收。

1.2可达性分析算法

主流的商用程序语言的主流实现中，都是称通过可达性分析（Reachability Analysis）来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为GC Roots 的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots 没有任何引用链相连时，则证明此对象是不可达的。

在Java 中，可作为GC Roots 的对象包括：
（1）虚拟机栈（栈帧中的本地变量表）中引用的对象
（2）方法区中类静态属性引用的对象
（3）方法区中常量引用的对象
（4）本地方法栈中JNI（一般说的Native 方法）引用的对象

1.3细谈引用

无论是通过哪种算法判断对象存活都与“引用”有关。引用分为强引用，软引用，弱引用，虚引用4种，这4种引用的强度依次减弱。

强引用：

平时我们编程的时候例如：Object object=new Object（）；那object就是一个强引用了。如果一个对象具有强引用，那就类似于必不可少的生活用品，垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。

软引用（SoftReference）：

如果一个对象只具有软引用，那就是有用但非必须的对象。如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。 软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。

弱引用（WeakReference）：

如果一个对象只具有弱引用，那就是非必须的对象。弱引用与软引用的区别在于：只具有弱引用的对象拥有 短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。 弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联 的引用队列中。

虚引用（PhantomReference）：

“虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。 虚引用主要用来跟踪对象被垃圾回收的活动。为一个对象设置虚引用的唯一目的就是能在这个对象被回收时收到一个系统通知。

1.4对象究竟是生存还是死亡呢？

即使在可达性分析中不可达的对象，也并非是非死不可。要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots 相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件就是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()已经被虚拟机调用过，虚拟机将这两种情况视为没有必要执行。
如果这个对象被判为有必要执行finalize() 方法，那么这个对象将会放置在一个叫做F-Queue 队列之中，并在稍后由一个虚拟机自动建立的、低优先级的Finalizer 线程去执行它。这里所谓的执行是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，这样做的原因是，如果一个对象在finalize()方法中执行缓慢，或者发生了死循环，将很可能会导致F-Queue 队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC 将会对F-Queue 中的对象进行第二次小规模的标记，如果对象要在finalize()中拯救自己，只要重新与引用链上的任何一个对象建立联系即可，比如把自己this 复制给某个类变量或对象的成员变量，那在第二次标记时它将被移出即将回收的集合；如果对象这时候还没有逃脱，那基本上它就真的被回收了。任何一个对象的finalize()方法都只会被系统调用一次，如果对象面临下一次回收，它的finalize()方法不
会被再次执行。

finalize()能做的所有工作，使用try/finally或其他方式都能做的更好，更及时，所以完全可以忘记它的存在。

1.5回收方法区

在方法区（永久代）中进行垃圾收集的性价比较低：在堆中，尤其在新生代中，常规应用进行一次垃圾收集一般可以回收70%~95%的空间，而永久代的垃圾收集效率远低于此。永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。回收废弃常量和回收Java堆中的对象类似。以常量池中字面量的回收为例，没有任何String 对象引用常量池中的某个字符串常量，这个常量就会被系统清理出常量池。常量池中的其他类、方法、字段的符号引用也与此类似。
判定一个类是否是无用的类的条件比较苛刻，需要同时满足以下三个条件：
1）该类的所有实例都已经被回收
2）加载该类的类加载器已经被回收
3）该类对应的Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
虚拟机可以对满足上述3 个条件的无用类进行回收，这里说的仅仅是可以，而不是和对象一样，不适用了就必然会被回收。是否对类回收，HotSpot 虚拟机提供了参数进行控制。在大量使用反射、动态代理、CGLib 等ByteCode 框架，动态生成JSP 以及OSGi 这类频繁自定义ClassLoader 的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。

2.GC 算法

2.1标记-清除算法
最基础的收集算法是标记-清除算法（Mark-Sweep），算法分为标记和清除两个阶段。首先标记处所有需要回收的对象，在标记完成后统一回收所有被标记的对象。他的不足主要有两个：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后再程序运行过程中需要分配较大对象时， 无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

2.2复制算法
为了解决效率问题，出现了复制算法。它将可用内存按容量划分为大小相等的两块，每次只是用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存空间，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半，未免太高了一点。

现在的商业虚拟机都采用这种收集算法来回收新生代。将内存分为一块较大的Eden 空间和两块较小的Survivor 空间，每次都使用Eden 和其中一块Survivor。当回收时，将Eden 和Survivor 中还存活着的对象一次性地复制到另外一块Survivor 空间上，最后清理掉Eden 和刚才用过的Survivor 空间。HotSpot 虚拟机默认Eden 和Survivor 的大小比例是8：1。当Survivor 空间不够用时，需要依赖其他内存（老年代）进行分配担保。

2.3标记-整理算法
复制收集算法在对象存活率较高时，效率就会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，所以老年代一般不能直接选用这种算法。根据老年代的特点，有人提出一种标记-整理算法（Mark-Compact），标记过程仍然与标记-清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。

2.4分代收集算法
当前商业虚拟机的垃圾收集都采用分代收集算法（Generational Collection），这种算法是根据对象存活周期的不同将内存划分为适当的几块。一般是把Java 堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用标记-清除或者标记-整理算法来进行回收。

3.GC

Minor GC
从年轻代空间（包括Eden 和Survivor 区域）回收内存被称为Minor GC。
非常频繁，回收速度较快。
各种Young GC 的触发原因都是eden 区满了。
Full GC
收集整个堆，包括年轻代、老年代、元数据区等所有部分。
速度较慢。
触发原因不确定，因具体垃圾收集器而异。
比如老年代内存不足，ygc 出现promotion failure，System.gc()等。
CMS 垃圾收集器不能像其他垃圾收集器那样等待年老代机会完全被填满之后再进行收集，
需要预留一部分空间供并发收集时的使用。