介绍 GC 基础原理和理论
目标
大多数情况下对 Java 程序进行 GC 调优, 主要关注两个目标: 响应速度、吞吐量
响应速度(Responsiveness) 响应速度指程序或系统对一个请求的响应有多迅速。比如，用户订单查询响应时间，对响应速度要求很高的系统，较大的停顿时间是不可接受的。调优的重点是在短的时间内快速响应
吞吐量(Throughput) 吞吐量关注在一个特定时间段内应用系统的最大工作量，例如每小时批处理系统能完成的任务数量，在吞吐量方面优化的系统，较长的GC停顿时间也是可以接受的，因为高吞吐量应用更关心的是如何尽可能快地完成整个任务，不考虑快速响应用户请求
GC调优中，GC导致的应用暂停时间影响系统响应速度，GC处理线程的CPU使用率影响系统吞吐量
GC 垃圾回收算法
标记-清除算法(Mark-Sweep)
最基础的垃圾回收算法，之所以说它是最基础的是因为它最容易实现，思想也是最简单的。标记-清除算法分为两个阶段：标记阶段和清除阶段。标记阶段的任务是标记出所有需要被回收的对象，清除阶段就是回收被标记的对象所占用的空间。
标记-清除算法采用从根集合（GC Roots）进行扫描，对存活的对象进行标记，标记完毕后，再扫描整个空间中未被标记的对象，进行回收，如下图所示。标记-清除算法不需要进行对象的移动，只需对不存活的对象进行处理，在存活对象比较多的情况下极为高效，但由于标记-清除算法直接回收不存活的对象，因此会造成内存碎片。
复制算法(Copying)
为了解决Mark-Sweep算法的缺陷，Copying算法就被提了出来。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用的内存空间一次清理掉，这样一来就不容易出现内存碎片的问题。
这种算法虽然实现简单，运行高效且不容易产生内存碎片，但是却对内存空间的使用做出了高昂的代价，因为能够使用的内存缩减到原来的一半。
Copying算法的效率跟存活对象的数目多少有很大的关系，如果存活对象很多，那么Copying算法的效率将会大大降低。
标记-整理算法(Mark-compact)
标记-整理算法采用标记-清除算法一样的方式进行对象的标记，但在清除时不同，在回收不存活的对象占用的空间后，会将所有的存活对象往左端空闲空间移动，并更新对应的指针。标记-整理算法是在标记-清除算法的基础上，又进行了对象的移动，因此成本更高，但是却解决了内存碎片的问题。
分代收集算法 Generational Collection（分代收集）算法
分代收集算法就是目前虚拟机使用的回收算法，它解决了标记整理不适用于老年代的问题，将内存分为各个年代，在不同年代使用不同的算法，从而使用最合适的算法，新生代存活率低，可以使用复制算法。而老年代对象存活率高，没有额外空间对它进行分配担保，所以使用标记整理算法。具体请看下面介绍
GC 分代收集算法
将 Java 的堆内存逻辑上分成两块: 新生代、老年代，针对不同存活周期、不同大小的对象采取不同的垃圾回收策略
“分代回收”是基于这样一个事实: 对象的生命周期不同，所以针对不同生命周期的对象可以采取不同的回收方式，以便提高回收效率。
新生代（Young Generation）
新生代又叫年轻代，大多数对象在新生代中被创建，很多对象的生命周期很短。每次新生代的垃圾回收（又称Young GC、Minor GC、YGC）后只有少量对象存活，所以使用复制算法，只需少量的复制操作成本就可以完成回收
新生代内又分三个区：一个Eden区，两个Survivor区(S0、S1，又称From Survivor、To Survivor)，大部分对象在Eden区中生成。
两个Surviver区分别称为“From”区和“To”区。对象在Eden区创建，经过一次Yong GC后，还存活的对象将会被复制到Surviver区的“From”区，此时“To”区是空的。到了下一次GC的时候，Eden区还存活的对象会直接移动到Surviver区的“To”区，而“Form”区的对象有两个去处，“From”区的对象会根据经过的GC次数计算年龄，如果年龄到达了阈值（默认15），则会被移动到老年代中，否则就复制到“To”区，此时“From”区变成了空的，然后“From”区和“To”区进行角色互换，到下一次进行GC时，还是有一块空的“To”区，用来存放从eden区和“From”区移动过来的对象。
老年代（Old Generation）
在新生代中经历了N次垃圾回收后仍然存活的对象，就会被放到老年代，该区域中对象存活率高。老年代的垃圾回收通常使用“标记-整理”算法
GC 事件分类
根据垃圾收集回收的区域不同，垃圾收集主要通常分为Young GC、Old GC、Full GC、Mixed GC
Young GC
新生代内存的垃圾收集事件称为Young GC(又称Minor GC)，当JVM无法为新对象分配在新生代内存空间时总会触发 Young GC，比如 Eden 区占满时。新对象分配频率越高, Young GC 的频率就越高
Young GC 每次都会引起全线停顿(Stop-The-World)，暂停所有的应用线程，停顿时间相对老年代GC的造成的停顿，几乎可以忽略不计
Old GC 、Full GC、Mixed GC
Old GC，只清理老年代空间的GC事件，只有CMS的并发收集是这个模式
Full GC，清理整个堆的GC事件，包括新生代、老年代、元空间等
Mixed GC，清理整个新生代以及部分老年代的GC，只有G1有这个模式
GC日志分析
GC日志是一个很重要的工具，它准确记录了每一次的GC的执行时间和执行结果，通过分析GC日志可以调优堆设置和GC设置，或者改进应用程序的对象分配模式
可以查阅GC 日志详解
内存分配策略
Java提供的自动内存管理，可以归结为解决了对象的内存分配和回收的问题，前面已经介绍了内存回收，下面介绍几条最普遍的内存分配策略
对象优先在Eden区分配
大多数情况下，对象在先新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Young GC大对象之间进入老年代
JVM提供了一个对象大小阈值参数(-XX:PretenureSizeThreshold，默认值为0，代表不管多大都是先在Eden中分配内存)，大于参数设置的阈值值的对象直接在老年代分配，这样可以避免对象在Eden及两个Survivor直接发生大内存复制长期存活的对象将进入老年代
对象每经历一次垃圾回收，且没被回收掉，它的年龄就增加1，大于年龄阈值参数(-XX:MaxTenuringThreshold，默认15)的对象，将晋升到老年代中空间分配担保
当进行Young GC之前，JVM需要预估老年代是否能够容纳Young GC后新生代晋升到老年代的存活对象，以确定是否需要提前触发GC回收老年代空间，基于空间分配担保策略来计算
continueSize: 老年代最大可用连续空间
在发生 MinorGC 之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象的总空间，如果大于，那么Minor GC 可以确保是安全的，如果不大于，
那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代对象的平均大小，如果大于则进行 Young GC，否则可能进行一次 Full GC。
Young GC后晋升对象能被老年代容纳下，则担保成功，否则担保失败，出现”promotion failed”错误，需要 Full GC
动态年龄判定:
新生代对象的年龄可能没达到阈值(MaxTenuringThreshold参数指定)就晋升老年代，如果Young GC之后，新生代存活对象年龄从小到大的累加和总和大于任一Survivor空间的一半，此时S0或者S1区即将容纳不了存活的新生代对象，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄
Safe Point
先提一下STW(Stop The World), STW 即在 GC（Minor GC 或 Full GC）期间，只有垃圾回收器线程在工作，其他工作线程则被挂起，这能造成挺大的性能开销。
由于 Full GC（或Minor GC） 会影响性能，所以我们要在一个合适的时间点发起 GC，这个时间点被称为 Safe Point，这个时间点的选定既不能太少以让 GC 时间太长导致程序过长时间卡顿，也不能过于频繁以至于过分增大运行时的负荷。
一般当线程在这个时间点上状态是可以确定的，如确定 GC Root 的信息等，可以使 JVM 开始安全地 GC。Safe Point 主要指的是以下特定位置：
- 循环的末尾
- 方法返回前
- 调用方法的 call 之后
- 抛出异常的位置
参考链接