一、关于Gc
1.GC是什么? 为什么要有GC呢?
GC是垃圾收集的意思（Garbage Collection）,内存处理是编程人员容易出现问题的地方，忘记或者错误的内存回收会导致程序或系统的不稳定甚至崩溃，Java提供的GC功能可以自动监测对象是否超过作用域从而达到自动回收内存的目的，Java语言没有提供释放已分配内存的显示操作方法。
所以，Java的内存管理实际上就是对象的管理，其中包括对象的分配和释放。
2.对于Java程序员来说，分配对象使用new关键字
释放对象时，只要将对象所有引用赋值为null，让程序不能够再访问到这个对象，我们称该对象为"不可达的".GC将负责回收所有"不可达"对象的内存空间。
对于GC来说，当程序员创建对象时，GC就开始监控这个对象的地址、大小以及使用情况。通常，GC采用有向图的方式记录和管理堆（heap）中的所有对象。通过这种方式确定哪些对象是"可达的"，哪些对象是"不可达的".当GC确定一些对象为"不可达"时，GC就有责任回收这些内存空间。但是，为了保证GC能够在不同平台实现的问题，Java规范对GC的很多行为都没有进行严格的规定。例如，对于采用什么类型的回收算法、什么时候进行回收等重要问题都没有明确的规定。因此，不同的JVM的实现者往往有不同的实现算法。这也给Java程序员的开发带来行多不确定性。本文研究了几个与GC工作相关的问题，努力减少这种不确定性给Java程序带来的负面影响。
Java程序内存主要（这里强调主要二字）分两部分，堆和非堆。大家一般new的对象和数组都是在堆中的，而GC主要回收的内存也是这块堆内存。
二、判定可回收对象
目前最常见的有两种算法用来判定一个对象是否为垃圾。
1.引用计数算法
引用计数算法给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。
优点是简单，高效，现在的objective-c用的就是这种算法。
缺点是很难处理循环引用，比如图中相互引用的两个对象则无法释放。
这个缺点很致命，有人可能会问，那objective-c不是用的好好的吗？我个人并没有觉得objective-c好好的处理了这个循环引用问题，它其实是把这个问题抛给了开发者。
2.可达性分析算法
可达性分析算法（根搜索算法）为了解决上面的循环引用问题，Java采用了一种新的算法：可达性分析算法。
从GC Roots（每种具体实现对GC Roots有不同的定义）作为起点，向下搜索它们引用的对象，可以生成一棵引用树，树的节点视为可达对象，反之视为不可达。
OK，即使循环引用了，只要没有被GC Roots引用了依然会被回收，完美！
但是，这个GC Roots的定义就要考究了，Java语言定义了如下GC Roots对象：
虚拟机栈（帧栈中的本地变量表）中引用的对象。
方法区中静态属性引用的对象。
方法区中常量引用的对象。
本地方法栈中JNI引用的对象。
三、垃圾回收
目前主流有以下几种算法，目前JVM采用的是分代回收算法，而分代回收算法正是从这几种算法发展而来。
1.标记清除算法 (Mark-Sweep)
标记-清除算法分为两个阶段：标记阶段和清除阶段。标记阶段的任务是标记出所有需要被回收的对象，清除阶段就是回收被标记的对象所占用的空间。
优点：简单实现。
缺点：容易产生内存碎片（碎片太多可能会导致后续过程中需要为大对象分配空间时无法找到足够的空间而提前触发新的一次垃圾收集动作）。
2.复制算法 (Copying)
复制算法将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用的内存空间一次清理掉，这样一来就不容易出现内存碎片的问题。
优点：实现简单，运行高效且不容易产生内存碎片。
缺点：对内存空间的使用做出了高昂的代价，因为能够使用的内存缩减到原来的一半。
从算法原理我们可以看出，复制算法算法的效率跟存活对象的数目多少有很大的关系，如果存活对象很多，那么复制算法算法的效率将会大大降低。3.标记整理算法 (Mark-Compact)
该算法标记阶段和Mark-Sweep一样，但是在完成标记之后，它不是直接清理可回收对象，而是将存活对象都向一端移动，然后清理掉端边界以外的内存。
优点：实现简单，不容易产生内存碎片，内存使用高效。
缺点：效率非常低。
所以，特别适用于存活对象多，回收对象少的情况下。
4.分代回收算法
以上几种算法都有各自的优点和缺点，适用于不同的内存情景。而分代回收算法根据Java的语言特性，将复制算法和标记整理算法的的特点相结合，针对不同的内存情景使用不同的回收算法。
这里重复一下两种老算法的适用场景：
复制算法：适用于存活对象很少。回收对象多标记整理算法: 适用用于存活对象多，回收对象少
两种算法刚好互补，不同类型的对象生命周期决定了更适合采用哪种算法。
于是，我们根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Old Generation）和新生代（Young Generation），老年代的特点是每次垃圾收集时只有少量对象需要被回收，使用标记整理算法，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，复制算法，那么就可以根据不同代的特点采取最适合的收集算法。
现在回头去看堆内存为什么要划分新生代和老年代，是不是觉得如此的清晰和自然了？
具体来看：
对于新生代，虽然采取的是复制算法，但是，实际中并不是按照上面算法中说的1：1的比例来划分新生代的空间，而是将新生代划分为一块较大的Eden空间和两块较小的Survivor空间，比例为8：1：1。为什么？下一节深入分析。
老年代的特点是每次回收都只回收少量对象，这符合一个稳定系统的主要特征——超过一半的对象会长期驻留在内存中。所以老年代的比例要大于新生代，默认的新生代：老年代的比例为1：2。
这就是分代回收算法。
四、触发GC的类型
了解这些是为了解决实际问题，Java虚拟机会把每次触发GC的信息打印出来来帮助我们分析问题，所以掌握触发GC的类型是分析日志的基础。
GC_FOR_MALLOC: 表示是在堆上分配对象时内存不足触发的GC。
GC_CONCURRENT: 当我们应用程序的堆内存达到一定量，或者可以理解为快要满的时候，系统会自动触发GC操作来释放内存。
GC_EXPLICIT: 表示是应用程序调用System.gc、VMRuntime.gc接口或者收到SIGUSR1信号时触发的GC。
GC_BEFORE_OOM: 表示是在准备抛OOM异常之前进行的最后努力而触发的GC
五、关于内存回收GC的一些问题
1.为什么不是一块Survivor空间而是两块？
这里涉及到一个新生代和老年代的存活周期的问题，比如一个对象在新生代经历15次（仅供参考）GC，就可以移到老年代了。问题来了，当我们第一次GC的时候，我们可以把Eden区的存活对象放到Survivor A空间，但是第二次GC的时候，Survivor A空间的存活对象也需要再次用Copying算法，放到Survivor B空间上，而把刚刚的Survivor A空间和Eden空间清除。第三次GC时，又把Survivor B空间的存活对象复制到Survivor A空间，如此反复。
所以，这里就需要两块Survivor空间来回倒腾。
2.为什么Eden空间这么大而Survivor空间要分的少一点？
新创建的对象都是放在Eden空间，这是很频繁的，尤其是大量的局部变量产生的临时对象，这些对象绝大部分都应该马上被回收，能存活下来被转移到survivor空间的往往不多。所以，设置较大的Eden空间和较小的Survivor空间是合理的，大大提高了内存的使用率，缓解了Copying算法的缺点。
我看8：1：1就挺好的，当然这个比例是可以调整的，包括上面的新生代和老年代的1：2的比例也是可以调整的。
3.新的问题又来了，从Eden空间往Survivor空间转移的时候Survivor空间不够了怎么办？直接放到老年代去。
Eden空间和两块Survivor空间的工作流程这里本来简单的Copying算法被划分为三部分后很多朋友一时理解不了，也确实不好描述，下面我来演示一下Eden空间和两块Survivor空间的工作流程。
现在假定有新生代Eden，Survivor A， Survivor B三块空间和老生代Old一块空间。
// 分配了一个又一个对象
放到Eden区
// 不好，Eden区满了，只能GC(新生代GC：Minor GC)了
把Eden区的存活对象copy到Survivor A区，然后清空Eden区（本来Survivor B区也需要清空的，不过本来就是空的）
// 又分配了一个又一个对象
放到Eden区
// 不好，Eden区又满了，只能GC(新生代GC：Minor GC)了
把Eden区和Survivor A区的存活对象copy到Survivor B区，然后清空Eden区和Survivor A区
// 又分配了一个又一个对象
放到Eden区
// 不好，Eden区又满了，只能GC(新生代GC：Minor GC)了
把Eden区和Survivor B区的存活对象copy到Survivor A区，然后清空Eden区和Survivor B区
// ...
// 有的对象来回在Survivor A区或者B区呆了比如15次，就被分配到老年代Old区
// 有的对象太大，超过了Eden区，直接被分配在Old区
// 有的存活对象，放不下Survivor区，也被分配到Old区
// ...
// 在某次Minor GC的过程中突然发现：
// 不好，老年代Old区也满了，这是一次大GC(老年代GC：Major GC)
Old区慢慢的整理一番，空间又够了
// 继续Minor GC
// ...
// ...4.关于gc引起卡顿
因为垃圾回收的时候，需要整个的引用状态保持不变，否则判定是判定垃圾，等我稍后回收的时候它又被引用了，这就全乱套了。所以，GC的时候，其他所有的程序执行处于暂停状态，卡住了。
幸运的是，这个卡顿是非常短（尤其是新生代），对程序的影响微乎其微 （关于其他GC比如并发GC之类的，在此不讨论）。
所以GC的卡顿问题由此而来，也是情有可原，暂时无可避免。
总结：
1.在进行GC优化之前，需要确认项目的架构和代码等已经没有优化空间。我们不能指望一个系统架构有缺陷或者代码层次优化没有穷尽的应用，通过GC优化令其性能达到一个质的飞跃。
2.其次，通过上述分析，可以看出虚拟机内部已有很多优化来保证应用的稳定运行，所以不要为了调优而调优，不当的调优可能适得其反。
3.最后，GC优化是一个系统而复杂的工作，没有万能的调优策略可以满足所有的性能指标。GC优化必须建立在我们深入理解各种垃圾回收器的基础上，才能有事半功倍的效果。
