第3章 垃圾收集器与内存分配策略
概述
为什么要去了解GC（Garbage Collection，垃圾收集）和内存分配？
- 帮助我们排查各种内存溢出、内存泄露问题。
- 当垃圾收集成为系统达到更高并发了的瓶颈时，需要对它们实施必要的监控和调节。
垃圾收集和内存回收都是针对Java堆和方法区来说的。因为程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭，当方法结束或线程结束时，内存自然就跟着回收了。而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间才能知道会创建哪些对象，这部分内存的分配和回收都是动态的。
再说一下什么是 GC Roots ？这个后面会经常见到：
GC(Garbage Collector) Roots，特指的是垃圾收集器（Garbage Collector）的对象，GC会收集那些不是GC Roots且没有被GC Roots引用的对象。
在Java语言中，可作为GC Roots的对象包括：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象。
- 方法区中类静态属性引用的对象。
- 方法区中常量引用的对象。
- 本地方法栈中JNI（即Native方法）引用的对象。
如何判断对象是否存活？（回收Java堆中的对象）
1.引用计数算法（Reference Counting）
- 算法思路：给对象添加一个引用计数器，每当有一个地方引用它，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。
- 缺陷：它很难解决对象之间相互循环引用的问题。因为互相引用着对方，导致它们的引用计数都不为0，于是引用计数算法一直无法通知GC收集器回收它们。
2.可达性分析算法
- 算法思路：通过一系列的 “GC Roots” 作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连（就是从GC Roots 到这个对象不可达）时，则证明此对象是不可用的。
真正宣告一个对象死亡，至少要经历两次标记过程：
- 如果对象在进行可达性分析后，发现没有与 GC Roots 相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize( ) 方法。（没有必要执行的两种情况：对象没有覆盖 finalize( ) 方法，或者 finalize( ) 方法已经被虚拟机调用过。）
- 有必要执行 finalize( ) 方法的对象将会被放置在一个叫做 F-Queue 的队列中，并在稍后由一个虚拟机自动建立的、低优先级的 Finalizer 线程去执行它，稍后GC将对 F-Queue 中的对象进行第二次小规模的标记。对象可以在 finalize( ) 方法 中自我拯救——重新与引用链上的任何一个对象建立关联即可，那它在第二次标记时将被移除出“即将回收”的集合。（这种自救机会只有一次，因为一个对象的 finalize( ) 方法最多只会被系统自动调用一次。如果对象这时候还没有逃脱，那基本上就真的被回收了）
注意：在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收 70%~95% 的空间，
回收方法区（HotSpot虚拟机中也称 永久代）
永久代的垃圾收集主要回收两部分内容：废弃常量 和 无用的类 。
-
回收废弃常量：以常量池中的字面量的回收为例，假如一个字符串“abc” 已经进入了常量池，如果没有任何 String对象 引用常量池中的 “abc” 常量，也没有其他地方引用了这个字面量，如果这时发生了内存回收，而且必要的话，这个 “abc” 常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。
-
回收无用的类：
类需要同时满足下面3个条件才算是“无用的类”：
- 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
- 加载该类的 ClassLoader 已经被回收。
- 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
满足上面3个条件的无用类就可以回收，是“可以”，不是必然。是否对类进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制。
在大量使用 反射、动态代理、CGLib等ByteCode框架、动态生成JSP、以及OSGi这类频繁自定义ClassLoader 的场景都需要虚拟机具备 类卸载 的功能，以保证永久代不会溢出。
如有错误，欢迎留言指正 * _ *