垃圾收集器与内存分配策略

GC

• 哪里需要回收？
• 什么时候回收？
• 如何回收？

线程隔离的内存区域（程序计数器、虚拟机栈、本地方法栈），线程结束时内存回收，无需多虑回收问题。

判断对象是否存活方法

1. 引用计数
   对于一对象，每当有一地方引用，计数器+1；引用失效，计数器-1。
   JVM未使用该方法，没法解决对象之间互相循环引用的问题。

2. 可达性分析

   GCRoots到这个对象不可达时，此对象需要回收

   • GC Roots对象作为起始点
     
     1. 虚拟机栈（栈帧中的本地变量表）中引用的对象。
     2. 方法区中类静态属性引用的对象。
     3. 方法区中常量引用的对象。
     4. 本地方法栈中JNI（即一般说的Native方法）引用的对象。
   • Reference Chain引用链 搜索走过的路径
     下图中的对象都存活

引用

• 强引用
  Object obj = new Object();永不回收被引用对象
• 软引用
  还有用但非必需对象；系统发生内存溢出异常前，将此类对象列进回收范围，进行第二次回收。若此次回收还没足够内存，抛出内存溢出异常。JDK1.2后提供SoftReference类。
• 弱引用
  非必需对象；生存到下一次垃圾收集发生之前；垃圾收集时，无论内存是否足够，都会回收。JDK1.2后提供WeakReference类
• 虚引用
  无法通过虚引用来取得一个对象实例；目的：能在这个对象被收集器回收时收到一个系统通知。JDK1.2后提供PhantomReference类

两次标记过程

不可达对象不一定回收，回收的对象至少经历两次标记过程

1. 不可达对象被第一次标记，并进行筛选：当对象没有覆盖finalize()或者finalize()方法已被虚拟机调用过,则视为“没有必要执行”
2. 若此对象被判为有必要执行finalize()方法，则放入F-Queue队列中，稍后虚拟机建立低优先级的Finalizer线程去执行它（并不承诺等待它运行结束，避免执行缓慢和死循环的问题）。finalize()方法是对象自我救赎的最后机会。执行后只需和引用链上的任何对象关联即可。

/**
 * 此代码演示了两点：
 * 1.对象可以在被GC时自我拯救。
 * 2.自救机会只有一次，因一个对象的finalize()方法最多只会被系统自动调用一次
 */
public class FinalizeEscapeGC {
    public static FinalizeEscapeGC 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("finalize method executed!");
        FinalizeEscapeGC.SAVE_HOOK = this;
    }
    public static void main(String[] args) throws Throwable {
        SAVE_HOOK = new FinalizeEscapeGC();
        //对象第一次成功拯救自己
        SAVE_HOOK = null;
        System.gc();
        //因为finalize方法优先级很低，所以暂停0.5秒以等待它
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no,i am dead：(");
        }
        //下面这段代码与上面的完全相同，但是这次自救却失败了
        SAVE_HOOK = null;
        System.gc();
        //因为finalize方法优先级很低，所以暂停0.5秒以等待它
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no,i am dead：(");
        }
    }
}

SAVE_HOOK对象的finalize（）方法确实被GC收集器触发过，并且在被收集前成功逃脱了。但不建议使用该方法

回收方法区

方法区又称HotSpot的永久代；主要回收废弃常量和无用类

无用类需同时满足：
1. 该类所有实例已被回收（即Java堆中不存在该类实例）
2. 加载该类的ClassLoader已被回收
3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法再任何地方用过反射访问该类的方法

垃圾收集算法

标记-清除法

• 步骤：
  
  1. 标记所需回收对象（可达性+finalize）
  2. 回收被标记的对象
• 缺点：效率不高，大量不连续内存碎片
  

复制算法

• 两块内存合作步骤：
  
  1. 将可用内存按容量划分为大小相等的两块，每次使用其中一块。
  2. 一块用完，存活的对象复制到另一块上
  3. 把已使用过的内存空间清理掉
• 缺点：运行高效，但内存缩小代价太大

• 新生代 一般被分为： 1 * Eden（较大） + 2 * Survivor（较小）
• Eden : Survivor = 8 : 1
• 由于内存不够，老年代一般不直接选用复制收集算法

• 每次使用Eden和一块Survivor（10%空间空闲）：
  
  1. 回收时，以上存活对象复制到另一块Survivor上，再清理
  2. 没法保证只有不多于10%对象存活，空间不够时，依赖老年代内存分配担保
     

