java垃圾回收机制

本文是针对个人感觉重要与否进行编写，某些常见，易懂的部分我会简单描述。不建议初次了解读本篇文章，本文适合巩固学习。

• 如何判定对象是否已死

  引用计数算法：给对象一个引用计数器，当有地方引用计数器加一，一个引用失效计数器减一；计数器为0的对象可被清除。（缺点：互相引用时，计数器都为1时，对象已经不会在被使用，但并不会被消除）

  可达性分析算法：通过一系列成为“GC Roots”的对象作为起点，从这些节点向下开始搜索，所走的路径成为引用链，当一个对象到GC Roots 没有任何引用链时，则该对象是可以用的。

  GC Roots 对象包含：①虚拟机栈引用的对象、②方法区中静态属性引用的对象、③方法区中常量引用的对象、④本地方法栈中JNI引用的对象。

• 垃圾回收算法

  • 标记-清除算法（Mark-Sweep）
    不足：标记与清除两个过程销量都不是很高；空间碎片太多，不连续空间导致无法分配较大的对象；而引起另一次垃圾回收。

  • 复制算法（Copying）
    复制算法是为了解决效率问题而出现的，它将可用的内存分为两块，每次只用其中一块，当这一块内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已经使用过的内存空间一次性清理掉。这样每次只需要对整个半区进行内存回收，内存分配时也不需要考虑内存碎片等复杂情况，只需要移动指针，按照顺序分配即可。

    不过这种算法有个缺点，内存缩小为了原来的一半，这样代价太高了。现在的商用虚拟机都采用这种算法来回收新生代，不过研究表明1:1的比例非常不科学，因此新生代的内存被划分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。每次回收时，将Eden和Survivor中还存活着的对象一次性复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden区和Survivor区的比例为8:1，意思是每次新生代中可用内存空间为整个新生代容量的90%。当然，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖老年代进行分配担保（Handle Promotion）

  • 标记-整理算法（Mark-Compact）
    复制算法在对象存活率较高的场景下要进行大量的复制操作，效率很低。万一对象100%存活，那么需要有额外的空间进行分配担保。老年代都是不易被回收的对象，对象存活率高，因此一般不能直接选用复制算法。根据老年代的特点，有人提出了另外一种标记-整理算法，过程与标记-清除算法一样，不过不是直接对可回收对象进行清理，而是让所有存活对象都向一端移动，然后直接清理掉边界以外的内存。

  • 分代收集算法
    现代商用虚拟机基本都采用分代收集算法来进行垃圾回收。这种算法没什么特别的，无非是上面内容的结合罢了，根据对象的生命周期的不同将内存划分为几块，然后根据各块的特点采用最适当的收集算法。大批对象死去、少量对象存活的（新生代），使用复制算法，复制成本低；对象存活率高、没有额外空间进行分配担保的（老年代），采用标记-清理算法或者标记-整理算法。

• 垃圾收集器

  • Serial收集器
    最基本、发展历史最久的收集器，这个收集器是一个采用复制算法的单线程的收集器，单线程一方面意味着它只会使用一个CPU或一条线程去完成垃圾收集工作，另一方面也意味着它进行垃圾收集时必须暂停其他线程的所有工作，直到它收集结束为止。

    特点：1. 需要STW（Stop The World），停顿时间长。2. 简单高效，对于单个CPU环境而言，Serial收集器由于没有线程交互开销，可以获取最高的单线程收集效率。

  • Serial Old收集器
    Serial收集器的老年代版本，同样是一个单线程收集器，使用“标记-整理算法”，这个收集器的主要意义也是在于给Client模式下的虚拟机使用。

  • ParNew收集器
    ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集外，其余行为和Serial收集器完全一样，包括使用的也是复制算法。

    它却是Server模式下的虚拟机首选的新生代收集器，其中有一个很重要的和性能无关的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。

  • Parallel Scavenge收集器
    Parallel Scavenge收集器也是一个新生代收集器，也是用复制算法的收集器，也是并行的多线程收集器，CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是打到一个可控制的吞吐量。Parallel Scavenge收集器是虚拟机运行在Server模式下的默认垃圾收集器。

    特点：虚拟机提供了-XX:MaxGCPauseMillis和-XX:GCTimeRatio两个参数来精确控制最大垃圾收集停顿时间和吞吐量大小。如果对于垃圾收集器运作原理不太了解，以至于在优化比较困难的时候，使用Parallel Scavenge收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成将是一个不错的选择。

  • Parallel Old收集器
    Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器在JDK 1.6之后的出现，“吞吐量优先收集器”终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge收集器+Parallel Old收集器的组合。

  • CMS收集器
    CMS（Conrrurent Mark Sweep）收集器是以获取最短回收停顿时间为目标的收集器。使用标记 - 清除算法，收集过程分为如下四步：

    (1). 初始标记(单线程)，标记GCRoots能直接关联到的对象，时间很短。
    (2). 并发标记(并发)，进行GCRoots Tracing（可达性分析）过程，时间很长。
    (3). 重新标记(并行)，修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，时间较长。
    (4). 并发清除(并发)，回收内存空间，时间很长。

    特点：
    (1). 对CPU资源非常敏感，可能会导致应用程序变慢，吞吐率下降。
    (2). 无法处理浮动垃圾，因为在并发清理阶段用户线程还在运行，自然就会产生新的垃圾，而在此次收集中无法收集他们，只能留到下次收集，这部分垃圾为浮动垃圾，同时，由于用户线程并发执行，所以需要预留一部分老年代空间提供并发收集时程序运行使用。
    (3). 由于采用的标记 - 清除算法，会产生大量的内存碎片，不利于大对象的分配，可能会提前触发一次Full GC。
    虚拟机提供了-XX:+UseCMSCompactAtFullCollection参数来进行碎片的合并整理过程，这样会使得停顿时间变长，虚拟机还提供了一个参数配置，-XX:+CMSFullGCsBeforeCompaction，用于设置执行多少次不压缩的Full GC后，接着来一次带压缩的GC。

  • G1收集器
    G1是目前技术发展的最前沿成果之一，HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。与其他GC收集器相比，G1收集器有以下特点：

    (1). 并行和并发。使用多个CPU来缩短Stop The World停顿时间，与用户线程并发执行。
    (2). 分代收集。独立管理整个堆，但是能够采用不同的方式去处理新创建对象和已经存活了一段时间、熬过多次GC的旧对象，以获取更好的收集效果。
    (3). 空间整合。基于标记 - 整理算法，无内存碎片产生。
    (4). 可预测的停顿。能简历可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

    清理流程为：初始标记(单线程)-并发标记(并发)-重新标记(并行)-筛选回收(可并发却并行)
    在G1之前的垃圾收集器，收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分（可以不连续）Region的集合。

• 我们的虚拟机使用的垃圾回收收集器：
  jdk1.7-1.8 默认：PS Scavenge + PS MarkSweep（PS MarkSweep是以Serial Old为模型设计的也就是说默认收集方式为Parallel Scavenge 收集器
  +Serial Old收集器）（百度你会发现很多错误的答案认为这两个版本用的是PS Scavenge 和 PS Old 其实是错误的。）
  jdk1.9：貌似开始上G1（未测试，谨慎参考）
  http://www.cnblogs.com/grey-wolf/p/9217497.html