回收哪些内存/对象 引用计数算法 可达性分析算法 finalize()方法 HotSpot实现分析
转载：http://blog.csdn.net/tjiyu/article/details/53982412
1、Java虚拟机垃圾回收
垃圾回收，或称垃圾收集（Garbage Collection，GC）是指自动管理回收不再被引用的内存数据。
在1960年诞生于MIT的Lisp语言首次使用了动态内存分配和垃圾收集技术，可以实现垃圾回收的一个基本要求是语言是类型安全的，现在使用的包括Java、Perl、ML等。
1-1、为什么需要了解垃圾回收
目前内存的动态分配与内存回收技术已经相当成熟，但为什么还需要去了解内存分配与GC呢？
1、当需要排查各种内存溢出、内存泄漏问题时；
2、当垃圾收集成为系统达到更高并发量的瓶颈时；
我们就需要对这些"自动化"技术实话必要的监控和调节；
1-2、垃圾回收需要了解什么
思考GC完成的3件事：
1、哪些内存需要回收？回收Java堆和方法区中的死亡对象。即如何判断对象已经死亡；
2、什么时候回收？即GC发生在什么时候？需要了解GC策略，与垃圾回收器实现有关；
3、如何回收？即需要了解垃圾回收算法，及算法的实现--垃圾回收器，见下一篇文章；
第一点就是本文下面的主题，这是垃圾回收的基础，如：可达性分析算法是后面垃圾回收算法的基础，而判断哪些对象可以回收是垃圾回收的首要任务。
2、判断对象可以回收
垃圾收集器对堆进行回收前，首先要确定堆中的对象哪些还"存活"，哪些已经"死去"；
下面先来了解两种判断对象不再被引用的算法，再来谈谈对象的引用，最后来看如何真正宣告一个对象死亡。
2-1、引用计数算法（Recference Counting）
1、算法基本思路
给对象添加一个引用计数器，每当有一个地方引用它，计数器加1；
当引用失效，计数器值减1；
任何时刻计数器值为0，则认为对象是不再被使用的；不被使用的对象会被标记。
2、优点
实现简单，判定高效，可以很好解决大部分场景的问题，也有一些著名的应用案例；
3、缺点
（A）、很难解决对象之间相互循环引用的问题
如：
- ReferenceCountingGC objA = new ReferenceCountingGC();
- ReferenceCountingGC objB = new ReferenceCountingGC();
- objA.instance = objB;
- objB.instance = objA;
- objA = null;
- objB = null;
当两个对象不再被访问时，因为相互引用对方，导致引用计数不为0；
更复杂的循环数据结构，如图（《编译原理》7-18）：
（B）、并且开销较大，频繁且大量的引用变化，带来大量的额外运算；
主流的JVM都没有选用引用计数算法来管理内存；
2-2、可达性分析算法（Reachability Analysis）
也称为传递跟踪算法；
主流的调用程序语言（Java、C#等）在主流的实现中，都是通过可达性分析来判定对象是否存活的。
1、算法基本思路
通过一系列"GC Roots"对象作为起始点，开始向下搜索；
搜索所走过的路径称为引用链（Reference Chain）；
当一个对象到GC Roots没有任何引用链相连时（从GC Roots到这个对象不可达），则证明该对象是不可用的；会被标记起来
如下图中，对象5/6/7相互关联，但是到GCRoots是不可达的，所以会被判定不可用。
2、GC Roots对象
Java中，GC Roots对象包括：
（1）、虚拟机栈（栈帧中局部变量表）中引用的对象；
（2）、方法区中类静态属性引用的对象；
（3）、方法区中常量引用的对象；
（4）、本地方法栈中JNI（Native方法）引用的对象；
主要在执行上下文中和全局性的引用；
3、优点
更加精确和严谨，可以分析出循环数据结构相互引用的情况；
4、缺点
实现比较复杂；
需要分析大量数据，消耗大量时间；
分析过程需要GC停顿（引用关系不能发生变化），即停顿所有Java执行线程（称为"Stop The World"，是垃圾回收重点关注的问题）；可达性分析是GC的一部分
后面会针对HotSpot虚拟机实现的可达性分析算法进行介绍，看看是它如何解决这些缺点的。
2-3、再谈对象引用
在《Java对象在Java虚拟机中的引用访问方式》曾详细介绍过对象的引用问题，这与对象回收算法有很大关系，下面再来了解下。
java程序通过reference类型数据操作堆上的具体对象；
1、JVM层面的引用
reference类型是引用类型（Reference Types）的一种；
JVM规范规定reference类型来表示对某个对象的引用，可以想象成类似于一个指向对象的指针；
对象的操作、传递和检查都通过引用它的reference类型的数据进行操作；
2、Java语言层面的引用
（i）、JDK1.2前的引用定义
如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用；
这种定义太过狭隘，无法描述更多信息；
（ii）、JDK1.2后，对引用概念进行了扩充，将引用分为：
（1）、强引用（Strong Reference）
程序代码普遍存在的，类似"Object obj=new Object()"；
只要强引用还存在，GC永远不会回收被引用的对象；
（2）、软引用（Soft Reference）
用来描述还有用但并非必需的对象；
直到内存空间不够时（抛出OutOfMemoryError之前），才会被垃圾回收；
最常用于实现对内存敏感的缓存；
SoftReference类实现；
（3）、弱引用（Weak Reference）
用来描述非必需对象；
只能生存到下一次垃圾回收之前，无论内存是否足够；当垃圾回收器工作时，就会回收弱引用关联的对象
WeakReference类实现；
（4）、虚引用（Phantom Reference）
也称为幽灵引用或幻影引用；
完全不会对其生存时间构成影响；
唯一目的就是能在这个对象被回收时收到一个系统通知；
PhantomRenference类实现；
更多请参考JDK相关API说明；
2-4、判断对象生存还是死亡
要真正宣告一个对象死亡，至少要经历两次标记过程。
1、第一次标记
在可达性分析后发现到GC Roots没有任何引用链相连时，被第一次标记；
并且进行一次筛选：此对象是否必要执行finalize()方法；
（A）、没有必要执行
没有必要执行的情况：
（1）、对象没有覆盖finalize()方法；
（2）、finalize()方法已经被JVM调用过；
这两种情况就可以认为对象已死，可以回收；
（B）、有必要执行
对有必要执行finalize()方法的对象，被放入F-Queue队列中；
稍后在JVM自动建立、低优先级的Finalizer线程（可能多个线程）中触发这个方法；
2、第二次标记
GC将对F-Queue队列中的对象进行第二次小规模标记；
finalize()方法是对象逃脱死亡的最后一次机会：（A）、如果对象在其finalize()方法中重新与引用链上任何一个对象建立关联，第二次标记时会将其移出"即将回收"的集合；
（B）、如果对象没有，也可以认为对象已死，可以回收了；
一个对象的finalize()方法只会被系统自动调用一次，经过finalize()方法逃脱死亡的对象，第二次不会再调用；
2-5、finalize()方法
上面已经说到finalize()方法与垃圾回收第二次标记相关，下面了解下在Java语言层面有哪些需要注意的。
finalize()是Object类的一个方法，是Java刚诞生时为了使C/C++程序员容易接受它所做出的一个妥协，但不要当作类似C/C++的析构函数；
因为它执行的时间不确定，甚至是否被执行也不确定（Java程序的不正常退出），而且运行代价高昂，无法保证各个对象的调用顺序（甚至有不同线程中调用）；
如果需要"释放资源"，可以定义显式的终止方法，并在"try-catch-finally"的finally{}块中保证及时调用，如File相关类的close()方法；
此外，finalize()方法主要有两种用途：
1、充当"安全网"
当显式的终止方法没有调用时，在finalize()方法中发现后发出警告；
但要考虑是否值得付出这样的代价；
如FileInputStream、FileOutputStream、Timer和Connection类中都有这种应用；
2、与对象的本地对等体有关
本地对等体：普通对象调用本地方法（JNI）委托的本地对象；
本地对等体不会被GC回收；
如果本地对等体不拥有关键资源，finalize()方法里可以回收它（如C/C++中malloc()，需要调用free()）；
如果有关键资源，必须显式的终止方法；
一般情况下，应尽量避免使用它，甚至可以忘掉它。
更多请参考：
《How to Handle Java Finalization's Memory-Retention Issues》：http://www.devx.com/Java/Article/30192
《Effective Java》第二版 第2章 第7条：避免使用终结方法；
《Thinking in Java》第四版 5.5 清理：终结处理和垃圾回收；
《Java语言规范》12.6 类实例的终结；
3、HotSpot虚拟机中对象可达性分析的实现
前面对可达性分析算法进行介绍，并看到了它在判断对象存活与死亡的作用，下面看看是HotSpot虚拟机是如何实现可达性分析算法，如何解决相关缺点的。
3-1、可达性分析的问题
1、消耗大量时间
从前面可达性分析知道，GC Roots主要在全局性的引用（常量或静态属性）和执行上下文中（栈帧中的本地变量表）；
要在这些大量的数据中，逐个检查引用，会消耗很多时间；
2、GC停顿
可达性分析期间需要保证整个执行系统的一致性，对象的引用关系不能发生变化；
导致GC进行时必须停顿所有Java执行线程（称为"Stop The World"）；
（几乎不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的）
Stop The World：
是JVM在后台自动发起和自动完成的；
在用户不可见的情况下，把用户正常的工作线程全部停掉；
3-2、枚举根节点
枚举根节点也就是查找GC Roots；
目前主流JVM都是准确式GC，可以直接得知哪些地方存放着对象引用，所以执行系统停顿下来后，并不需要全部、逐个检查完全局性的和执行上下文中的引用位置；
在HotSpot中，是使用一组称为OopMap的数据结构来达到这个目的的；
在类加载时，计算对象内什么偏移量上是什么类型的数据；
在JIT编译时，也会记录栈和寄存器中的哪些位置是引用；
这样GC扫描时就可以直接得知这些信息；
3-3、安全点
1、安全点是什么，为什么需要安全点
HotSpot在OopMap的帮助下可以快速且准确的完成GC Roots枚举，但是这有一个问题：
运行中，非常多的指令都会导致引用关系变化；
如果为这些指令都生成对应的OopMap，需要的空间成本太高；
问题解决：
只在特定的位置记录OopMap引用关系，这些位置称为安全点（Safepoint）；
即程序执行时并非所有地方都能停顿下来开始GC，只有在安全点时才能暂停；
2、安全点的选定
不能太少，否则GC等待时间太长；也不能太多，否则GC过于频繁，增大运行时负荷；
所以，基本上是以程序"是否具有让程序长时间执行的特征"为标准选定；
"长时间执行"最明显的特征就是指令序列复用，如：方法调用、循环跳转、循环的末尾、异常跳转等；
只有具有这些功能的指令才会产生Safepoint；
3、如何在安全点上停顿
对于Safepoint，如何在GC发生时让所有线程（不包括JNI线程）运行到其所在最近的Safepoint上再停顿下来？
主要有两种方案可选：
（A）、抢先式中断（Preemptive Suspension）
不需要线程主动配合，实现如下：
（1）、在GC发生时，首先中断所有线程；
（2）、如果发现不在Safepoint上的线程，就恢复该线程让其运行到Safepoint上；
现在几乎没有JVM实现采用这种方式；
（B）、主动式中断（Voluntary Suspension）
（1）、不直接操作线程中断，而是仅简单设置一个标志；
（2）、让各线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起；
而轮询标志的地方和Safepoint是重合的；
在JIT执行方式下：test指令是HotSpot生成的轮询指令；
一条test汇编指令便完成Safepoint轮询和触发线程中断；
3-4、安全区域
1、为什么需要安全区域
对于上面的Safepoint还有一个问题：
程序不执行时没有CPU时间（Sleep或Blocked状态），无法运行到Safepoint上再中断挂起；
这就需要安全区域来解决；
2、什么是安全区域（Safe Region）
指一段代码片段中，引用关系不会发生变化；
在这个区域中的任意地方开始GC都是安全的；
3、如何用安全区域解决问题
安全区域解决问题的思路：
（1）、线程执行进入Safe Region，首先标识自己已经进入Safe Region，那样，当在这段时间里jvm要发起GC时，就不用管这些标识自己为safe region状态的线程了。
（2）、线程要离开Safe Region时，其需要检查系统是否已经完成根节点枚举（或整个GC）；
如果已经完成，就继续执行；
否则必须等待，直到收到可以安全离开Safe Region的信号通知；
这样就不会影响标记结果；
虽然HotSpot虚拟机中采用了这些方法来解决对象可达性分析的问题，但只是大大减少了这些问题影响，并不能完全解决，如GC停顿"Stop The World"是垃圾回收重点关注的问题，后面介绍垃圾回收器时应注意：低GC停顿是其一个关注。
4 内存分配与回收策略
4.1 优先在 Eden 分配
大多数情况下，对象在新生代 Eden 区分配，当 Eden 区空间不够时，发起 Minor GC；
4.2 大对象直接进入老年代
提供 -XX:PretenureSizeThreshold 参数，大于此值的对象直接在老年代分配，避免在 Eden 区和 Survivor 区之间的大量内存复制；
4.3 长期存活的对象进入老年代
JVM 为对象定义年龄计数器，经过 Minor GC 依然存活且被 Survivor 区容纳的，移动到 Survivor 区，年龄加 1，每经历一次 Minor GC 不被清理则年龄加 1，增加到一定年龄则移动到老年区（默认 15 岁，通过 -XX:MaxTenuringThreshold 设置）；
4.4 动态对象年龄判定
若 Survivor 区中同年龄所有对象大小总和大于 Survivor 空间一半，则年龄大于等于该年龄的对象可以直接进入老年代；
4.5 空间分配担保
在发生 Minor GC 之前，JVM 先检查老年代最大可用连续空间是否大于新生代所有对象总空间，成立的话 Minor GC 确认是安全的；否则继续检查老年代最大可用连续空间是否大于历次晋升到老年代对象的平均大小，大于的话进行 Minor GC，小于的话进行 Full GC。
4.6 Full GC 的触发条件
对于 Minor GC，其触发条件非常简单，当 Eden 区空间满时，就将触发一次 Minor GC。而 Full GC 则相对复杂，有以下条件：
4.6.1 调用 System.gc()
此方法的调用是建议 JVM 进行 Full GC，虽然只是建议而非一定，但很多情况下它会触发 Full GC，从而增加 Full GC 的频率，也即增加了间歇性停顿的次数。因此强烈建议能不使用此方法就不要使用，让虚拟机自己去管理它的内存，可通过 -XX:+ DisableExplicitGC 来禁止 RMI 调用 System.gc()。
4.6.2 老年代空间不足
老年代空间不足的常见场景为前文所讲的大对象直接进入老年代、长期存活的对象进入老年代等，当执行 Full GC 后空间仍然不足，则抛出如下错误： Java.lang.OutOfMemoryError: Java heap space 为避免以上两种状况引起的 Full GC，调优时应尽量做到让对象在 Minor GC 阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。
4.6.3 空间分配担保失败
使用复制算法的 Minor GC 需要老年代的内存空间作担保，如果出现了 HandlePromotionFailure 担保失败，则会触发 Full GC。
4.6.4 JDK 1.7 及以前的永久代空间不足
在 JDK 1.7 及以前，HotSpot 虚拟机中的方法区是用永久代实现的，永久代中存放的为一些 class 的信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation 可能会被占满，在未配置为采用 CMS GC 的情况下也会执行 Full GC。如果经过 Full GC 仍然回收不了，那么 JVM 会抛出如下错误信息：java.lang.OutOfMemoryError: PermGen space 为避免 PermGen 占满造成 Full GC 现象，可采用的方法为增大 PermGen 空间或转为使用 CMS GC。
在 JDK 1.8 中用元空间替换了永久代作为方法区的实现，元空间是本地内存，因此减少了一种 Full GC 触发的可能性。
4.6.5 Concurrent Mode Failure
执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足（有时候“空间不足”是 CMS GC 时当前的浮动垃圾过多导致暂时性的空间不足触发 Full GC），便会报 Concurrent Mode Failure 错误，并触发 Full GC。