标记-整理算法

一般老年代使用

• 步骤：
  
  1. 标记同标记-清除法
  2. 不直接清除，存活对象向一端移动
  3. 清理掉边界以外的内存
     

分代收集算法

• Java堆 分为 新生代 + 老年代
• 新生代用复制算法；老年代用标记-清理or标记-整理

HotSpot的算法实现

• 枚举根节点 （寻找GC Roots）
  
  • 逐个检查引用寻找GC Roots消耗时间
  • GC停顿所有执行线程，Stop the world
  • 类加载完成时，使用OopMap记录GC Roots对象引用
• 安全点 （解决如何进入GC）
  
  • 并非每条指令生成OopMap，特定的位置记录信息，称为安全点
  • 安全点（Safepoint）处才能暂停开始GC
  • 长时间执行的指令才会产生Safepoint（方法调用、 循环跳转、 异常跳转）
  • 考虑如何让执行线程跑到最近的安全点停顿
    
    • 抢占式中断：停顿所有线程，若发现在执行则恢复让它执行到安全点再开始GC（几乎不用）
    • 主动式中断：GC需要中断线程时，设置一个标记，各线程主动轮询标志，发现为真自己中断挂起
• 安全区域 （解决不执行线程）
  
  • 线程处于Sleep或Bolcked，没有分配CPU时间
  • Safe Region指在一段代码中，引用关系不发生变化，在此区域中，任意地方开始GC都是安全的。
  • 线程执行Safe Region代码时，标识自己进入安全区域；线程离开Safe Region时，检查系统是否完成根节点枚举（或整个GC过程），若完成则可继续执行，否则等待收到可安全离开Safe Region信号为止

垃圾收集器

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现
并行：多条垃圾收集线程并行工作，但用户线程等待
并发：用户线程与垃圾线程同时执行

Serial

• 单线程 stop the world
• 必须暂停所有工程线程
• Client模式下默认新生代收集器
• 简单高效；没有线程交互开销
  

ParNew

• 并行多线程 stop the world
• Server模式下的首选新生代收集器
• 除了Serial，只有它能与CMS收集器配合
• 随着CPU的增加，GC效率更高
  

Parallel Scavenge

• 并行多线程 stop the world
• 新生代
• 与前面缩短垃圾收集用户线程停顿时间不同，目的是达到可控制的吞吐量
  （吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间））
  

Serial Old

• 单线程 stop the world
• 老年代
• Client模式下虚拟机
• 吞吐量优先

Parallel Old

• 并行多线程 stop the world
• 老年代

CMS

• 老年代
• 目标：最短回收停顿时间
• 应用：应用集中在互联网站或者B/S系统的服务端上
• 采用标记清除，比前面的标记整理复杂一点，步骤：
  
  1. 初始标记（CMS initial mark） Stop The World
  2. 并发标记（CMS concurrent mark） Stop The World
  3. 重新标记（CMS remark）
  4. 并发清除（CMS concurrent sweep）
• 优点：并发收集，低停顿
• 缺点：
  
  1. 占用CPU资源，总吞吐量低，随CPU的增加而下降
  2. 无法处理浮动垃圾：标记过程中产生的垃圾（只能下次再处理）
  3. 大量空间碎片
     

G1

• 并行与并发
• 单独运行但也有分代概念
• 基于标记-整理，从局部上基于复制算法
• 可预测的停顿
• 将整个Java堆划分为多个大小相等的独立区域（Region）
• 跟踪每个Region的垃圾堆积价值大小，回收价值最大的Region
• 运作步骤：
  
  1. 初始标记（Initial Marking）
  2. 并发标记（Concurrent Marking）
  3. 最终标记（Final Marking）
  4. 筛选回收（Live Data Counting and Evacuation）
• 没有更好的实践，CMS仍然是现在的选择
  

内存分配与回收策略

• 新生代GC（Minor GC）：非常频繁，一般回收速度也比较快。
• 老年代GC（Major GC/Full GC）：经常会伴随至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行
  Major GC的策略选择过程）。 Major GC的速度一般会比Minor GC慢10倍以上。

• 对象优先在Eden分配
  若没足够空间，将发起一次Minor GC(新生代GC)
• 大对象直接进入老年代
• 长期存活的对象将进入老年代
• 动态对象年龄判定
• 空间分配担保