Java 垃圾回收机制
什么是垃圾
当对象失去引用（索引）并且不能被外界引用时就会变成垃圾。
垃圾分类
垃圾的分类如下图
强引用
这类引用是最常见的引用，如果一个对象具有强引用，那么垃圾回收期绝对不会回收找个对象。当内存不足时，JVM宁愿抛出异常终止程序，也不会回收掉这个对象的内存来解决内存不足的问题。
软引用
如果一个对象只具有软引用，是否被回收就要看内存空间是否足够；如果内存空间足够，垃圾回收器就不会回收这个对象；如果内存空间不够了，那么垃圾回收器就会回收这个对象；
弱引用
被定义是垃圾；弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
虚引用
与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样【null】，在任何时候都可能被垃圾回收器回收。
如何定义一个对象是不是垃圾
没有索引不能够被重新使用的对象！系统无法重新复用这个对象了！那么这个对象就是个垃圾；那么如何定义一个对象是不是垃圾呢？
这里有两种方法可以发现和确定失去索引的对象，是否是垃圾（引用计数法、可达性分析法）
引用计数法
每个对象在创建的时候会在对象头分配一个空间来保存该对象被其他对象引用的次数。如果该对象被其他对象引用，引用计数器+1；如果删除对对象的引用，引用计数器-1；当该对象的计数器为0时，该对象被视为垃圾被回收。
但是这样做也有一个问题出现-交织空引用。首先两个对象互相引用；之后，两个索引都置空；但是RC并不等于零，因为他们交织引用了对方。这就造成了本应该是垃圾的对象，无法被判定为垃圾，无法收回！！！
这种现象被称为空索引-交织引用。
可达性分析法
可达性分析算法（Reachability Analysis）的基本思路是，通过一些被称为垃圾回收根（GC Roots）的对象作为起点，从这些节点开始向下搜索，搜索走过的路径被称为引用链（Reference Chain)，当一个对象到 GC Roots 没有任何引用链相连时（即从 GC Roots 节点到该节点不可达），则证明该对象是不可用的。
如何回收垃圾
在确定了哪些垃圾可以被回收后，垃圾收集器要做的事情就是开始进行垃圾回收，但是这里面涉及到一个问题是：如何高效地进行垃圾回收。由于Java虚拟机规范并没有对如何实现垃圾收集器做出明确的规定，因此各个厂商的虚拟机可以采用不同的方式来实现垃圾收集器，这里我们讨论几种常见的垃圾收集算法的核心思想：①标记-清除法；②复制算法；③标记整理算法；④内存模型与回收策略
标记-清除法
标记清除算法（Mark-Sweep）是最基础的一种垃圾回收算法，它分为2部分，先把内存区域中的这些对象进行标记，哪些属于可回收标记出来，然后把这些垃圾拎出来清理掉。就像上图一样，清理掉的垃圾就变成未使用的内存区域，等待被再次使用。
这逻辑再清晰不过了，并且也很好操作，但它存在一个很大的问题，那就是内存碎片。
上图中等方块的假设是 2M，小一些的是 1M，大一些的是 4M。等我们回收完，内存就会切成了很多段。我们知道开辟内存空间时，需要的是连续的内存区域，这时候我们需要一个 2M的内存区域，其中有2个 1M 是没法用的。这样就导致，其实我们本身还有这么多的内存的，但却用不了。
优点：简单快捷；缺点：造成太多内存碎片
复制算法
复制算法（Copying）是在标记清除算法上演化而来，解决标记清除算法的内存碎片问题。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。保证了内存的连续可用，内存分配时也就不用考虑内存碎片等复杂情况，逻辑清晰，运行高效。
上面的图很清楚，也很明显的暴露了另一个问题，合着我这140平的大三房，只能当70平米的小两房来使？代价实在太高。
优点：解决了内存碎片太多的问题 ； 缺点：内存使用效率太低
标记-整理算法
标记整理算法（Mark-Compact）标记过程仍然与标记 — 清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，再清理掉端边界以外的内存区域。
标记整理算法一方面在标记-清除算法上做了升级，解决了内存碎片的问题，也规避了复制算法只能利用一半内存区域的弊端。看起来很美好，但从上图可以看到，它对内存变动更频繁，需要整理所有存活对象的引用地址，在效率上比复制算法要差很多。
内存模型和回收策略
Java 堆（Java Heap）是JVM所管理的内存中最大的一块，堆又是垃圾收集器管理的主要区域，这里我们主要分析一下 Java 堆的结构。
Java 堆主要分为2个区域-年轻代与老年代，其中年轻代又分 Eden 区和 Survivor 区，其中 Survivor 区又分 From 和 To 2个区。
Eden区
对象会在新生代 Eden 区中进行分配，当 Eden 区没有足够空间进行分配时，虚拟机会发起一次 Minor GC【小型回收】，Minor GC 相比 Major GC【大型回收】 更频繁，回收速度也更快。
通过 Minor GC 之后，Eden 会被清空，Eden 区中绝大部分对象会被回收，而那些无需回收的存活对象，将会进到 Survivor 的 From 区（若 From 区不够，则直接进入 Old 区）。
Survivor区
Survivor 区相当于是 Eden 区和 Old 区的一个缓冲，类似于我们交通灯中的黄灯。Survivor 又分为2个区，一个是 From 区，一个是 To 区。每次执行 Minor GC，会将 Eden 区和 From 存活的对象放到 Survivor 的 To 区（如果 To 区不够，则直接进入 Old 区）。
1、为啥需要？
不就是新生代到老年代么，直接 Eden 到 Old 不好了吗，为啥要这么复杂。想想如果没有 Survivor 区，Eden 区每进行一次 Minor GC，存活的对象就会被送到老年代，老年代很快就会被填满。而有很多对象虽然一次 Minor GC 没有消灭，但其实也并不会蹦跶多久，或许第二次，第三次就需要被清除。这时候移入老年区，很明显不是一个明智的决定。
所以，Survivor 的存在意义就是减少被送到老年代的对象，进而减少 Major GC 的发生。Survivor 的预筛选保证，只有经历16次 Minor GC 还能在新生代中存活的对象，才会被送到老年代。
2、为啥需要俩？
设置两个 Survivor 区最大的好处就是解决内存碎片化。
我们先假设一下，Survivor 如果只有一个区域会怎样。Minor GC 执行后，Eden 区被清空了，存活的对象放到了 Survivor 区，而之前 Survivor 区中的对象，可能也有一些是需要被清除的。问题来了，这时候我们怎么清除它们？在这种场景下，我们只能标记清除，而我们知道标记清除最大的问题就是内存碎片，在新生代这种经常会消亡的区域，采用标记清除必然会让内存产生严重的碎片化。因为 Survivor 有2个区域，所以每次 Minor GC，会将之前 Eden 区和 From 区中的存活对象复制到 To 区域。第二次 Minor GC 时，From 与 To 职责兑换，这时候会将 Eden 区和 To 区中的存活对象再复制到 From 区域，以此反复。
这种机制最大的好处就是，整个过程中，永远有一个 Survivor space 是空的，另一个非空的 Survivor space 是无碎片的。那么，Survivor 为什么不分更多块呢？比方说分成三个、四个、五个?显然，如果 Survivor 区再细分下去，每一块的空间就会比较小，容易导致 Survivor 区满，两块 Survivor 区可能是经过权衡之后的最佳方案。
Old区
老年代占据着2/3的堆内存空间，只有在 Major GC 的时候才会进行清理，每次 GC 都会触发“Stop-The-World”。内存越大，STW 的时间也越长，所以内存也不仅仅是越大就越好。由于复制算法在对象存活率较高的老年代会进行很多次的复制操作，效率很低，所以老年代这里采用的是标记 — 整理算法。
除了上述所说，在内存担保机制下，无法安置的对象会直接进到老年代，以下几种情况也会进入老年代。
1、大对象
大对象指需要大量连续内存空间的对象，这部分对象不管是不是“朝生夕死”，都会直接进到老年代。这样做主要是为了避免在 Eden 区及2个 Survivor 区之间发生大量的内存复制。当你的系统有非常多“朝生夕死”的大对象时，得注意了。
2、长期存活对象
虚拟机给每个对象定义了一个对象年龄（Age）计数器。正常情况下对象会不断的在 Survivor 的 From 区与 To 区之间移动，对象在 Survivor 区中每经历一次 Minor GC，年龄就增加1岁。当年龄增加到15岁时，这时候就会被转移到老年代。当然，这里的15，JVM 也支持进行特殊设置。
3、动态对象年龄
虚拟机并不重视要求对象年龄必须到15岁，才会放入老年区，如果 Survivor 空间中相同年龄所有对象大小的综合大于 Survivor 空间的一般，年龄大于等于该年龄的对象就可以直接进去老年区，无需等你“成年”。
GC时为什么会有全局停顿？
类比在聚会时打扫房间，聚会时很乱，又有新的垃圾产生，房间永远打扫不干净，只有让大家停止活动了，才能将房间打扫干净。当gc线程在处理垃圾的时候，其它[[Java线程]]要停止才能彻底清除干净，否则会影响gc线程的处理效率增加gc线程负担，特别是在垃圾标记的时候。
垃圾收集器
JVM中的垃圾收集器主要包括7种，即Serial，Serial Old，ParNew，Parallel Scavenge，Parallel Old以及CMS，G1收集器。
Serial收集器
Serial收集器是一个单线程的垃圾收集器，并且在执行垃圾回收的时候需要 Stop The World。虚拟机运行在Client模式下的默认新生代收集器。Serial收集器的优点是简单高效，对于限定在单个CPU环境来说，Serial收集器没有多线程交互的开销。
Serial Old收集器
Serial Old是Serial收集器的老年代版本，也是一个单线程收集器。主要也是给在Client模式下的虚拟机使用。在Server模式下存在主要是做为CMS垃圾收集器的后备预案，当CMS并发收集发生Concurrent Mode Failure时使用。
ParNew收集器
ParNew是Serial收集器的多线程版本，新生代是并行的（多线程的），老年代是串行的（单线程的），新生代采用复制算法，老年代采用标记整理算法。可以使用参数：**-XX：UseParNewGC使用该收集器，使用 -XX：ParallelGCThreads可以限制线程数量。**
Parallel Scavenge垃圾收集器
Parallel Scavenge是一种新生代收集器，使用复制算法的收集器，而且是并行的多线程收集器。Paralle收集器特点是更加关注吞吐量（吞吐量就是cpu用于运行用户代码的时间与cpu总消耗时间的比值）。可以通过**-XX:MaxGCPauseMillis参数控制最大垃圾收集停顿时间；通过-XX:GCTimeRatio参数直接设置吞吐量大小；通过-XX:+UseAdaptiveSizePolicy参数可以打开GC自适应调节策略，该参数打开之后虚拟机会根据系统的运行情况收集性能监控信息，动态调整虚拟机参数以提供最合适的停顿时间或者最大的吞吐量。自适应调节策略**是Parallel Scavenge收集器和ParNew的主要区别之一。
Parallel Old收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和标记-整理算法。
CMS（Concurrent Mark Sweep）收集器（并发标记清除）
CMS收集器是一种以获取最短回收停顿时间为目标的收集器。CMS收集器是基于标记-清除算法实现的，是一种老年代收集器，通常与ParNew一起使用。
CMS的垃圾收集过程分为4步：
初始标记：需要“Stop the World”，初始标记仅仅只是标记一下GC Root能直接关联到的对象，速度很快。
并发标记：是主要标记过程，这个标记过程是和用户线程并发执行的。
重新标记：需要“Stop the World”，为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录（停顿时间比初始标记长，但比并发标记短得多）。
并发清除：和用户线程并发执行的，基于标记结果来清理对象。
CMS垃圾回收器的优缺点分析：
CMS以降低垃圾回收的停顿时间为目的，很显然其具有并发收集，停顿时间低的优点。
缺点主要包括如下：
- 对CPU资源非常敏感，因为并发标记和并发清理阶段和用户线程一起运行，当CPU数变小时，性能容易出现问题。
- 收集过程中会产生浮动垃圾，所以不可以在老年代内存不够用了才进行垃圾回收，必须提前进行垃圾收集。通过参数**-XX:CMSInitiatingOccupancyFraction的值来控制内存使用百分比。如果该值设置的太高，那么在CMS运行期间预留的内存可能无法满足程序所需，会出现Concurrent Mode Failure失败，之后会临时使用Serial Old收集器做为老年代收集器**，会产生更长时间的停顿。
- 标记-清除方式会产生内存碎片，可以使用参数**-XX：UseCMSCompactAtFullCollection**来控制是否开启内
G1（Garbage-First）收集器
G1收集器将新生代和老年代取消了，取而代之的是将堆划分为若干的区域，每个区域都可以根据需要扮演新生代的Eden和Survivor区或者老年代空间，仍然属于分代收集器，区域的一部分包含新生代，新生代采用复制算法，老年代采用标记-整理算法。
通过将JVM堆分为一个个的区域（region）,G1收集器可以避免在Java堆中进行全区域的垃圾收集。G1跟踪各个region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据回收时间来优先回收价值最大的region。
G1收集器的特点：
- 并行与并发：G1能充分利用多CPU，多核环境下的硬件优势，来缩短Stop the World，是并发的收集器。
- 分代收集：G1不需要其他收集器就能独立管理整个GC堆，能够采用不同的方式去处理新建对象、存活一段时间的对象和熬过多次GC的对象。
- 空间整合：G1从整体来看是基于标记-整理算法，从局部（两个Region）上看基于复制算法实现，G1运作期间不会产生内存空间碎片。
- 可预测的停顿：能够建立可以预测的停顿时间模型，预测停顿时间。
和CMS收集器类似，G1收集器的垃圾回收工作也分为了四个阶段：
- 初始标记
- 并发标记
- 最终标记
- 筛选回收
其中，筛选回收阶段首先对各个Region的回收价值和成本进行计算，根据用户期望的GC停顿时间来制定回收计划。
Java版本常用收集器
jdk1.8默认的新生代垃圾收集器：Parallel Scavenge，老年代：Parallel Old
jdk1.9 默认垃圾收集器G1