如转载，请标明出处
什么对象应被回收
一般地，一个对象没有被引用，说明这个对象“已死”，可以被回收。那么如何标记这个对象是否被引用？一般包含如下两种算法：
-
引用计数算法
对象被引用一次，就将引用计数器加1；相反，就减1。这种算法简单且效率高，但是无法解决循环引用的问题。 -
可达性分析算法
Java中采用的是这种算法。从一系列被称为“GC Roots”的对象为起点开始寻找，当一个对象到GC Roots无任何引用链时，这个对象就可视为不可达的，因此可以回收。
GC Roots主要存在全局性的引用和执行上下文中：
- 线程栈引用的对象
- 本地方法栈引用的对象
- 类静态属性引用的对象
- 常量引用的对象
垃圾回收算法
| 算法名称 | 特点 | 说明 |
|---|---|---|
| 标记-清除(Mark-Sweep) | 效率不高；产生内存碎片 | 一般老年代使用 |
| 复制算法 | 没有内存碎片；但得预留一部分内存；需要依赖其他内存(分配担保) | 一般新生代使用； |
| 标记-整理(Mark-Compact) | 一般老年代使用 | |
| 分代收集算法 | - |
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 回收器
基于标记-清除算法，目标是获取最短停顿时间。整个过程大致分四个步骤：- 初始标记
只标记GC Roots能关联的对象，需要Stop-The-World - 并发标记
寻找不可达对象，在此期间，用户线程也在运行 - 重新标记
修正因用户线程运行导致的引用发生变化的对象，需要Stop-The-World - 并发清除
用户线程也在运行
缺点如下：
> 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目前使用较少，先不介绍。
最后盗一张图说明这些收集器的使用搭配：
上述内容都是个人理解，若有错误，请批评指正
本文参考了周志明《深入理解Java虚拟机》第2版
