在默认情况下，通过 System.gc()者 Runtime.getRuntime().gc() 的调用，会显式触发 Full GC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。
然而 System.gc()调用附带一个免责声明，无法保证对垃圾收集器的调用(不能 确保立即生效)。
JVM 实现者可以通过 System.gc() 调用来决定 JVM 的 GC 行为。而一般情况 下，垃圾回收应该是自动进行的，无须手动触发，否则就太过于麻烦了。在一些特殊情况下，我们可以在运行之间调用System.gc()。
(调用System.gc()方法会触发Gull GC (整堆收集),但是调用后不一定会立即生效,因为垃圾回收是自动的,一般情况下,不要在项目中显示的调用.)
2.Stop the WorldStop-the-World，简称 STW，指的是 GC 事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为 STW。
可达性分析算法中枚举根节点（GC Roots）会导致所有 Java 执行线程停顿，为 什么需要停顿所有 Java 执行线程呢？
1.分析工作必须在一个能确保一致性的快照中进行
2.一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
3.如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证
4.被 STW 中断的应用程序线程会在完成 GC 之后恢复，频繁中断会让用户感觉
5.像是网速不快造成电影卡带一样，所以我们需要减少 STW 的发生。
6.STW 事件和采用哪款 GC 无关，所有的 GC 都有这个事件。
7.越优秀，回收效率越来越高，尽可能地缩短了暂停时间。
STW 是 JVM 在后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉。
( Stop the World -->STW 在垃圾回收时,会导致整个应用程序停止.
在标记垃圾对象时,需要以某个时间节点上内存中的情况进行分析(拍照 快照)
因为不进行停顿的话,内存中的对象不停的变化,导致分析结果不准确.
停顿是不可避免的,优秀的垃圾回收器尽可能减少停顿的时间.)
我们希望能描述这样一类对象：当内存空间还足够时，则能保留在内存中；如果 内存空间在进行垃圾收集后还是很紧张，则可以抛弃这些对象。
在 JDK1.2 版之后，Java 对引用的概念进行了扩充，将引用分为：
强引用（Strong Reference）
软引用（Soft Reference）
弱引用（Weak Reference）
虚引用（Phantom Reference）
这4种引用强度依次逐渐减弱。除强引用外，其他3种引用均可以在java.lang.ref 包中找到它们的身影。如下图，显示了这 3 种引用类型对应的类，开发人员可以 在应用程序中直接使用它们.
强引用（StrongReference）：
最传统的“引用”的定义，是指在程序代码之 中普遍存在的引用赋值，即类似“Object obj=new Object()”这种引用关系。 无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用 的对象。宁可报 OOM，也不会 GC 强引用
软引用（SoftReference）：在系统将要发生内存溢出之前，将会把这些对象列 入回收范围之中进行第二次回收。如果这次回收后还没有足够的内存，才会抛出 内存溢出异常。
弱引用（WeakReference）：被弱引用关联的对象只能生存到下一次垃圾收集 之前。当垃圾收集器工作时，无论内存空间是否足够，都会回收掉被弱引用关联 的对象。
虚引用（PhantomReference）：一个对象是否有虚引用的存在，完全不会对 其生存时间构成影响，也无法通过虚引用来获得一个对象的实例。为一个对象设 置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
(对象引用:
Object obj = new Object();
就是将对象分等级: 强引用(有引用指向的对象) 软引用 弱引用 虚引用(都是垃圾了)
强引用: Object obj = new Object(); obj引用创建的对象 那么此对象就是被强引用的.
这种情况下,即使内存不够用了,报内存溢出,也不会回收.
软引用: 当内存足够使用时,先不回收这类对象,当虚拟机内存不够用时,要回收此类对象.
弱引用: 此类对象只能生存到下次垃圾回收时, 只要发生垃圾回收,就会回收此类对象.
虚引用: 发现即回收.)
如果说收集算法是内存回收的方法论,那么收集器就是内存回收的实践者.
垃圾收集器没有在 java 虚拟机规范中进行过多的规定，可以由不同的厂商、 不同版本的 JVM 来实现。
由于 JDK 的版本处于高速迭代过程中，因此 Java 发展至今已经衍生了众多 的 GC 版本。
从不同角度分析垃圾收集器，可以将 GC 分为不同的类型。
垃圾回收器(具体实现垃圾回收的收集器名称)
2.垃圾回收器分类按线程数分，可以分为串行垃圾回收器和并行垃圾回收器。
串行回收指的是在同一时间段内只允许有一个 CPU 用于执行垃圾回收操作，此时工作线程被暂停，直至垃圾收集工作结束。
和串行回收相反，并行收集可以运用多个 CPU 同时执行垃圾回收，因此提 升了应用的吞吐量，不过并行回收仍然与串行回收一样，采用独占式，使用 "stop-the-world"机制。
按照工作模式分，可以分为并发式垃圾回收器和独占式垃圾回收器。
并发式垃圾回收器与应用程序线程交替工作，以尽可能减少应用程序的停顿 时间。
独占式垃圾回收器（stop the world）一旦运行，就停止应用程序中的所有 用户线程，直到垃圾回收过程完全结束。
按工作的内存区间分，又可分为年轻代垃圾回收器和老年代垃圾回收器。
(按线程数分，可以分为串行垃圾回收器和并行垃圾回收器
按照工作模式分，可以分为并发式垃圾回收器和独占式垃圾回收器
按工作的内存区间分，又可分为年轻代垃圾回收器和老年代垃圾回收器)
吞吐量：运行用户代码的时间占总运行时间的比例（总运行时间：程序的运 行时间+内存回收的时间）
垃圾收集开销：垃圾收集所用时间与总运行时间的比例。
暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间。
收集频率：相对于应用程序的执行，收集操作发生的频率。
内存占用：Java 堆区所占的内存大小。
快速：一个对象从诞生到被回收所经历的时间
串行回收器：Serial，Serial old
并行回收器：ParNew，Parallel scavenge，Parallel old
并发回收器：CMS、G1
新生代收集器：Serial，ParNew.Parallel scavenge；
老年代收集器：Serial old.Parallel old.cMS；
整堆收集器：G1；
4.1.CMS 回收器(低延迟)
CMS(Concurrent Mark Sweep，并发标记清除)收集器是以获取最短回收停顿 时间为目标的收集器（追求低停顿），它在垃圾收集时使得用户线程和 GC 线程并 发执行，因此在垃圾收集过程中用户也不会感到明显的卡顿。
初始标记：Stop The World，仅使用一条初始标记线程对所有与 GC Roots 直 接关联的对象进行标记。
并发标记：使用多条标记线程，与用户线程并发执行。此过程进行可达性分析， 标记出所有废弃对象。速度很慢。
重新标记：Stop The World，使用多条标记线程并发执行，将刚才并发标记过 程中新出现的废弃对象标记出来。
并发清除：只使用一条 GC 线程，与用户线程并发执行，清除刚才标记的对象。 这个过程非常耗时。
并发标记与并发清除过程耗时最长，且可以与用户线程一起工作，因此，总体上 说，CMS 收集器的内存回收过程是与用户线程一起并发执行的。
CMS 的优点： 并发收集 低延迟
CMS 的弊端：
1.会产生内存碎片，导致并发清除后，用户线程可用的空间不足。在无法分配 大对象的青况下，不得不提前触发 Ful1 GC.
2.CMS 收集器对 CPU 资源非常敏感。在并发阶段，它虽然不会导致用户停顿， 但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。
4.2.G1(Garbage First)回收器(区域划分代式)
应用程序所应对的业务越来越庞大、复杂，用户越来越多，没有 GC 就不能保证应用程序正常进行，而经常造成 STW 的 GC 又跟不上实际的需求，所以才会不断地尝试对 GC 进行优化。
G1（Garbage-First）垃圾回收器是在 Java7 update 4 之后引入的一个新的垃圾回收器，是当今收集器技术发展的 最前沿成果之一. 与此同时，为了适应现在不断扩大的内存和不断增加的处理器数量，进一步 降低暂停时间（pause time），同时兼顾良好的吞吐量。
官方给 G1 设定的目标是在延迟可控的情况下获得尽可能高的吞吐量，所以 才担当起“全功能收集器”的重任与期望。
G1 是一款面向服务端应用的垃圾收集器。
为什么名字叫做 Garbage First（G1）呢？
因为 G1 是一个并行回收器，它把堆内存分割为很多不相关的区域（Region） （物理上不连续的）。使用不同的 Region 来表示 Eden、幸存者 0 区，幸存者 1 区，老年代等。
G1 GC 有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各 个 Region 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时 间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收 价值最大的 Region.
由于这种方式的侧重点在于回收垃圾最大量的区间（Region），所以我们给 G1 一个名字：垃圾优先（Garbage First）。
G1（Garbage-First）是一款面向服务端应用的垃圾收集器，主要针对配备 多核 CPU 及大容量内存的机器，以极高概率满足 Gc 停顿时间的同时，还兼具 高吞吐量的性能特征。
G1 收集器可以 “ 建立可预测的停顿时间模型 ”，它维护了一个列表用 于记录每个 Region 回收的价值大小（回收后获得的空间大小以及回收所需时 间的经验值），这样可以保证 G1 收集器在有限的时间内可以获得最大的回收效率.
G1 收集器收集器收集过程有初始标记、并发标记、最终标记、 筛选回收，和 CMS 收集器前几步的收集过程很相似：
① 初始标记：标记出 GC Roots 直接关联的对象，这个阶段速度较快，需 要停止用户线程，单线程执行。
② 并发标记：从 GC Root 开始对堆中的对象进行可达新分析，找出存活 对象，这个阶段耗时较长，但可以和用户线程并发执行。
③ 最终标记：修正在并发标记阶段引用户程序执行而产生变动的标记记录。
④ 筛选回收：筛选回收阶段会对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来指定回收计划（用最少的时间来回收包 含垃圾最多的区域，这就是 Garbage First 的由来——第一时间清理垃圾最多 的区块），这里为了提高回收效率，并没有采用和用户线程并发执行的方式，而是停顿用户线程。
适用场景：要求尽可能可控 GC 停顿时间；内存占用较大的应用。可以用 -XX:+UseG1GC 使用 G1 收集器，jdk9 默认使用 G1 收集器。
