深入理解JVM - 垃圾收集器与内存分配策略

上一篇介绍了Java内存运行时区域的各个部分，其中程序计数器、虚拟机栈、本地方法栈3个区域随线程生而生，随线程灭而灭；栈中的栈帧随着方法的进入和退出而有条不紊的执行入栈和出栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就是已知的。因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多的考虑内存回收的问题，因为随着方法或线程的结束，这些内存自然就回收了。

而Java堆和方法区则不一样。一个接口的多个实现类需要的内存可能是不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分的内存分配和回收也是动态的。本篇所指的内存分配与回收也仅指这一部分内存。

1、对象已死吗

1.1、引用计数法

给每个对象添加一个引用计数器，每当有一个地方引用它时，计数器值加1；当引用失效时，计数器值减1；任何时刻计数器为0的对象就是不可能再被使用的对象。

目前主流的Java虚拟机没有使用引用计数法来管理内存的，因为它很难解决对象之间相互循环引用的问题。

1.2、可达性分析算法

在主流的商用程序语言（Java、c#等）的主流实现中，都是称通过可达性分析来判定一个对象是否可存活的。

基本思路：通过一系列的成为“GC ROOTS”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径成为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明该对象是不可用的。

在Java语言中，作为GC Roots的对象包含下面几种：

-------------------------执行上下文-------------------------------------

a、虚拟机栈（栈帧中的本地变量表）中引用的对象；

-------------------------全局性引用-------------------------------------

b、方法区中类静态属性中引用的对象；

c、方法区中常量引用的对象；

--------------------------------------------------------------

d、本地方法栈中JNI(即一般所说的Native方法)引用的对象；

上图源于网络，感谢

对象object5、object6、object7虽然相互关联，但是它们到GC Roots是不可达的，所以它们将会被判定为可回收对象。

1.3.、引用

引用分为强、软、弱、虚引用。前三种应该都很熟悉了。简单的说一下第四种：

虚引用又被称为幻影引用或者幽灵引用，它是最弱的一种引用关系。一个对象是否存在虚引用，完全不会对其生存时间构成影响，也无法通过虚引用获取一个对象的实例。为以一个对象设置虚引用关联的唯一目的是能在这个对象被收集器回收时收到一个系统通知。

1.4、回收方法区

很多人认为方法区（或者HotSpot虚拟机中的永久代）是没有垃圾收集的，Java虚拟机规范中确实说过不要求虚拟机在方法区实现垃圾收集，而且在方法区中进行垃圾收集的性价比一般是比较低的。在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收70%~95%的空间，而永久代的垃圾收集的效率远低于此。

永久代的垃圾收集主要回收两部分的内容：废弃常量和无用的类。废弃常量的回收和Java堆中的对象非常类似，比如如果没有任何String对象引用常量池中的“abc”，也没有任何其他地方引用这个字面量，如果发生内存回收，而且必要的话，这个“abc”常量就会被系统清理出常量池。

“无用的类”需同时满足如下的三个条件：

a、该类的所有实例都已经被回收，也就是Java堆中不存在该类的实例；

b、加载该类的ClassLoader已经被回收；

c、该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法；

虚拟机可以对满足上述三个条件的无用类进行回收，这里仅仅是说“可以”，而不是和对象一样，不使用了就必然会被回收。

2、垃圾收集算法

2.1、标记-清除算法

分为标记、清除两个阶段，标记所有需要回收的对象，在标记完成之后统一回收所有被标记的对象。

缺点：标记和清除两个阶段的效率都不高；产生大量的内存碎片；

2.2、复制算法[新生代]

为了解决效率问题，一种被成为“复制”的收集算法出现了。

将可用内存分为两个大小相等的两块，每次只使用其中的一块。当这一块内存使用完了，就将还存活的对象复制到另一块上面，然后再把使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收。

解决了内存碎片过多的问题，但是代价是可使用内存缩小为原来的一半，未免有点太高了。而且当存活对象较多的时候，会进行较多的复制操作。

【现在的商业虚拟机都采用这种收集算法来回收新生代[老年代不使用这种算法，因为需要分配担保]，IBM研究表明新生代中的对象98%是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活的对象一次性复制到另一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8：1，也就是每次新生代中可用内存空间为整个新生代容量的90%，只有10%被浪费掉。当Survivor空间不够的时候，需要依赖其他内存（这里指老年代）进行分配担保，这里所谓的担保就是当另一块Survivor空间不足以存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代】

2.3、标记-整理算法[老年代]

标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清除，而是让所有存活的对象都向一端移动，然后直接清理掉边界以外的内存。

