GC
GC的全称是garbage collection，中文名称垃圾回收，是对内存管理的一种功能。 垃圾回收器跟踪并回收托管内存中分配的对象，定期执行垃圾回收以回收分配给没有有效引用的对象的内存。 当使用可用内存不能满足内存请求时，GC会自动进行。
特点
- 安全性考虑
- 减少内存泄露
- 减少程序员工作量
从以下几点了解GC
要想深入了解Java的GC，我们应该先探寻如下三个问题：
- What? – 哪些内存需要回收？
- When? – 什么时候回收？
- How? – 如何回收？
What– 哪些内存需要回收？
我们知道，内存运行时JVM会有一个运行时数据区来管理内存。它主要包括5大部分：
- 程序计数器(Program Counter Register)
- 虚拟机栈(VM Stack)
- 本地方法栈(Native Method Stack)
- 方法区(Method Area)
- 堆(Heap)
而其中程序计数器、虚拟机栈、本地方法栈是每个线程私有的内存空间，随线程而生，随线程而亡。 例如栈中每一个栈帧中分配多少内存基本上在类结构去诶是哪个下来时就已知了， 因此这3个区域的内存分配和回收都是确定的，无需考虑内存回收的问题。
但方法区和堆就不同了，一个接口的多个实现类需要的内存可能不一样，
我们只有在程序运行期间才会知道会创建哪些对象，这部分内存的分配和回收都是动态的，
GC主要关注的是这部分内存。
When? – 什么时候回收？
堆
- 如何判断一个对象已经死去？
很容易想到的一个答案是：对一个对象添加引用计数器。每当有地方引用它时，计数器值加1； 当引用失效时，计数器值减1。而当计数器的值为0时这个对象就不会再被使用，判断为已死。 是不是简单又直观。然而，很遗憾。这种做法是错误的！
为什么是错的呢？事实上，用引用计数法确实在大部分情况下是一个不错的解决方案，而在实际的应用中也有不少案例， 但它却无法解决对象之间的循环引用问题。比如对象A中有一个字段指向了对象B，而对象B中也有一个字段指向了对象A， 而事实上他们俩都不再使用，但计数器的值永远都不可能为0，也就不会被回收，然后就发生了内存泄露。
- 正确的：
在Java，C#等语言中，比较主流的判定一个对象已死的方法是： 可达性分析(Reachability Analysis).所有生成的对象都是一个称为”GC Roots”的根的子树。 从GC Roots开始向下搜索，搜索所经过的路径称为引用链(Reference Chain)， 当一个对象到GC Roots没有任何引用链可以到达时，就称这个对象是不可达的（不可引用的），也就是可以被GC回收了。
如下图所示：
5,6,7是不可达的
GC Roots
看了上图以后，又会有一个问题，就是如何选取GC Roots？ 包括以下下几种对象：
- 1.虚拟机栈中引用的对象（就是java函数体中的本地变量表）。
- 2.方法区中类静态属性引用的对象。
- 3.方法区中常量引用的对象。
- 4.本地方法栈中JNI（即一般说的Native方法）引用的对象。
引用
无论是引用计数器还是可达性分析，判定对象是否存活都与引用有关！那么，如何定义对象的引用呢？
我们希望给出这样一类描述：当内存空间还够时，能够保存在内存中；如果进行了垃圾回收之后内存空间仍旧非常紧张，则可以抛弃这些对象。所以根据不同的需求，给出如下四种引用，根据引用类型的不同，GC回收时也会有不同的操作：
- 强引用(Strong Reference):Object obj = new Object();只要强引用还存在，GC永远不会回收掉被引用的对象。
- 软引用(Soft Reference)：描述一些还有用但非必需的对象。在系统将会发生内存溢出之前，会把这些对象列入回收范围进行二次回收（即系统将会发生内存溢出了，才会对他们进行回收。）
- 弱引用(Weak Reference):程度比软引用还要弱一些。这些对象只能生存到下次GC之前。当GC工作时，无论内存是否足够都会将其回收（即只要进行GC，就会对他们进行回收。）
- 虚引用(Phantom Reference):一个对象是否存在虚引用，完全不会对其生存时间构成影响。
方法区
关于方法区中需要回收的是一些废弃的常量和无用的类。
- 废弃的常量的回收。这里看引用计数就可以了。没有对象引用该常量就可以放心的回收了。
- 无用的类的回收。什么是无用的类呢？
- 该类所有的实例都已经被回收。也就是Java堆中不存在该类的任何实例；
- 加载该类的ClassLoader已经被回收；
- 该类对应的java.lang.Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法。
How? – 如何回收？
标记-清除(Mark-Sweep)算法
分为两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。 缺点：效率问题，标记和清除两个过程的效率都不高；空间问题，会产生很多碎片
复制算法
将可用内存按容量划分为大小相等的两块，每次只用其中一块。当这一块用完了， 就将还存活的对象复制到另外一块上面，然后把原始空间全部回收。高效、简单。 缺点：将内存缩小为原来的一半。
标记-整理(Mark-Compat)算法(标记-压缩算法)
标记过程与标记-清除算法过程一样，但后面不是简单的清除，而是让所有存活的对象都向一端移动， 然后直接清除掉端边界以外的内存。
分代收集(Generational Collection)算法
- 新生代中，每次垃圾收集时都有大批对象死去，只有少量存活，就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集；
- 老年代中，其存活率较高、没有额外空间对它进行分配担保，就应该使用“标记-整理”或“标记-清理”算法进行回收。
收集器
#### Serial收集器
单线程收集器，表示在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。Stop The World.
#### ParNew收集器
实际就是Serial收集器的多线程版本。
- 并发(Parallel):指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态；
- 并行(Concurrent):指用户线程与垃圾收集线程同时执行，用户程序在继续运行，而垃圾收集程序运行于另一个CPU上。
#### Parallel Scavenge收集器
该收集器比较关注吞吐量(Throughout)(CPU用于用户代码的时间与CPU总消耗时间的比值)，保证吞吐量在一个可控的范围内。
CMS(Concurrent Mark Sweep)收集器
CMS收集器是一种以获得最短停顿时间为目标的收集器。
G1(Garbage First)收集器
从JDK1.7 Update 14之后的HotSpot虚拟机正式提供了商用的G1收集器，与其他收集器相比， 它具有如下优点：
- 并行与并发
- 分代收集
- 空间整合
- 可预测的停顿等
内存分配
Java技术体系中所提倡的自动内存管理最终可以归结为自动化的解决2个问题：给对象分配内存以及回收分配给对象的内存。
对象优先在Eden分配
大多数情况下，对象在新生代Eden区分配。当Eden区没有足够的内存时，虚拟机将发起一次Minor GC。
- Minor GC(新生代GC):指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC发生的非常频繁。
- Full GC/Major GC(老年代GC):指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC。
大对象直接进老年代
大对象是指需要大量连续内存空间的Java对象（例如很长的字符串以及数组）
长期存活的对象将进入老年代
JVM为每个对象定义一个对象年龄计数器。
- 如果对象在Eden出生并经历过第一次Minor GC后仍然存活，并且能够被Survivor容纳，则应该被移动到Survivor空间中，并且年龄对象设置为1；
- 对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度(默认为15岁，可通过参数-XX:MaxTenuringThreshold设置)，就会被晋升到老年代中。
- 要注意的是：JVM并不是永远的要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一般，年龄大于等于该年龄的对象就可以直接进入老年代，无需等到MaxTenuringThreshold中要求的年龄。
空间分配担保
- 在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，则进行Minor GC是安全的；
- 如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，则急促检查老年代最大可用连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管它是有风险的；
- 如果小于或者HandePromotionFailure设置为不允许冒险，则这时要改为进行一次Full GC.
