GC垃圾回收

垃圾收集GC（Garbage Collection） 是Java语言的核心技术之一， 在Java中，程序员不需要去关心内存动态分配和垃圾回收的问题，这一切都交给了JVM来处理。但是不关心不代表它不存在，java中的gc垃圾回收的一些相关知识，本文进行了一些梳理：何为垃圾（定义垃圾），怎么科学的处理垃圾（垃圾收集算法），以及一些实现了回收垃圾理论的工具介绍（垃圾收集器）。

1.定义垃圾

什么样的对象可以被称为 “垃圾”呢？我们一般将那些不可能再被任何途径使用的对象作为 ’“垃圾”，即通常所说的没用任何引用指向的对象。

如何筛选出这种无引用指向的垃圾呢？下面列出两种算法：

• 引用计数算法（Reference Counting）

  简单来说，就是对于创建的每一个对象都有一个与之关联的计数器，这个计数器记录着该对象被使用的次数，垃圾收集器在进行垃圾回收时，对扫描到的每一个对象判断一下计数器是否等于0，若等于0，就会释放该对象占用的内存空间,同时将该对象引用的其他对象的计数器进行减一操作 。

  该算法实现简单，判定效率高，但Java虚拟机中并没有采取这一算法来管理内存，主要因为它很难解决对象直接的循环引用(objA中引用objB,objB中引用objA，当A、B都无其他对象引用时，由于它们相互间的引用，导致计数器任然不为0)。

• 可达性分析算法

  根搜索算法的基本思路就是通过一系列名为”GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。

在Java语言中，可作为GC Roots的对象包含以下4种：

1. 虚拟机栈 (栈帧中的局部变量区，也叫做局部变量表)中引用的对象。
2. 方法区中静态属性引用的对象
3. 方法区中常量引用的对象
4. 本地方法栈中(Native方法)引用的对象

Java中对引用的延伸：

在JDK1.2以前，Java中引用的定义很传统: 如果引用类型的数据中存储的数值代表的是另一块内存的起始地址，就称这块内存代表着一个引用。这种定义有些狭隘，一个对象在这种定义下只有被引用或者没有被引用两种状态。

在JDK1.2之后，Java对引用的概念做了扩充，将引用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)和虚引用(Phantom Reference)四种，这四种引用的强度依次递减。（详情见：java中的四种引用类型）

• 1.强引用（StrongReference）
  强引用是使用最普遍的引用。如果一个对象具有强引用，那垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。 ps：强引用其实也就是我们平时A a = new A()这个意思。
• 2.软引用（SoftReference）
  如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存（下文给出示例）。
  软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。
• 3.弱引用（WeakReference）
  弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
  弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。
• 4.虚引用（PhantomReference）
  “虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。
  虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列 （ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之 关联的引用队列中。

对象死亡的判定：

对于可达性算法找那个不可达的对象，JVM并不会将这些对象定义为已死亡的对象，这时候对象会经历两次标记过程。

标记的前提是对象在进行可达性分析后发现没有与GC Roots相连接的引用链。

1.第一次标记并进行一次筛选。
筛选的条件是此对象是否有必要执行finalize()方法。
当对象没有覆盖finalize方法，或者finzlize方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”，对象被回收。

2.第二次标记
如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会被放置在一个名为：F-Queue的队列之中，并在稍后由一条虚拟机自动建立的、低优先级的Finalizer线程去执行。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。这样做的原因是，如果一个对象finalize（）方法中执行缓慢，或者发生死循环（更极端的情况），将很可能会导致F-Queue队列中的其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃。
Finalize（）方法是对象脱逃死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，如果对象要在finalize（）中成功拯救自己----只要重新与引用链上的任何的一个对象建立关联即可，譬如把自己赋值给某个类变量或对象的成员变量，那在第二次标记时它将移除出“即将回收”的集合。如果对象这时候还没逃脱，那基本上它就真的被回收了

在JVM内存模型中，我们知道有程序计数器、虚拟机栈、本地方法栈、堆和方法区 五大类，并且知道 程序计数器、虚拟机栈、本地方法栈3个区域是随线程而生灭的，所以这几个区域内的内存分配和回收一般具有确定性，这几个区域不需要过多的考虑回收的问题，因为方法结束或线程结束时，内存就自然回收了。而java堆和方法区则不一样这部分的分配和回收都是动态的，垃圾收集器所关注的也是这部分内存。

