如转载，请标明出处

什么对象应被回收

一般地，一个对象没有被引用，说明这个对象“已死”，可以被回收。那么如何标记这个对象是否被引用？一般包含如下两种算法：

• 引用计数算法
  对象被引用一次，就将引用计数器加1；相反，就减1。这种算法简单且效率高，但是无法解决循环引用的问题。
• 可达性分析算法
  Java中采用的是这种算法。从一系列被称为“GC Roots”的对象为起点开始寻找，当一个对象到GC Roots无任何引用链时，这个对象就可视为不可达的，因此可以回收。
  GC Roots主要存在全局性的引用和执行上下文中：

• 线程栈引用的对象
• 本地方法栈引用的对象
• 类静态属性引用的对象
• 常量引用的对象

垃圾回收算法

HotSpot算法

Stop-The-World

Java是通过GC Roots来寻找标记不可达的对象，因此，在这个过程中，用户的线程是不能运行的，否则标记的不可达对象是不精确的，这种停顿所有用户线程而且必须停顿的过程形象得称为"Stop-The-World"，简称"GC停顿"。好的垃圾收集器的指标之一就是缩小GC停顿的时间。
为了加快定位程序中哪些地方存在对象引用，HotSpot定义了一个称为OopMap(Ordinary Object Pointer)的结构来预先存储这些位置，这样垃圾收集器就能更快得标记出不可达对象。

Safepoint & Saferegion

一般情况下，程序中存在引用的地方是很多的，如果每个地方都存入OopMap，GC的成本也会很高。因此只在某些特定的位置生成OopMap，这些位置称为Safepoint。
在Safepoint，对象的引用链该改变的已经改变，暂时不会再发生变化，比如方法调用，循环跳转等；当一个线程运行到了一个方法内，那么此时不应该让这个用户线程停顿(因为方法执行后，引用可能发生变化，之前不可达，方法执行后又可达了)，此时就可以把方法结束的点称为Safepoint。
在主动式中断中，当发生GC时，不是直接停顿用户线程，而是设置一个标记，当用户线程运行到Safepoint时，就主动去查看这个标记，若发现了停顿标记，就挂起自己；否则继续运行。不同的垃圾回收器定义的Safepoint可能不同。

Safepoint完美得解决了运行中的线程停顿问题，但是不运行的线程，比如sleep的线程就无法响应JVM的中断请求。因此就提出了Saferegion。
Saferegion中的代码可能无法响应JVM中断请求，但是引用关系也不会改变，所以，这区域的代码并不会影响GC Roots枚举的结果。JVM 发起GC时就可以忽略这些进入到Saferegion的线程了。
当一个线程离开Saferegion时，要检查是否完成了GC Roots枚举或GC过程，若没有完，则不能离开直到上述过程结束。

垃圾回收器

新生代收集器有以下三种，都使用复制算法

• Serial 回收器
  如其名，单线程的；是Client模式下的默认新生代回收器；
  GC log标识：def new generation

• ParNew 回收器
  Serial回收器的多线程版本，一般也是在新生代中使用，使用该回收器还有一个很重要的原因是只有它和Serial回收器可以与CMS搭配使用;
  GC log标识：par new generation
  涉及到的参数：

  参数	作用
  -XX:+UseParNewGC	显示指定JVM新生代使用该回收器
  -XX:+UseConcMarkSweepGC	指定老年代使用CMS回收器，此时默认的新生代回收器为ParNew
  -XX:ParallelGCThreads	限制垃圾收集线程数

• Parallel Scavenge 回收器
  大部分回收器都是以缩短用户线程停顿时间为设计目标，该款的关注点略有不同：达到一个可控的吞吐量【运行用户代码时间/(用户代码时间+垃圾收集收集时间)】；自适应调节策略是其与ParNew的一个重要区别；
  GC log标识：PSYoungGen
  涉及到参数：

  参数	作用
  -XX:MaxGCPauseMillis	大于0的毫秒数，收集器尽可能保证GC时间不超过该值
  -XX:GCTimeRatio	0<value<100，默认值99，表示允许最大1%(1/(1+99))的GC时间
  -XX:+UseAdaptiveSizePolicy	默认打开，打开后，不需要手动设置新生代的大小、Eden比例、晋升老年代对象大小(-XX:PretenureSizeThreshold)等细节参数了，虚拟机会根据实际情况自动调节

老年代收集器包含以下几种，采用 标记-清除 or 标记-整理 算法

• Serial Old 回收器
  基于标记-整理算法，Serial的老年代版本，同样是单线程的。与Parallel Scavenge搭配使用；也可在CMS Concurrent Mode Failure失败时使用。

• Parallel Old 回收器
  基于标记-整理算法，Parallel Scavenge的老年代版本。
  GC log标识：ParOldGen
  相关参数：

  参数	作用
  -XX:+UseParallelGC	年轻代收集器设为Parallel Scavenge，老年代设为Parallel Old

• CMS 回收器
  基于标记-清除算法，目标是获取最短停顿时间。整个过程大致分四个步骤：

  1. 初始标记
     只标记GC Roots能关联的对象，需要Stop-The-World
  2. 并发标记
     寻找不可达对象，在此期间，用户线程也在运行
  3. 重新标记
     修正因用户线程运行导致的引用发生变化的对象，需要Stop-The-World
  4. 并发清除
     用户线程也在运行

  缺点如下：
  > cpu资源敏感
  这一点好像无法避免

  > 无法处理浮动垃圾
  因为CMS gc时，用户线程也在运行，在此期间也会产生新的垃圾(浮动垃圾)，这部分只能在下次GC时清理。
  除了这些浮动垃圾，用户线程运行过程也需要内存空间，因此需要预留一部分内存空间(别的收集器都是STW的，因此不必预留)，如果预留的内存不足，则会出现Concurrent Mode Failure，启动备选方案，使用Serial Old进行一次Full gc(会STW)。CMS gc发生的条件是判断当前老年代的使用率，如果超过某个值，则会发生CMS gc；
  > 产生内存碎片
  CMS基于标记-清除算法，因此会产生碎片。这样会导致往往老年代有很多内存空间，但是无法分配大的对象导致Full gc。
  GC log标识：concurrent mark-sweep generation
  相关参数：

  参数	作用
  -XX:CMSInitiatingOccupancyFraction	发生CMS gc的阈值
  -XX:+UseCMSCompactAtFullCollection	默认开启，表示无法为对象找到足够空间而进行Full gc时，进行内存的整理，消除内存碎片
  -XX:CMSFullGCsBeforeCompaction	表示进行多少次不compact的Full gc后，进行一次compact Full gc；默认值为0，表示每次Full gc都进行碎片整理

• G1
  G1目前使用较少，先不介绍。

最后盗一张图说明这些收集器的使用搭配：

collectors.png

上述内容都是个人理解，若有错误，请批评指正

本文参考了周志明《深入理解Java虚拟机》第2版