JVM学习笔记三：垃圾收集器与内存分配策略

内存回收与分配重点关注的是堆内存和方法区内存（程序计数器占用小，虚拟机栈和本地方法栈随线程有相同的生命周期）。

一、判断对象是否存活？

1. 引用计数算法

优势：实现简单，效率高。

致命缺陷：无法解决对象相互引用的问题——会导致对象的引用虽然存在，但是已经不可能再被使用，却无法被回收。

2. 可达性分析算法

对象到GC Roots没有引用链，则回收。

GC Roots包括：

（1）Java虚拟机栈中引用的对象。

（2）方法区中类静态属性引用的对象。

（3）方法去中常量引用的对象。

（4）本地方法栈中Native方法（JNI）引用的对象。

3. 关于引用

JDK1.2之后，Java对引用进行了扩充。

（1）强引用：Object obj = new Object()，不会被jvm回收

（2）软引用：在内存溢出异常发生之前才被强制回收。

（3）弱引用：延迟到下次垃圾回收之前再被回收。

（4）虚引用：仅为了在被回收时收到一个系统通知。

4. finalize方法：

在对象被JVM回收之前，有一个低优先级的线程去执行。只有覆盖了finalize方法，才会执行，且只会执行一次。

5. 回收方法区：

永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。

二、垃圾收集算法

1. 标记-清除算法（Mark-Sweep）

效率问题：标记和清除两个过程的效率都不高。

空间问题：清除后剩余空间零散不连续，无法为大的对象分配内存。

2. 复制算法

将内存分为两个半区，将区A中的存活对象全部复制到B区的连续空间，然后清理A中所有空间。

缺点：内存实际空间减半。在对象存活率较高时需要进行较多的复制操作。

实际应用：将堆内存分为新生代和老年代。由于新生代中的对象98%都是可回收的，故将新生代又划分为Eden空间和两块较小的Survivor空间，默认Eden:Survivor（单个）=8:1

这样每次垃圾收集时，将Eden和S1中的存活对象复制到S2，然后清空Eden和S1区。

为了防止S2中空间不足以存储Eden和S1的所有剩余存活对象，提供老年代作为保障（Handle Promotion：分配担保）。

3. 标记-整理算法（将存活对象移动到一起）

将标记后的存活对象进行移动，清除剩余对象。

应用：老年代

4. 分代收集

新生代：存活率低，使用复制算法

老年代：存活率高，使用“标记-整理”或“标记-清除”算法

三、垃圾收集器

垃圾收集中的并行与并发：

并行（Parallel）：多条垃圾收集线程

并发（Concurrent）：用户线程与垃圾收集线程同时执行

1. Serial收集器

单线程、Stop the World.

Client模式下的默认新生代收集器（一个Client分配给JVM管理的内存一般不会很大，收集时间一般很快）。简单高效（相对于其他单线程收集器）

主要参数：

-XX:SurvivoRatio：新生代中Eden区域和Survivor区域（单个Survivor）的容量比值，默认为8

-XX:PretenureSizeThreshold：直接晋升到老年代的对象大小，大于该值的对象直接在老年代分配。

-XX:HandlePromotionFailure：允许老年代分配担保失败，开启后可以冒险YGC。

2. ParNew收集器

Serial的多线程版本（多条垃圾收集线程）。

Server模式下首选的新生代收集器。

除Serial外，只有它能与CMS收集器配合工作。

3. Parallel Scavenge收集器

新生代、复制算法、多线程。

注重吞吐量，适合后台进程。

-XX:MacGCPauseMillis：最大垃圾收集停顿时间

-XX:GCTimeRatio：吞吐量大小

GCTimeRatio=99，意味着允许最大垃圾收集时间占比为1/(1+99)=1%，GCTimeRatio=用户代码运行时间/GC时间。

-XX:+UseAdaptiveSizePolicy：动态自适应调整JVM参数（-Xmn、SurvivorRatio等）

4. Serial Old收集器

Serial的老年代版本，使用“标准—整理”算法，适合client端。

5. Parallel Old收集器

Parallel Scavenge的老年代版本

6. CMS收集器（Concurrent Mark Sweep）

老年代、GC系统停顿时间最短

“标记-清除”

四个阶段：

（1）初始标记：找GC Roots

（2）并发标记：找引用链

（3）重新标记：找变更

（4）并发清除：清除

（1）（3）：stop the world

（2）（4）：与用户线程并发

缺陷：

对cpu资源敏感：垃圾收集线程数和每个收集线程占用cpu的时间受cpu数量影响

无法处理“浮动垃圾”

即并发清除阶段用户线程又产生的对象。

-XX:CMSInitiatingOccupancyFranction：老年代被使用的百分比，达到时触发GC（如果等老年代占满了再GC，则GC时并发产生的对象可能就获取不到存储空间）

CMSInitiatingOccupancyFranction过高会导致大量Concurrent Mode Failure，即老年代预留的内存无法满足程序需要。

内存空间碎片

-XX:+UseCMSCompactAtFullCollection：FullGC时启动内存碎片的合并整理

-XX:CMSFullGCsBeforeCompaction：执行多少次不压缩的FullGC后压缩一次，默认为0。即每次FullGC时都合并整理内存碎片。

7. G1收集器

最前沿成果。削弱新生代与老年代概念，将整个堆划分为独立的不同Region。根据各Region的回收价值，确定优先列表。

从整体来看：“标记-整理” 算法

从局部（两个Region之间）来看：“复制”算法

四、内存分配与回收策略

1. 优先在Eden区分配（如果启动本地线程分配缓冲TLAB-Thread Local Allocation Buffer，则优先在TLAB）

如果Eden区满，则触发一次Minor GC(也称Young GC)

-XX:+PrintGCDetails

在JVM发生垃圾收集时打印内存回收日志

在进程退出时输出当前各区域的内存分配情况

在JDK8中，PermGen（永久代）被Metaspace（元空间）取代了。

2. 大对象直接进入老年代

-XX:PretenureSizeThreshold：直接进入老年代的对象大小

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

-XX:MaxTenuringThreshold：设置对象在新生代中能存活的最大年龄，默认15

-XX:+PrintTenuringDistribution：打印老年代内的各年龄对象内存分配情况

4. 动态对象年龄判定

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

5. 空间分配担保

（1）YGC发生前先检查“老年代最大可用的连续空间”是否大于新生代所有对象总空间。如果是，则触发YGC,无风险；如果否，进入（2）

（2）再次判断“老年代最大可用的连续空间”是否大于历次平均晋升到老年代的对象大小总和。如果否，则直接执行FullGC；如果是，进入（3）

（3）执行YGC，有风险。

（4）如果3中的YGC失败，则再执行FullGC。

五、垃圾回收和GC实战

1. YGC测试代码：

/**
* @author zni.feng
*/
import java.lang.management.ManagementFactory;

public class YGCTest {
/**
* VM参数： -verbose:gc -XX:+UseSerialGC  -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
*/
private static final int _1MB= 1024 * 1024;

public static void main(String[] args) {
System.out.println(ManagementFactory.getRuntimeMXBean().getInputArguments());//打印JVM参数
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]; //出现一次YGC
System.out.println("exit");
}

}

测试结果：

[-verbose:gc, -XX:+UseSerialGC, -Xms20M, -Xmx20M, -Xmn10M, -XX:+PrintGCDetails, -XX:SurvivorRatio=8, -Dfile.encoding=UTF-8]
[GC (Allocation Failure) [DefNew: 6815K->282K(9216K), 0.0077121 secs] 6815K->6426K(19456K), 0.0077785 secs] [Times: user=0.01 sys=0.01, real=0.01 secs]
exit
Heap
def new generation   total 9216K, used 4620K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
eden space 8192K,  52% used [0x00000007bec00000, 0x00000007bf03c8d8, 0x00000007bf400000)
from space 1024K,  27% used [0x00000007bf500000, 0x00000007bf546800, 0x00000007bf600000)
to   space 1024K,   0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)
tenured generation   total 10240K, used 6144K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
the space 10240K,  60% used [0x00000007bf600000, 0x00000007bfc00030, 0x00000007bfc00200, 0x00000007c0000000)
Metaspace       used 2695K, capacity 4486K, committed 4864K, reserved 1056768K
class space    used 294K, capacity 386K, committed 512K, reserved 1048576K

测试结果分析：

从结果可以看到，发生了一次YGC，GC后新生代（DefNew：Default New Generaion）从6815K降到了282K，即基本上全部回收，而整个堆内存的大小并没有显著减小（从6815K降到了6426K），这是因为allocation1、allocation2、allocation3对象仍存在（强引用），并没有被真正回收，只是从新生代进入了老年代（Survivor区不足以容纳6M的对象）。并且，从程序结束时的各区域内存分配情况可以看到，老年代占用了约6M（tenured generation total 10240K,used 6144K）；新生代Eden区占用了52%，约4M（total 8192K，即8M），是用来存放allocation4的对象。

2. 大对象直接进入老年代

/**
* @author zni.feng
*/
public class PretenureSizeThresholdTest {
/**
* VM参数: -verbose:gc -XX:+UseSerialGC  -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
* -XX:PretenureSizeThreshold=3145728
* (3145728=3*1024*1024=3MB)
*/

private static final int _1MB=1024*1024;
public static void main(String[] args) {
byte[] allocation;
allocation = new byte[4*_1MB];

}

}

测试结果：

Heap
def new generation   total 9216K, used 835K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
eden space 8192K,  10% used [0x00000007bec00000, 0x00000007becd0f90, 0x00000007bf400000)
from space 1024K,   0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)
to   space 1024K,   0% used [0x00000007bf500000, 0x00000007bf500000, 0x00000007bf600000)
tenured generation   total 10240K, used 4096K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
the space 10240K,  40% used [0x00000007bf600000, 0x00000007bfa00010, 0x00000007bfa00200, 0x00000007c0000000)
Metaspace       used 2621K, capacity 4486K, committed 4864K, reserved 1056768K
class space    used 286K, capacity 386K, committed 512K, reserved 1048576K

测试结果分析：可以看到，allocation对象直接进入了老年代。