2.常见垃圾收集算法

常用 的垃圾回收算法有：标记清除、复制、标记整理、分代收集算法。

• 标记-清除算法（Mark-Sweep）

  见名知意，算法分为“标记”和“清除”两个阶段：s1.标记出所有需要回收的对象 s2.标记成功后统一回收所有被标记的对象。

  不足：1.效率问题，标记和清楚的两个过程效率都不高。2.空间问题，标记清除之后会产生大段不连续的内存碎片，可能会在需要分配大对象空间时没有足够的连续空间进行分配，从而导致触发再一次垃圾收集动作。
  

• 复制算法(Copying)

  为了解决效率问题，复制算法出现了，该算法是将内存分为两块大小一样的区域，每次是使用其中的一块。当这块内存块用完了，就将这块内存中还存活的对象复制到另一块内存中，然后清空这块内存。这种算法在对象存活率较低的场景下效率很高，比如说新生代，只对整块内存区域的一半进行垃圾回收，在垃圾回收的过程也不会出现内存碎片的情况，不需要移动对象，只需要移动指针即可，实现简单，所以运行效率很高。运行效率是在建立在浪费空间的基础上的，这是典型的已空间换时间的方法，因为每次只能是使用内存的一半。
  

  现在商用的jvm中都采用了这种算法来回收新生代，因为新生代的对象基本上都是朝生夕死的，存活下来的对象约占10%左右，所以需要复制的对象比较少，采用这种算法效率比较高。虚拟机将堆（heap）内存分为了新生代和老年代，其中新生代又分为内存较大的 Eden 区和两个较小的 survivor 区。当进行内存回收时，将eden区和survivor区的还存活的对象一次性地复制到另一个survivor空间上，最后将eden区和刚才使用过的survivor空间清理掉。hotspot虚拟机默认eden和survivor空间的大小比例为8：1，也就是每次新生代中可用内存空间为整个新生代空间的90%（80%+10%），只会浪费掉10%的空间。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当survivor空间不够用时，需要依赖于其他内存（这里指的是老年代）进行分配的担保。

• 标记-整理算法(Mark-compact)

  复制算法在对象存活率较高的情况下就要进行较多的对象复制操作，效率将会变低。更关键的是，如果你不需要浪费50%的空间，就需要有额外的空间进行分配担保，用以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种办法。

  根据老年代的特点，出现了“标记-整理” 算法,算法的标记过程仍与“标记-清除” 算法一样，但后续步骤不会直接对可回收对象进行清理，而是让存活的对象向一端移动，然后清理掉端边界以外的内存。

• 分代收集算法 （Generational Collection）

这种算法并没有什么新的思想，而是根据对象存活周期的不同将内存划分为多块。一般把java堆分成新生代 和 老年代。新生代中每次垃圾回收时都有大批的对象死去，只有少量存活就选用 复制算法。而老年代中对象存活率高、没有额外的内存空间进行分配担保，所以就使用“标记-清除” 或 “标记-整理”算法进行回收。
新生代发生的gc动作叫做minor gc 或 young gc，老年代发生的叫做major gc 或 full gc。
　　 minor gc 的触发条件：当创建新对象时Eden区剩余空间小于对象的内存大小时发生minor gc；
　　 major gc 触发条件：
　　1、显式调用System.gc()方法；
　　2、老年代空间不足；
　　3、方法区空间不足；
　　4、从新生代进入老年代的空间大于老年代空闲空间；

扩展：

分代理论：

90%的对象熬不过第一次垃圾回收，而老的对象(经历了好几次垃圾回收的对象)则有98%的概率会一直活下来。

一般的垃圾回收器把内存分成三类: Eden(E), Suvivor(S)和Old(O), 其中Eden和Survivor都属于年轻代，Old属于老年代，新对象始终分配在Eden里面，熬过一次垃圾回收的对象就被移动到Survisor区了，经过数次垃圾回收之后还活着的对象会被移到Old区。

