【深入理解Java虚拟机】垃圾回收与内存分配策略

一：判断对象是否已死（需要回收）的方法

（1）：引用计数算法：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能被使用的。
存在问题：很难解决对象之间相互引用的问题
（2）：可达性分析算法：GC Roots 的对象最为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明这个对象不可达。
GC Roots包括：
1、虚拟机栈（栈帧中的本地变量表）中引用的对象
2、方法区中类静态属性引用的对象
3、方法区中常量引用的对象
4、本地方法栈中JNI引用的对象

二：对象引用类别

Java对象引用分为：强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）
相关API：SoftReference、WeakReference、PhantomReference
软引用：在系统将要发生内存溢出异常之前，将会对这类对象进行回收
弱引用：生存周期，只能生存到下一次垃圾收集发生之前
虚引用：为一个对象设置虚引用关联的唯一目的就是能在这个对象呗收集器回收时收到一个系统通知。

三：对象是否被回收

首先：对象进行可达性分析后发现没有与GCRoots相连接的引用链，将它第一次标记并且进行一次筛选，筛选条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者此方法已经被虚拟机吊用过，虚拟机则认为“没有必要执行”。
如有必要执行finalize()方法，那么此对象会被加入F-Queue队列中，稍后虚拟机自动建立的优先级低的Finalizer线程去执行它。当不承诺会等待它运行结束，这样如果finalize（）执行慢，或者发生死循环，很可能导致F-Queue永久等待，甚至导致垃圾回收系统奔溃。
finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中对象进行第二次标记，如果对象在此期间重新与引用链上任何一个对象关联就能复活，被移出回收队列。否则会被回收。
任何一个对象的finalize()方法都只会被系统自动调用一次。

四：方法区常量和类回收

常量回收条件：无引用
类回收条件：所有实例已经被回收，加载该类的ClassLoader已经被回收，该类对应的Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法。
HotSpot提供 ： -Xnoclassgc
-verbose:class
-XX:+TraceClassLoading 装载
-XX:+TraceClassUnLoading 卸载

五：垃圾回收算法

1、标记-清除算法

算法分为标记，清除两个阶段：首先标记出所有要回收的对象，标记完成后统一回收被标记的对象。
不足：（1）效率问题，标记和清除两个过程的效率都不高。（2）空间问题，标记清除后会产生大量不连续的内存碎片，空间碎片太多可能导致以后内存运行过程中需要分配大对象时，无法找到足够的连续内存分配而不得不提前触发一次垃圾收集操作。

2、复制算法

为了解决效率问题。将内存划分为两块，每次只是用其中一块，当这一块的内存用完了，就将还存活的对象复制到另一块上面，然后把已使用的内存空间一次清理掉。

3、标记-整理算法

标记过程与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉断边界以外的内存。

4、分代收集算法

把java堆内存分为新生代和老年代，然后在不同的年代使用最合适的算法。

六：HotSpot的算法实现

1、枚举根节点

GCRoots时必须执行线程（Stop The World）,保证结果的一致性。
HotSpot中，使用一组称为OopMap的数据结构达到这个目的的，类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。

2、安全点

只有在特定的位置记录生成了OopMap, 这些位置称为安全点（SafePoint）,即程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点才能停顿。
方案：抢占式中断，主动式中断
抢占式中断：在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上，现在几乎没有虚拟机采用抢占式中断来暂停线程从而响应GC事件。
主动式中断：当GC需要中断线程时，不直接对线程操作，仅仅简单的设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时自己中断挂起，轮询标志的地方和安全点重合。

3、安全区域（Safe Region）

指 在一段代码之中，引用关系不会发生变化，那么这个区域中的任意地方开始GC都是安全的。

七：常用垃圾收集器

1.Serial收集器

新生代收集器，单线程收集器，进行垃圾收集时，必须暂停其他所有的工作线程。虚拟机的自动发起 Stop-The-World是很难被用户接受， Serial收集器是对于运行在Client模式下的虚拟机来说是一个很好的选择。

2.ParNew收集器

新生代收集器，ParNew收集器是Serial收集器多线程版本

3.Parallel Scavenge 收集器

是新生代收集器，使用复制算法的收集器，也是并行的多线程收集器
此收集器为了达到一个可控制的吞吐量（Thronghput）.
吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )
-XX:MaxGCPauseMillis 控制最大垃圾收集停顿时间
-XX：GCTimeRatio 控制吞吐量大小 ，大于0小于100的整数
-XX:+UserAdaptiveSizePolicy 开关，是否自适应调节策略

4.Serial Old收集器

老年代收集器，单线程收集器，使用 “标记-整理”算法，主要用于给Client模式下的虚拟机使用。如果是在Server模式下，主要用途是jdk1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，或者作为CMS收集器的后备方案，在并发手机发生Concurrent Mode Failure时使用。

5.Parallel Old收集器

6、CMS (Concurrent Mark Sweep )收集器

CMS收集器是以获取最短回收停顿时间为目标的收集器。
步骤：
（1）、初始标记（CMS initial mark）
（2）、并发标记（CMS concurrent mark)
（3）、重新标记（CMS remark）
（4）、并发清除（CMS concurrent sweep）
其中，初始标记，重新标记这两步依然需要“ Stop The World”，初始标记仅仅只标记一下GCRoots能关联到的对象，速度快，并发标记就是进行GC Root Tracing的过程，重新标记则为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个停顿一般比初始标记长，但远比并发标记的时间短。
由于整个过程耗时最长的并发标记和并发清除过程收集线程都可以与用户线程一起工作，所以，CMS收集器的内存回收过程与用户线程是一起并发执行的。
CMS收集器缺点：
（1）对CPU资源敏感，虽然不会导致用户线程停顿，但是会占用CPU资源导致应用程序变慢，总吞吐量降低。
（2）CMS无法处理浮动垃圾，
（3）CMS是基于 标记–清除算法实现的， 很可能会提前触发Full GC

7、G1收集器

G1是一款面向服务端应用的垃圾收集器。将整个Java堆划分为多个大小相等的独立区域（Region），保留新生代和老年代的概念，但新生代和老年代不再是物理隔离，它们都是一部分Region（不需要连续）的集合。
特点：
（1）、并发与并行，G1能充分利用CPU，多核环境下硬件优势来缩短Stop-The-World停顿时间
（2）、分代收集
（3）、空间整合 ，，基于标记 - 整理算法收集
（4）、可预测停顿：可建立可预测的停顿时间模型