对象已死吗？
判断对象存活：
引用计数法：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值+1；当引用失效时，计数器值-1。任何时刻计数器为0的对象就是不可能再被使用的。
主流的Java虚拟机不选用引用计数法来管理内存，最主要的原因是它很难解决对象之间相互循环引用的问题。
比如：左边为堆，右边为栈
可达性分析算法：通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索（dfs），搜索过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连，则证明此对象是不可用的。
可作为GC Roots的对象包括下面几种：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象。
- 方法区中类静态属性引用的对象。
- 方法区中常量引用的对象。
- 本地方法中JNI（Native方法）引用的对象。
再谈引用
引用分为强引用、软引用、弱引用、虚引用4种，引用强度依次减弱。
- 强引用就是在程序代码中普遍存在的，比如Object obj=new Object()，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
- 软引用是用来描述一些还有用但并非必需的对象。在系统将要发生内存溢出异常之前，会将软引用关联的对象列进回收范围进行第二次回收，如果这次还没有足够的内存，才会抛出内存溢出异常。在jdk1.2之后，提供了SoftReference类实现软引用。
- 弱引用也是用来描述非必需对象的，但是他的强度比软引用更弱一些，被弱引用关联着的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论内存是否足够，都回收掉只被弱引用关联的对象。在JDK1.2后，提供了WeakReference类实现弱引用。
- 虚引用也称为幽灵引用或幻影引用，他是最弱的引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用。
finalize()
即使在可达性分析算法中不可达的对象，也并非是非死不可的，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize方法，当对象没有覆盖finalize方法，或者finalize方法已经被虚拟机调用过，虚拟机都将这两种情况视为“没有必要执行”。如果被判定“有必要执行”，那么这个对象会放置在一个F-Queue队列之中，并在稍后由一个Finalizer线程去执行他，稍后GC会对F-Queue中的对象进行第二次标记，finalize()方法是对象逃脱死亡命运的最后一次机会。
任何一个对象的finalize方法都只会被系统调用一次。
垃圾收集算法
标记—清除算法（最基础的收集算法）：
首先标记处所有需要回收的对象，在标记完成后统一回收所有被标记的对象，标记过程采用上面的可达性分析算法。
不足：1）效率问题，标记和清除过程效率都不高；2）空间问题，标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前除法另一次垃圾收集动作。
堆更详细的划分
- 新生代
Eden 伊甸园：创建一个对象，就会扔到这里，垃圾回收器经常光顾这里
Survivor 存活区 - 老年代
Tenured Gen：地位高，养老
复制算法：
将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块用完了，就将存活着的对象复制到另外一块上面，然后再把已使用过的内存一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半，未免太高了一点。
改进：现在的商业虚拟机都采用这种收集算法来回收新生代，新生代的对象98%是朝生夕死的，所以不需要按照1：1的比例划分内存空间，而是将内存分为一块较大的Eden和两块较小的Survivor，每次使用Eden和其中一块Survivor，当回收时，将Eden和Survivor中还存活的对象一次性复制到另外一块Survivor空间，最后清理掉Eden和刚使用过的Survivor。HotSpot虚拟机默认Eden:Survivor=8:1。当Survivor空间不够用时，需要依赖其他内存（老年代）进行分配担保。
标记—整理算法
复制收集算法在对象存活率较高时就要进行较多的复制操作，效率会变低，更关键的是，老年代存活率大，需要更多的空间担保，所以老年代不能用这种算法。
针对老年代，标记和前面的标记清理一样，但后续是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
分代收集算法
对新生代采用复制算法，对老年代采用标记—整理算法。
垃圾收集器
上图展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。Hotspot实现了如此多的收集器，正是因为目前并无完美的收集器出现，只是选择对具体应用最适合的收集器。
Serial收集器
- 最基本、发展历史最悠久。
- 单线程垃圾收集器，运行一会儿，停一下进行垃圾收集，再运行。
- 桌面应用（客户端）
ParNew收集器
Serial收集器的多线程版本。
在垃圾收集器中，并发和并行的解释：
- 并行：多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。
- 并发：用户线程与垃圾收集线程同时执行（交替执行），用户程序在继续运行，而垃圾收集程序运行在另一个CPU中。
Parallel Scavenge收集器
吞吐量：运行用户代码时间/（运行用户代码时间+垃圾收集时间）
- 多线程收集器
- 达到可控制的吞吐量
- -XX:MaxGCPauseMillis 最大垃圾收集器停顿时间 单位ms
- -XX:GCTimeRatio 设置吞吐量大小（0,100）
CMS收集器（Concurrent Mark Sweep）
一种以获取最短回收停顿时间为目标的收集器。
基于“标记——清除”算法实现。
4个步骤：初始标记——并发标记——重新标记——并发清除
其中初始标记、重新标记需要“stop the world”，初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC RootsTracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比 初始标记阶段稍长一些，但远比并发标记的时间短。
由于整个过程耗时最长的并发标记和并发清除过程收集器线程都可以和用户线程一起工作，所以总体上CMS收集器的内存回收过程是与用户线程一起并发执行的。
优点：并发收集、低停顿
缺点：
- 占用大量CPU资源，导致应用程序变慢，总吞吐量降低
- 无法处理浮动垃圾（CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理它们，只好留待下一次GC时再清理掉）
- 可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。因为垃圾收集阶段用户线程还要运行，所以还需要预留足够的内存空间给用户线程使用，不能像其他垃圾收集器等到老年代几乎完全填满在进行收集。要是CMS预留的内存无法满足程序需要，就会出现“Concurrent Mode Failure”。
- 大量空间碎片。因为是标记清除算法。
G1收集器（Garbage-First）
当今收集器技术发展的最前沿成果之一。面向移动端应用。
优点：
- 并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
-
分代收集（region）：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
-
空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
-
可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。
在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。
G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的来由）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。
- 初始标记：标记一下GC Roots能直接关联到的对象，需要停顿线程，但耗时很短
- 并发标记：是从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行
- 最终标记：修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录
- 筛选回收：对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划
内存分配与回收策略
对象优先在Eden分配：大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次MinorGC。
新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
老年代GC（Major GC/Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的MinorGC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）。Major GC的速度一般会比Minor GC慢10倍以上。
大对象直接进入老年代：虚拟机提供了一个-XX：PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制。
长期存活的对象将进入老年代：虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就将会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX：MaxTenuringThreshold设置。
动态对象年龄判定：为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。|
空间分配担保:在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC。