絮叨
前面的章节
Java与C++之间有一堵内存动态分配和垃圾收集的高墙 外面的人想进去，里面的人想出来
概述
- 那些内存需要回收？什么时候进行回收？如何进行回收？
- 程序计数器、虚拟机栈、本地方法栈这三部分随着线程而生，随着线程而灭。栈中的栈帧随着方法有序的进出。每一个栈帧中分配内- 存是在类结构确定下来就已知（JIT会在编译时进行些许优化）
- 因此程序计数器、虚拟机栈、本地方法栈这三者内存分配和回收都具备确定性，垃圾回收再这几块不需要你过多的考虑。他们会随着- 线程的回收而自动进行回收。
- Java堆和方法区（Java堆中一个逻辑部分），所以说垃圾回收也是主要考虑到这块的内存的回收和利用。
对象已死？
- 需要判断Java堆中有哪些对象是活着或者死去（即不可能被任何途径使用的对象）
引用计数算法
- 引用计数算法很优秀应用很广泛，但是它很难解决对象之间循环依赖的而导致的问题
- 引用计数算法的存在的缺陷，如上
- JavaVM不是通过引用计数来进行垃圾回收的（来判断对象是否存活）
根可达性分析算法（GC Roots Tracing）
Java中可以作为GC Roots对象包括以下几种：
- 虚拟机栈（栈帧中本地变量表）中引用的对象；
- 方法区中类的静态属性引用的对象；
- 方法区中常量引用的对象；
- 本地方法栈中JNI（一般只Native方法）的引用对象-
示例如下
再谈引用
1.2之前Java中对象只有：引用和未引用两种状态
1.2之后进行了扩充：强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）
- Strong Reference：只要强引用还存在，垃圾回收器就不会进行回收
- Soft Reference：一些还有用，但是非必需的对象。系统将要发生OOM时，会将这些对象列入回收范围，并进行第二次垃圾回收。如- 果回收之后内存还不够则会抛出OOM。Java中提供SoftReference来实现。
- Weak Reference：描述非必需对象。弱引用的关联的对象只能生存到下一次垃圾回收器发生之前。无论内存是否充足，都会回收掉弱- 引用关联的对象。WeakReference类
- Phantom Reference：最弱的一种引用。一个对象是否有虚引用的存在都不会对其生存时间造成影响，也无法通过虚引用来获取一个- 对象的实例。为一个对象设置、虚引用的唯一目的就是希望在该对象被垃圾回收器回收时收到一个系统通知。PhantomReference类。
生存还是死亡
根搜索法不可达的对象，还有两次标记的过程，进行自救。
过程：
在跟搜索算法不可达的对象，并将第一次被标记并且进行一次筛选。筛选条件是：此对象是否有必要调用finalize()方法。当对象没有覆盖finalize或方法已被虚拟机执行了，虚拟机 会认为以上两种情况没有必要执行。
如果这个对象被判定为有必要执行finalize()方法。该对象将会被F-Queue的队列中，稍后虚拟机将建立一个低优先级的Finalizer线程去执行。这里的执行指的是虚拟机会触发该 方法，但是并不承诺等待他运行结束（原因：finalizer执行很慢或死循环，导致队列中其他的对象永远在等待或内存溢出）。finalizer方法是对象逃离死亡的最后一次机会，对象只要finalizer中 拯救自己（建立自己引用）第二次标记的时候该对象就被移除回收队列。如果没有拯救，那么很快不久就被回收。但是如果对象的finalizer方法执行了，但是可能该对象还存活着。
实例代码如下：
public static FinalizerEscapeGC SAVE_HOOK = null; public void isAlive() { System.out.println("yes, i am still alive!!!"); } @Override protected void finalize() throws Throwable { super.finalize(); System.out.println("finalizer method execute"); FinalizerEscapeGC.SAVE_HOOK = this; } public static void main(String[] args) throws Exception { SAVE_HOOK = new FinalizerEscapeGC(); // 对象第一次进行成功的拯救 SAVE_HOOK = null; System.gc(); // 因为finalizer方法的优先级很低，所以暂停0.5s,以等待他运行 Thread.sleep(500); if (SAVE_HOOK != null) { SAVE_HOOK.isAlive(); } else { System.out.println("no, i am dead."); } // 下面的代码和上面的代码一样。但是对象却自救失败了。 // 对象第二次进行成功的拯救 SAVE_HOOK = null; System.gc(); // 因为finalizer方法的优先级很低，所以暂停0.5s,以等待他运行 Thread.sleep(600); if (SAVE_HOOK != null) { SAVE_HOOK.isAlive(); } else { System.out.println("no, i am dead."); } } 复制代码
回收方法区
- 方法区有被认为是HotSpot虚拟机中的永久代
- 误区：Java虚拟机规范中说过，不要求虚拟机在方法区实现垃圾收集，“性价比”很低；回收堆中新生代一般可以回收70%-95%,而永久- 代的垃圾回收远远低于此
- 永久代垃圾回收主要包括：废弃常量和无用的类。
- 回收废弃常量和回收Java堆中对象十分相似。以常量池中的字面值回收为例，“abc”字符串已进入常量池，但是系统中没有任何一个- 地方
- 引用字符串“abc”,也没有其他地方引用。如果这个时候发生内存回收，如果必要的话，该字符串变量则会被回收掉。
判定一个类是否是无用类则比较复杂。
- 该类的所有实例都已经被回收，也就是Java堆中不存在该类的任何实例
- 该类的ClassLoader已经被回收
- 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法 即时是满足以上三个条件，虚拟机也仅仅是可以进行回收。不像对象一样，一定会被回收。对类的回收，Hotspot
提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class及-XX:+TraceClassLoading、-XX:+TraceClassUnLoading 其中前两个参数在product版虚拟机中已经支持，最后一个需要FastDebug版的虚拟机支持。
垃圾收集算法
标记 - 清除算法
- 首先标记处所有需要回收的对象；其次在标记完成之后统一回收掉所有被标记的对象。
- 最基础的算法。后续的算法都是基于此，并针对其缺陷进行改进的得到的。
- 缺点：
- 效率（不高）标记和清除的效率都不高
- 空间问题，标记清除后会导致大量不连续的内存碎片，而碎片过多可能会导致以后程序在运作的过程中，分配较大对象时无法找到足够的连续内存而不得不触发另一次垃圾回收动作
- 图解
标记 - 复制算法(典型的用空间换时间的手法)
- 为了解决效率问题而出现的复制算法
- 复制算法：
- 内容：将可用内存按容量划分成大小相等的两块。每次只是使用其中的一半，将快使用完成后将存活的对象 复制到另外一块内存上去，然后再把使用过的内存一次清理掉。
- 好处1：每次都是对整块内存进行回收，减少了内存碎片的复杂情况
- 好处2：移动时只需移动堆顶指针，按照顺序分配即可，简单高效
- 缺点：内存缩小为原来的一半，有点浪费内存空间 3.图解
- 现代的商业虚拟机都是都是采用这种算法来回收新生代内存。新生代中对象98%都是朝生夕死。并非严格按照1:1。而是按照8:1。
- 1块较大的Eden和2块较小的Survivor内存；每次使用Eden和1个Survivor。（Eden:Survivor = 8:1）
- 这样内存中整个新生代的内存容量为（80+10=90），保证了只有10%的内存容量的浪费。 但是实际发生垃圾回收时我们无法保证98%对象都是标记死亡的，如果存活的对象的占用的内存多于剩下的10%的容量，这时则需要其他内存（老年代）进行分配担保。
标记 - 整理算法
- 复制算法在对象存活率较多时就需要执行较多的复制操作，效率将会降低。
- 关键的是，如果不想浪费50%的内存，就需要有额外的内存空间进行分配担保，以应对已使用内存中的对象100%存活的情况。所以老年代一般不会选择此算法（复制算法）。
- 根据老年代的特点：提出了标记 - 整理算法。标记过程和标记 - 清理一样。但是后续的步骤：不是对可回收的对象进行清理， 而是让所有存活的对象向一端进行移动。然后清理掉端边界以外的内存
- 图解
分代收集算法
- Java堆：新生代和老年代
- 新生代：适合复制算法。只需付出复制少量存活对象的成本就可以完成收集。
- 老年代：（对象的存活率较高，并且没有额外的空间对他进行内存分配）适合使用标记 - 清理或者标记 - 整理算法
HotSpot算法实现
- 以GC Roots节点找引用链为例（作为GC Roots节点主要是全局性引用常量或类的静态属性或执行上下文栈帧中的本地变量表）
- 可达性分析对执行时间十分敏感，GC停顿以确保一致性（Stop The World）
- 准确式GC、OopMap、
