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

概述：

垃圾收集（Garbage Collection GC） GC历史大于java历史，最早出现在Lisp语言

程序计数器、虚拟机栈、本地方法栈三个区域随着线程而生，随线程而灭

1、回收算法思路

1.1 引用计数算法

例如一个对象引用多少次，计数器就是多少，如果为0表示该对象不再用。

弊端：难以解决对象之前的相互循环引用的问题

代码

package learn;

public class ReferenceCountingGC {

	public Object instance = null;
	
	private static final int _1MB = 1024*1024;
	
	/**
	 * 这个成员属性的唯一意义就是占点内存，以便在GC日志中看清楚是否被回收过
	 */
	private byte[] bigSize = new byte[2*_1MB];
	
	public static void main(String [] args){
		ReferenceCountingGC objA = new ReferenceCountingGC();
		ReferenceCountingGC objB = new ReferenceCountingGC();
		objA.instance = objB;
		objB.instance = objA;
		objA = null;
		objB = null;
		
		//假设在这行发现GC，那么objA和objB是否能回收？
		System.gc();
	}
}

修改启动参数：-verbose:gc -Xms20m -Xmx20m -Xmn10m -XX:+PrintGCDetails -XX:SurvivorRatio=8

日志结果：

[GC (System.gc()) [PSYoungGen: 5079K->648K(9216K)] 5079K->656K(19456K), 0.0010334 secs] [Times: user=0.05 sys=0.00, real=0.00 secs] 
[Full GC (System.gc()) [PSYoungGen: 648K->0K(9216K)] [ParOldGen: 8K->572K(10240K)] 656K->572K(19456K), [Metaspace: 2644K->2644K(1056768K)], 0.0037670 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 PSYoungGen      total 9216K, used 82K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 1% used [0x00000000ff600000,0x00000000ff614920,0x00000000ffe00000)
  from space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
  to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
 ParOldGen       total 10240K, used 572K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 5% used [0x00000000fec00000,0x00000000fec8f158,0x00000000ff600000)
 Metaspace       used 2650K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 285K, capacity 386K, committed 512K, reserved 1048576K

如果注释 objA =null ; 和 objB =null ; 两个的日志结果

[GC (System.gc()) [PSYoungGen: 5079K->680K(9216K)] 5079K->4784K(19456K), 0.0021997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (System.gc()) [PSYoungGen: 680K->0K(9216K)] [ParOldGen: 4104K->4668K(10240K)] 4784K->4668K(19456K), [Metaspace: 2644K->2644K(1056768K)], 0.0067037 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
Heap
 PSYoungGen      total 9216K, used 82K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 1% used [0x00000000ff600000,0x00000000ff614920,0x00000000ffe00000)
  from space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
  to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
 ParOldGen       total 10240K, used 4668K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 45% used [0x00000000fec00000,0x00000000ff08f1a8,0x00000000ff600000)
 Metaspace       used 2650K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 285K, capacity 386K, committed 512K, reserved 1048576K

你会发现倒数第三行显示 没有注释显示5% used 和注释后 45% used , 这个也说明它不是基于引用计数算法进行垃圾回收的。

1.2. 根搜索算法

简单来说就是基于图论的理论，从“GC Roots”（根节点）开始搜索，如果该对象不可达，表示它被孤立了，也就是没有用需要清除

作为GCRoots 的对象

• 虚拟机栈(栈帧中的本地变量表) 中引用的对象
• 方法区中的类静态属性引用的对象
• 方法区中的常量引用对象
• 本地方法栈中JNI的引用的对象

1.3 引用继续细分

• 强引用（Strong Reference）：就是new的对象，这个引用垃圾收集器永远不会回收该对象
• 软引用（Soft Reference）：即将内存溢出，会收集这个引用的对象
• 弱引用（Weak Reference）：被弱引用关联的对象智能生存到下一次垃圾收集发生之前，意味着会标记一次
• 虚引用 （Phantom Reference）：为了在回收收到系统通知

1.4.是生还是死？

判断条件就是在第二标记前拯救它，每个对象都有一次被拯救的机会。

代码：

package learn.chapter2;

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 {
		// TODO Auto-generated method stub
		super.finalize();
		System.out.println("fianlize method executed!");
		FinalizeEscapeGC.SAVE_HOOK = this;
	}
	
	public static void main(String[] args) throws InterruptedException {
		SAVE_HOOK = new FinalizeEscapeGC();
		
		//对象第一次成功拯救自己
		SAVE_HOOK = null;
		System.gc();
		//因为Finalizer方法优先级很低， 暂停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();
		//因为Finalizer方法优先级很低， 暂停0.5秒， 以等待它
		Thread.sleep(500);
		if(SAVE_HOOK != null) {
			SAVE_HOOK.isAlive();
		} else {
			System.out.println("no, i am dead :(");
		}
	}
	
	
	
}

结果：

fianlize method executed!
yes, i am still alive
no, i am dead :(

总结：任何一个对象finalize() 方法都只会被系统自动调用一次，如果对象面临下一次回收，它的finalize()方法不会被再次执行。（简单来说就是一个张免死金牌）

1.5.回收方法区

永生代的垃圾收集主要分为两种：废弃常量和无用的类。回收性价比低（费力不讨好）

废弃常量：就是字面量没有变量引用

无用的类：

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

查看类的卸载和装载；

-verbose:class -XX: +TraceClassLoading   -XX:+TraceClassUnLoading 

2.垃圾回收算法

2.1 标记-清除算法 （Mark-Sweep）

分为两个阶段：标记和清除

缺点： 效率低、产生不连续的内存碎片

2.2 复制算法(Copying)

类似两个房间，所有人都住在一个房间里，当一个房间脏了，一起搬到另个地方，同时将脏的房间打扫干净。当另个房间，又切换新打扫房间。

优点：简单、高效

缺点：有点浪费内存

实际上采用并非1:1比例进行分配

2.3 标记整理算法（Mark-Compact）

应对存活率比较高

它类似就是将活的对象移动到一端，端边界以外清除掉。

2.4 分代收集算法（Generational Collection） （就是综合上述算法优点）

将内存分成多块，每块具不同特点，然后采用不同算法

少量存活：复制算法， 存活率高：标记-清除 或标记-整理

3. 垃圾收集器 （内存回收的具体实现）

收集器之间存在的连线，就是说明它们可以搭配使用

3.1 Serial 收集器

单线程的收集器 

特点：stop the world 暂停让我清扫清扫。

优点：简单而高效

适用：Client模式下的虚拟机来说是一个很好的选择

3.2 ParNew 收集器

Serial多线程版本

-XX:ParallelGCThreads 参数来限制垃圾收集的线程数

并行（Parallel）：多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态

并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行，）用户程序继续运行，而垃圾收集程序运行另个一个CPU上

3.3 Parallel Scavenge 收集器

使用复制算法+并行+多线程

目标：达到一个可控制的吞吐量（Throughout） 吞吐量 = 运行用户代码时间/（运行用户代码时间+垃圾收集时间）

虚拟机运行了100分钟，其中垃圾收集花掉1分钟，那么吞吐量就是99%

控制参数： 

控制最大垃圾收集停顿时间：-XX:MaxGCPauseMillis 

设置吞吐量大小：-XX:GCTimeRatio        (0-100)

内存划分自适应：-XX:+UseAdaptiveSizePolicy （不需要手动设置新生代Eden 和Survivor区的比例）

3.4 Serial Old 收集器

Serial Old是Serial收集器的老年版本， 同样是单线程收集器，使用标记-整理算法

3.5 Parallel Old 收集器

Parallel Old 是Parallel Scavenge 收集器的老年代版本，使用多线程和标记-整理算法

3.6 CMS收集器 （Concurrent Mark Sweep）

目标：获取最短回收停顿时间 

适用：B/S系统的服务端上， 基于“标记-清除”

初始标记 （CMS initial mark）

并发标记 (CMS concurrent mark)

重新标记(CMS remark)

并发清除(CMS concurrent sweep)

CMS收集器对CPU资源非常敏感

CMS收集器无法收集浮动垃圾

收集结束产生大量空间碎片

4、内存分配与回收策略

4.1 对象优先在Eden分配

新生代GC（Minor GC） 指发生在新生代的垃圾收集动作

老年代GC（Major GC/FullGC ） 表示发生在老年代的GC

package learn;

public class AllocationGC {

	private static final int _1MB = 1024*1024;
	
	/**
	 * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8
	 * @param args
	 */
	public static void main(String [] args){
		byte[] allocation1, allocation2, allocation3, allocation4;
		allocation1 = new byte[2 * _1MB];
		allocation2 = new byte[2 * _1MB];
		allocation3 = new byte[2 * _1MB];
		allocation4 = new byte[4 * _1MB]; //出现一次MinorGC
	}
}

Heap
 PSYoungGen      total 9216K, used 7291K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 89% used [0x00000000ff600000,0x00000000ffd1efb0,0x00000000ffe00000)
  from space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
  to   space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
 ParOldGen       total 10240K, used 4096K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 40% used [0x00000000fec00000,0x00000000ff000010,0x00000000ff600000)
 Metaspace       used 2650K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 285K, capacity 386K, committed 512K, reserved 1048576K

可以看出：6M在新生代， 而4M在老生代

4.2 大对象直接进入老年代

参数：-XX:PretenureSizeThreshold  设置一个值，表示大于该值放入老生代中

PretenureSizeThreshold 参数只对Serial 和 ParNew 两款收集器有效

4.3 长期存活的对象将进入老年代

熬过一次Minor GC 对象年龄加1 ，当累计到一定晋升到老年代

参数设置： -XX:MaxTenuringThreshold

4.4. 动态对象年龄判定

在Survivor 空间中相同年龄所有对象大小总和大于Survivor空间一半， 年龄大于或等于该对象可以直接进入老年代，无须等待MaxTenuringThreshold中要求的年龄

4.5 空间分配担保

是否需要老生代分配更多的空间。