这样分代的好处是，把一个复杂的大问题，分成两类不同的小问题，针对不同的小问题，采用更有针对性的措施(分而治之):

• 对于年轻代的对象，由于对象来的快去得快，垃圾收集会比较频繁，因此执行时间一定要短，效率要高，因此要采用执行时间短，执行时间的长短只取决于对象个数的垃圾回收算法。但是这类回收器往往会比较浪费内存，比如Copying GC，会浪费一半的内存，以空间换取了时间。
• 对于老年代的对象，由于本身对象的个数不多，垃圾收集的次数不多，因此可以采用对内存使用比较高效的算法。

JVM 内存模型中分为heap区和非heap区两类，heap(堆)区新生代中分为1个Eden Space和2和Suvivor Space，老年代为Tenured Gen；非heap区分为Code Cache(代码缓存区)、Perm Gen（永久代）、Jvm Stack(java虚拟机栈)、Local Method Statck(本地方法栈)；

3.垃圾收集器简介

垃圾收集算法是一种内存回收的方法论，而垃圾收集器就是这些方法的具体实现了，常见的垃圾收集器有：

• Serial收集器（复制算法)
  新生代单线程收集器，标记和清理都是单线程，优点是简单高效。是client级别默认的GC方式，可以通过-XX:+UseSerialGC来强制指定。
• Serial Old收集器(标记-整理算法)
  老年代单线程收集器，Serial收集器的老年代版本。
• ParNew收集器(停止-复制算法)　
  新生代收集器，可以认为是Serial收集器的多线程版本,在多核CPU环境下有着比Serial更好的表现。
• Parallel Scavenge收集器(停止-复制算法)
  并行收集器，追求高吞吐量，高效利用CPU。吞吐量一般为99%， 吞吐量= 用户线程时间/(用户线程时间+GC线程时间)。适合后台应用等对交互相应要求不高的场景。是server级别默认采用的GC方式，可用-XX:+UseParallelGC来强制指定，用-XX:ParallelGCThreads=4来指定线程数。
• Parallel Old收集器(停止-复制算法)
  Parallel Scavenge收集器的老年代版本，并行收集器，吞吐量优先。
• CMS(Concurrent Mark Sweep)收集器（标记-清理算法）
  高并发、低停顿，追求最短GC回收停顿时间，cpu占用比较高，响应时间快，停顿时间短，多核cpu 追求高响应时间的选择。
• G1( Garbage First ) 收集器，基于JVM内存分代假设理论的垃圾回收器

下面详细介绍下CMS和G1收集器：

首先我们需要了解一个名词 Stop-the-World，简称STW。

Stop-the-World： 指的是GC事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应, 有点像卡死的感觉，这个停顿称为STW。

不管选择哪种GC算法，stop-the-world都是不可避免的。Stop-the-world意味着从应用中停下来并进入到GC执行过程中去。一旦Stop-the-world发生，除了GC所需的线程外，其他线程都将停止工作，中断了的线程直到GC任务结束才继续它们的任务。GC调优通常就是为了改善stop-the-world的时间

CMS收集器

CMS收集器是一种以获取最短回收停顿时间为目标的收集器，CMS收集器是基于“”标记–清除”(Mark-Sweep)算法实现的，整个过程分为四个步骤：

• 1.初始标记 (Stop the World事件 CPU停顿， 很短) 初始标记仅标记一下GC Roots能直接关联到的对象，速度很快；

• 2.并发标记 (收集垃圾跟用户线程一起执行) 初始标记和重新标记任然需要“stop the world”，并发标记过程就是进行GC Roots Tracing的过程；

• 3.重新标记 (Stop the World事件 CPU停顿，比初始标记稍微长，远比并发标记短)修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记时间短

• 4.并发清理 -清除算法；

CMS是一款优秀的收集器，它的主要优点是：并发收集、低停顿

理由： 由于在整个过程和中最耗时的并发标记和 并发清除过程收集器程序都可以和用户线程一起工作，所以总体来说，Cms收集器的内存回收过程是与用户线程一起并发执行的

主要缺点：

(1).CMS收集器对CPU资源非常敏感