2.4、分代收集算法

当前商业虚拟机的垃圾收集都采用“分代收集”算法。这种算法并没有什么新的思想，只是根据对象存活的周期的不同将内存划分为几块。一般Java堆分为新生代和老年代。

新生代：在新生代中，每次垃圾收集都会发现大批对象死去，只有少量存活，因此使用复制算法。

老年代：对象的存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清除”或者“标记-整理”算法进行回收。

【GC进行时必须停顿所有Java执行线程】

【关于HotSpot的算法实现，可查看书籍72页】

以上只是垃圾收集的算法思想，在JVM中真正落地实现垃圾回收动作的还是GC收集器，而且通常虚拟机中往往不止有一种GC收集器。

HotSpot虚拟机垃圾收集器

 HotSpot在新生代和老年代使用了七种作用不同的垃圾收集器。

3、内存分配与回收策略

Java技术体系所提倡的自动内存管理最终可以归纳为自动化的解决两个问题：给对象分配内存以及回收分配给对象的内存。回收策略在可以查看第二部分，本小节将探讨对象内存分配那点事。

对象的内存分配，往大的方向讲，就是在堆上分配（但也可能经过JIT编译后被拆散为标量类型并间接的在栈上分配），对象主要分配在新生代Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB(本地线程分配缓冲)上分配。少数情况下，也可能直接分配在老年代中，分配的规则并不是百分之百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。

3.1、对象优先在Eden分配

大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够的空间进行分配时，虚拟机将发起一次Monitor GC。【新生代的总可用空间是Eden区 + 一个Survivor区的总容量】

private static final int _1MB = 1024 * 1024;

	/**
	 * VM 参数：-verbose:gc -Xms20M -Xmx20M -Xmn 10M -Xx:+printGCDetails
	 * -XX:SurviorRatio=8
	 * 上述参数含义：限制堆大小为20M，其中新生代10M，老年代10M，新生代中Eden和Survivor分配比例为8：1
	 */

	public void testAllocation() {
		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];// 出现一次Monitor GC
	}

上述代码中，新生代可用内存是9MB（Eden：8M + Survivor：1MB），由于新生代采用的是复制算法，因此在分配allocation1,allocation2,allocation3的时候都没有什么问题，空间足够。但是，在分配allocation4的时候，新生代只剩下了3MB，不足以容下4MB，因此发生了Monitor GC，GC期间虚拟机发现已有的三个2MB大小的对象全部无法放入另一块Survivor空间（只有1MB）,所以通过分配担保机制提前转移到老年代。

这次GC结束之后，4MB的allocation4对象顺利的分配到了新生代Eden区中，因此程序运行完的结果是Eden占用4MB，Survivor空闲，老年代被占用了6MB。

3.1.1.GC分类

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

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

3.2、大对象直接进入老年代

所谓的大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组，比如3.1中的allocation1等，大对象对虚拟机来说是一个坏消息，经常出现大对象容易导致内存还有空间时就提前触发了垃圾收集以获取足够的连续空间来“安置”它们。

虚拟机提供了一个-XX:PretenureSizeThresholdc参数，令大于这个设置值的对象直接在老年代上分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制。

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

既然虚拟机采用分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这点，虚拟机为每一个对象定义了一个对象年龄计数器。如果对象在Eden出生并经过第一次Monitor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象的年龄设为1。对象在Survivor区中每“熬过”一次Monitor GC，年龄就增加一岁，当它的年龄增加到一定程度（默认15岁），就将会晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold设置。

3.4、动态对象年龄判定

为了更好的适应不同程序的内存状况，虚拟机并不是永远要求对象的年龄必须达到了MaxTenuringThreshold才能晋升到老年代，如果在Survivor空间中相同年龄所有对象大小总和大于Survivor空间的一半，年龄大于或者等于改年龄的对象就可以直接进入老年代，无需等到MaxTenuringThreshold中要求的年龄。

3.5、空间分配担保

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

上述所说的冒险到底是冒的什么险呢？

前面提到过，新生代使用复制收集算法，但是为了内存利用率。只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况（最极端的情况是内存回收之后，新生代中所有的对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象存活下来在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多空间。

取平均值进行比较其实仍然是一种动态概率的手段，也就是说，如果某次Minor GC存活后的对象突增，远远高于平均值的话，依然会导致担保失败。如果出现HandlerPromotionFailure失败，那就只好在失败后重新发起一次FULL GC。虽然担保失败时绕的圈子是最大的，但大部分情况下都还是将HandlerPromotionFailure开关打开，避免Full GC过于频繁。