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

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

Java内存运行时区域的各部分, 其中程序计数器、虚拟机栈和本地方法栈线程私有，内存分配和回收具备确定性，方法结束或者线程结束时，内存自然就跟着回收了。
而Java堆和方法区则不一样，个接口中的多个实现类需要的内存可能不一样，一个方法中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收是动态的，垃圾收集器所关注的是这部分的内存。

判断对象死亡依据

---

1. 引用计数算法
   给对象添加一个引用计数器，每当有一个地方引用它的地方，计数器值+1；当引用失效，计数器值就减1;任何时候计数器为0的对象就不可能再被使用了(对象已死)。
   缺点： 无法解决对象相互循环引用的问题。
2. 可达性分析算法
   通过一系列的称为GC Roots的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain）,当一个对象到GC Roots没有任何引用链相连时，则证明此对象不可用。
   在Java语言中，可作为GC Roots的对象包括下面几种：
   1）. 虚拟机栈（栈帧中的本地变量表）中引用的对象。
   2）. 方法区中类静态属性引用的对象。
   3）. 方法区中常量引用的对象。
   4）. 本地方法栈中JNI（即一般说的Native方法）引用的对象。

再谈引用

在JDK 1.2 之后，Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4种，这4种引用强度依次逐渐减弱。

• 强引用：类似“Object obj = new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
• 软引用： 用来描述一些还有用但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK 1.2之后，提供了SoftReference类来实现软引用。
• 弱引用：被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK 1.2之后，提供了WeakReference类来实现弱引用。
• 虚引用： 为一个对象设置虚引用关联的目的能在这个对象被收集器回收时收到一个系统通知。在JDK 1.2之后，提供了PhantomReference类来实现虚引用。

---

生存还是死亡

两次标记：

如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记, 然后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。

如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它(触发，但不一定等待运行结束)。

然后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移除出“即将回收”的集合；如果对象这时候还没有逃脱，那基本上它就真的被回收了。
下面例子可以看出一个对象的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!");
        SAVE_HOOK = this;  // 自救
    }
    public static void main(String[] args) throws InterruptedException {
        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 :(");
        }
    }
}

运行结果：