在并发阶段，虽然不会导致用户线程停顿，但是会因为占用了一部分线程使应用程序变慢，总吞吐量会降低，为了解决这种情况，虚拟机提供了一种“增量式并发收集器”

的CMS收集器变种， 就是在并发标记和并发清除的时候让GC线程和用户线程交替运行，尽量减少GC 线程独占资源的时间，这样整个垃圾收集的过程会变长，但是对用户程序的影响会减少。（效果不明显，不推荐）

(2)CMS处理器无法处理浮动垃圾

CMS在并发清理阶段线程还在运行， 伴随着程序的运行自然也会产生新的垃圾，这一部分垃圾产生在标记过程之后，CMS无法再当次过程中处理，所以只有等到下次gc时候在清理掉，这一部分垃圾就称作“浮动垃圾” ，

(3).CMS是基于“标记–清除”算法实现的，所以在收集结束的时候会有大量的空间碎片产生。空间碎片太多的时候，将会给大对象的分配带来很大的麻烦，往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象的，只能提前触发 full gc。

为了解决这个问题，CMS提供了一个开关参数，用于在CMS顶不住要进行full gc的时候开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片没有了，但是停顿的时间变长了

G1垃圾收集器

**G1(Garbage First)**是一款面向服务端应用的垃圾收集器。G1具备如下特点：

G1运作步骤：

1、初始标记(stop the world事件 CPU停顿只处理垃圾)；

2、并发标记(与用户线程并发执行)；

3、最终标记(stop the world事件 ,CPU停顿处理垃圾)；

4、筛选回收(stop the world事件 根据用户期望的GC停顿时间回收)(注意：CMS 在这一步不需要stop the world)

跟其它垃圾回收器不一样的是：G1虽然也把内存分成了这三大类，但是在G1里面这三大类不是泾渭分明的三大块内存，G1把内存划分成很多小块, 每个小块会被标记为E/S/O中的一个，可以前面一个是Eden后面一个就变成Survivor了。

这么做给G1带来了很大的好处，由于把三块内存变成了几百块内存，内存块的粒度变小了，从而可以垃圾回收工作更彻底的并行化。

而且粒度的降低可以让G1在步骤4中，基于用户所配置的暂停时间来选择性的回收“一些内存块”，而不是整代内存来回收。这也是G1跟其它GC非常不同的一点，其它GC每次回收都会回收整个Generation的内存(Eden, Old), 而回收内存所需的时间就取决于内存的大小，以及实际垃圾的多少，所以垃圾回收时间是不可控的；而G1每次并不会回收整代内存，到底回收多少内存就看用户配置的暂停时间，所以可控。

G1的并行收集做得特别好，我们第一次听到并行收集应该是CMS(Concurrent Mark & Sweep)垃圾回收算法, 但是CMS的并行收集也只是在收集老年代能够起效，而在回收年轻代的时候CMS是要暂停整个应用的(Stop-the-world)。而G1整个收集全程几乎都是并行的，它回收的大致过程是这样的:

• 在垃圾回收的最开始有一个短暂的时间段(Inital Mark)会停止应用(stop-the-world)
• 然后应用继续运行，同时G1开始Concurrent Mark
• 再次停止应用，来一个Final Mark (stop-the-world)
• 最后根据Garbage First的原则，选择一些内存块进行回收。(stop-the-world)

由于它高度的并行化，因此它在应用停止时间(Stop-the-world)这个指标上比其它的GC算法都要好。

总结：与其他GC收集器相比，G1具备如下特点：

1、并行于并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。

2、分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。它能够采用不同的方式去处理新创建的对象和已经存活了一段时间，熬过多次GC的旧对象以获取更好的收集效果。

3、空间整合：与CMS的“标记–清理”算法不同**，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的**。

4、可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1和CMS共同的关注点，但Ｇ１除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段

G1的缺点：如果应用的内存非常吃紧，对内存进行部分回收根本不够，始终要进行整个Heap的回收，那么G1要做的工作量就一点也不会比其它垃圾回收器少，而且因为本身算法复杂了一点，可能比其它回收器还要差。因此G1比较适合内存稍大一点的应用(一般来说至少4G以上)，小内存的应用还是用传统的垃圾回收器比如CMS比较合适。