一、概述
1、必要性：目目前内存的动态分配与内存回收技术已经相当成熟，一切看起来都已经进入了“自动化”时代，为何我们还要去了解GC和内存分配呢？——当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集称为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”技术实施必要的监控和调节。
2、垃圾收集进行的区域
程序计数器、虚拟机栈和本地方法栈三个区域具有确定性：它们随线程而生，随线程而灭。当方法结束或者线程结束时内存自然就跟着回收了。因此不需要过多地考虑回收的问题。
Java堆和方法区不具有确定性：一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样。我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存。
二、对象已死吗
在堆里面存放着Java世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象之中哪些还存活着，哪些已经死去（即不可能再被任何途径使用的对象）。
2.1、引用计数算法
定义：给对象中添加一个引用计数器，每当一个地方引用它时，计数器就加1；当引用失效时，计数器就减1；任何时刻计数器为0的对象就是不可能再被使用的。
局限性：无法解决对象之间相互循环引用的问题
2.2、可达性算法
基本思想：通过一系列的称为"GC Roots"的对象为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连（不可达）时，则证明这个对象是不可用的。因此可进行回收。
在Java语言中可作为GC Roots的对象包括以下几种：
1.虚拟机栈（栈帧中的本地变量表）中引用的对象；
2.方法区中类静态属性引用的对象；
3.方法区中常量引用的对象；
4.本地方法栈中JNI（即一般说的native方法）引用的对象；
2.3、引用
1.强引用：在程序代码中普遍存在的，类似“Object obj=new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
2.软引用：在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存才会抛出内存溢出异常。——SoftReference类来实现
3.弱引用：被弱引用关联的对象只能生存到下一次垃圾收集发生之前。——WeakReference类来实现
4.虚引用：一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用的唯一目的就是能在这个对象被垃圾收集器回收时收到一个系统通知。
2.4、生存还是死亡
即使在可达性算法中不可达的对象，也并非是非死不可的，这时候的他们暂时都处于“缓刑”阶段。要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选——是否有必要执行finalize()方法
1.没有必要执行：当对象没有覆盖finalize()方法或者finalize()方法已经被虚拟机调用过。
2.有必要执行：当对象没有覆盖finalize()方法并且finalize()方法还没有被虚拟机调用过。那么对象会被放在一个F-Queue的队列中，虚拟机会“触发”finalize方法，但并不承诺会等待它运行结束。（如果这个对象在finalize方法中执行缓慢，为了避免其他对象永久处于等待，虚拟机就会中断它的finalize方法，并且回收这个对象）。
finalize方法是对象逃脱死亡命运的最后一次机会，对象如果要在finalize中成功拯救自己，只要重新与引用链上的任何一个对象建立关联即可。
但实际上，finalize()能做的所有工作，使用try-catch或者其他方式都可以做得更好、更及时，所以建议大家完全可以忘掉Java语言中有这个方法的存在。
2.5、回收方法区
1.很多人认为方法区中（HotSpot中的永久代）是没有垃圾收集的，Java虚拟机的规范中确实说过可以不要求虚拟机在方法区中实现垃圾收集，主要是因为“性比价”低。但是JDK8已经把垃圾收集扩展到方法区了。
2.永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。
回收废弃常量
与回收Java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说，就是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个“abc”常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。
回收无用类
“无用的类”需要满足三个条件：A、该类所有的实例都已经被回收；B、加载该类的ClassLoader已经被回收；C、该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
3.虚拟机可以对满足上述条件的类进行回收，可以但不是一定。可以通过参数（-Xnoclassgc）设置来控制。
4.在大量使用反射、动态代理、CGLib等ByteCode框架、动态生成JSP以及OSGI这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。
三、垃圾收集算法
3.1、标记——清除算法
算法分“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它是最基础的算法，后续的算法都是基于这种思路并对其不足进行改进。
不足：1.效率问题：标记和清除两个过程效率都不高；2.空间问题：标记清除之后会产生大量不连续的内存碎片，空间碎片太多会导致以后需要分配较大对象时，无法找到足够的连续空间而不得不提前出发另一次垃圾回收动作。
回收前
回收后
3.2、复制算法
它将内存分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活的对象复制到另外一块上面，然后把已使用过的内存空间一次性清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单、运行高效。
不足：这种算法的代价是将内存缩小为原来的一半。
改进：由于新生代中的对象98%是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。（HotSpot中Eden和Survivor的默认比例——8:1）。
当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保。如果另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。
3.3、“标记——整理”算法
复制算法在对象存活率较高时就要进行较多的赋值操作，效率很低。更关键的是如果不想浪费50%的内存空间，就需要有额外的内存空间进行分配担保，以应对被使用内存中对象100%都存活的极端情况，不适合在老年代中使用。
“标记——整理”算法：标记过程仍和“标记——清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有的存活对象都向一端移动，然后直接清理掉边界以外的内存。
3.4、分代收集算法
根据对象存货周期不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点选择最适当的算法。
新生代：大批对象死去，少量存活——选用复制算法
老年代：对象存活率高并且没有额外空间对它进行分配担保——选用“标记——清理”或者“标记——整理”算法
本篇博客摘录自《深入理解Java虚拟机》