finalize method executed!
yes, I am still alive :)
no, i am dead :(

注意: 尽量避免使用finalize()方法，因为它不是C/C++中的析构函数，而是Java刚诞生时为了使C/C++程序员更容易接受它所做出的一个妥协。它的运行代价高昂，不确定性大，无法保证各个对象的调用顺序。

---

回收方法区

永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。
“无用的类”，需要满足下面3个条件：

1. 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
2. 加载该类的ClassLoader已经被回收。
3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

-Xnoclassgc参数进行控制是否对类进行回收。

查看类加载和卸载信息参数:
-verbose:class和-XX:+TraceClassLoading可以在Product版的虚拟机中使用。
-XX:+TraceClassUnLoading参数需要FastDebug版的虚拟机支持。

---

垃圾收集算法

标记-清除算法

首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。
效率：标记和清除两个过程的效率都不高。
空间：清除后产生大量不连续的内存碎片，无法为大的对象分配内存。

复制算法

将可用内存分为两个半区A、B，将区A中的存活对象全部复制到B区的连续空间，然后清理A中所有空间。
代价太大，内存实际空间减半。在对象存活率较高时需要进行较多的复制操作。
实际应用：分代收集，将堆内存分为新生代和老年代（根据对象存活周期划分内存）。
由于新生代中的对象98%都是可回收的，故将新生代又划分为Eden空间和两块较小的Survivor空间，默认Eden:Survivor（单个）=8:1。
回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。
当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）

标记-整理算法

标记出所有需要回收的对象，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

分代收集算法

根据对象存活周期的不同将内存分为几块。
新生代: 只有少量存活，可以选用复制算法。
老年代: 对象存活率高，使用标记清除或者标记整理算法。

---

垃圾收集器

这里讨论的收集器是基于JDK 1.7 Update 14之后的Hotpot虚拟机，这个虚拟机包含的所有收集器如下图：

并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另一个CPU上。

1.Serial收集器
单线程、复制算法、Stop the World(STW).
Client模式下的默认的新生代收集器。
没有线程交互的开销，简单高效（相对与其他单线程收集器）
在用户的桌面场景中，分配给虚拟机管理的内存一般不会很大(100 MB级别)，停顿时间能控制在一两百毫秒以内 。
开启参数： -XX:UseSerialGC。

2.ParNew收集器
Serial的多线程版本，新生代、复制算法。
Server模式下首选的新生代收集器(除Serial外，只有它能与CMS收集器配合工作)。
-XX:SurvivorRatio, Eden区域和Survivor区域（单个Survivor）的容量比值，默认为8.
-XX:PretenureSizeThreshold, 晋升老年代对象大小，大于该值的对象直接在老年代分配.
-XX:HandlePromotionFailure, 是否允许老年代分配担保失败，开启后可以冒险进行Minor GC。
-XX:ParallelGCThreads，收集线程数，默认与CPU数量相同。
开启参数：
（1）-XX:+UseConcMarkSweepGC，使用CMS收集器，默认新生代收集器为 ParNew。
（2）-XX:+UseParNewGC 。
ParNew收集器在单CPU环境中不比Serial效果好，甚至可能更差，两个CPU也不一定跑的过，但随着CPU数量的增加，性能会逐步增加。

3.Parallel Scavenge收集器
复制算法、新生代、并行多线程。
收集器的目标则是达到一个可控制的吞吐量(Throughput），适合在后台运算而不需要太多交互的任务。
吞吐量 = 运行用户代码时间 /（运行用户代码时间+垃圾收集时间）。
参数:
-XX:MacGCPauseMillis：最大垃圾收集停顿时间.
-XX:GCTimeRatio：吞吐量大小T，0<=T<=100, 整数，默认为99。
GCTimeRatio = 99，意味着允许最大垃圾收集时间占比为1/(1+99)=1%，GCTimeRatio = 用户代码运行时间/GC时间.
-XX:+UseAdaptiveSizePolicy：动态自适应调整JVM参数（-Xmn、SurvivorRatio等）

4.Serial Old收集器
Serial的老年代版本，单线程收集器，使用标记-整理算法。主要是client模式下的虚拟机使用。
两大用途：
在JDK1.5及之前的版本中与Parallel Scavenge搭配使用。
作为CMS收集器的后备预案。在并发收集发生Concurrent Mode Failure时使用。
5.Parallel Old收集器
Parallel Scavenge收集器的老年代版本，使用多线程和标记-整理算法。在JDK1.6中才开始使用，与Parallel Scavenge配合，吞吐量优先。

6.CMS收集器（Concurrent Mark Sweep）
以获取最短回收停顿时间为目标的收集器，比较理想的应用场景是B/S架构的服务器。
基于标记-清除算法，运行过程分成4个步骤：

1. 初始标记(需要stop the world)，标记一下GC Roots能直接关联到的对象，速度很快。
2. 并发标记，进行GC Roots Tracing的过程。
3. 重新标记(需要stop the world)，为了修正并发标记时用户继续运行而 产生的标记变化，停顿时间比初始标记长，远比并发标记短。
4. 并发清除
   1、3：stop the world
   2、4：与用户线程并发

缺点：

1. CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但是因为占用了一部分CPU资源而导致应用程序变慢，总吞吐量就会降低。CMS默认启动的回收线程数为(CPU数量+3)/4。为了解决这一情况，有一个变种i-CMS,但目前并不推荐使用。
2. CMS收集器无法处理浮动垃圾（floating garbage）.
   即并发清除阶段用户线程又产生的对象。这种垃圾称为浮动垃圾。CMS无法在本次收集中处理掉它们，只好留到下一次GC再处理。
   -XX:CMSInitiatingOccupancyFranction：老年代被使用的百分比，达到时触发GC（如果等老年代占满了再GC，则GC时并发产生的对象可能就获取不到存储空间）
   CMSInitiatingOccupancyFranction过高会导致大量Concurrent Mode Failure，即老年代预留的内存无法满足程序需要。
3. 空间碎片过多（标记-清除算法），提供-XX:+UseCMSCompactAtFullCollection参数，应用于在FULL GC后再进行一个碎片整理过程。-XX:CMSFullGCsBeforeCompaction,多少次不压缩的full gc后来一次带压缩的。

7.G1收集器（面向服务端应用）
特点：
(1). 并行与并发。
(2).分代收集。
(3).空间整合：1）从整体来看：“标记-整理” 算法。2）从局部（两个Region之间）来看：“复制”算法
(4).可预测的停顿。
削弱新生代与老年代概念，将整个堆划分为独立的不同Region。根据各Region的回收价值，确定优先列表。

内存分配策略与回收

---

新生代GC（Minor GC/Young GC)）：指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。

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

1. 对象优先在Eden区分配（如果启动本地线程分配缓冲TLAB，则优先在TLAB上分配）
   如果Eden区满，则触发一次Minor GC。

2. 大对象直接进入老年代
   -XX:PretenureSizeThreshold参数，大于这个设置值的对象直接在老年代分配。(PretenureSizeThreshold参数只对Serial和ParNew两款收集器有效)

3. 长期存活的对象将进入老年代
   -XX:MaxTenuringThreshold：设置对象在新生代中能存活的最大年龄，默认15
   -XX:+PrintTenuringDistribution：打印老年代内的各年龄对象内存分配情况

4. 动态对象年龄判定
   若Survivor中相同年龄的所有对象大小总和超过Survivor的一半，则年龄大于或等于该年龄的对象就可以直接进入老年代。

5. 空间分配担保
   在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC。