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

了解GC(Garbage Collection)的目的：当需要排查各种内存溢出、内存泄露问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，就需要对这些“自动化”的技术实施必要的监控和调节。

3.1 对象已死？

堆中几乎存放着Java世界中所有的对象实例，垃圾收集器在对堆进行回收前，第一件事就是要确定这些对象有哪些还“存活”着，哪些已经“死去”（即不可能再被任何途径使用的对象）。

3.1.1 引用计数算法

很多判断对象是否存活的算法是这样的：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器+1，当引用时效，计数器-1；
任何时刻计数器都为0的章台就是不可能再被使用。

Java语言中没有选用计数算法来管理内存，最主要的原因是它很难解决对象之间的相互循环引用的问题。

3.1.2 根搜索算法

主流的商用程序语言（Java、C#）,都是使用跟搜索算法（GC Roots Tracing）判定对象是否存活的。

这个算法的基本思路就是通过一系列的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain）,当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。

在Java语言里，可作为GC Roots的对象包括以下几种：
- 虚拟机栈（栈帧中的本地变量表）中的引用的对象。
- 方法区中的类静态属性引用的对象。
- 方法区中的常量引用的对象。
- 本地方法中JNI(即一般说的Native方法)的引用的对象。

3.1.3 再谈引用

在JDK1.2之前，Java中的引用定义很传统：如果reference类型的数据中存储的数值代表的是另一块内存的起始地址，就称这块内存代表着一个引用。

在JDK1.2之后，Java对引用概念进行了扩充，将引用分为：
强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）。

• 强引用就是指在程序代码之中普遍存在的，类似”Object obj = new
  Object()“这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
• 软引用用来描述一些还有用，但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中并进行第二次回收，如果这次回收还是没有足够内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现软引用。
• 弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK1.2之后，提供了WeakReference类来实现弱引用。
• 虚引用是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会堆起生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是希望能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用。

3.1.4 生存还是死亡？

要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行根搜索后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法，当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为”没有必要执行“。

如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会被放置在一个名为F-Queue的队列中，并在稍后由一条由虚拟机自动建立的、低优先级的Finalizer线程去执行。这里所谓”执行“是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。原因是，如果一个对象的finalize()方法执行缓慢，或者发生死循环，将可能会导致F-Queue队列中其他对象永久处于等待状态，甚至整个内存回收系统崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己—只要重新与引用链上的任何一个对象建立关联即可，例如把自己赋值给某个类变量或对象的成员变量，那在第二次标记时它将被移除出”即将回收“的集合：如果对象没有逃脱，那就真离死不远了。

3.1.5 回收方法区

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

永久带的垃圾收集主要回收两部分内容：废弃常量和无用的类。
回收废弃常量与回收Java堆中的对象非常相似。判定一个常量是否是”废弃常量“比较简单，而要判定一个类是否是”无用的类“条件则苛刻很多，要同时满足3个条件才可以：

• 该类所有的实例都已经被回收，就是Java堆中不存在该类的任何实例。
• 加载该类的ClassLoader已经被回收。
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
  虚拟机可以对满足上述3个条件的无用类进行回收，这里说的仅仅是”可以“，而不是和对象的一样，不使用了就必然会回收。是否对类进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class及-XX:+TraceClassLoading、-XX:+TraceClassLoading查看累的加载和卸载信息。

在大量使用反射、动态代理、CGLib等bytecode框架的场景，以及动态生成JSP和OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能能够，以保证永久代不会溢出。

3.2 垃圾回收算法

3.2.1 标记-清除算法

最基础的收集算法是”标记-清除（Mark-Sweep）“算法，如它的名字一样，算法分为”标记“和”清除“两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。之所以说它基础，是因为后续收集算法都是基于这种思路并对其缺点进行改进而得到的。

他的主要缺点有两个：一个是效率问题；一个是空间问题，标记清楚后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存二不得不提前出发另一次垃圾收集动作。

3.2.2 复制算法

为了解决效率问题，”复制“（Copying）的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。

现在的商业虚拟机都采用这种和搜集算法来回收新生代，IBM的专门研究表明，新生代中的对象98%是朝生夕死，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中的一块Survivor。当回收时，将Eden和Survivor中还存活着的独享一次性地拷贝到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor的空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，也就是每次新生代中可用内存空间为整个新生代荣光来那个的90%（80%+10%），只有10%的内存时会被”浪费“的。当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。

如果另外一块Survivor空间没有足够的空阿金存放上一次新生代收集下来的存活对象，这些对象将直接通过分配担保机制进入老年代。

3.2.3 标记-整理算法

复制收集算法在对象存活率较高时就要执行较多的复制操作，效率会变低。更关键的是，日过不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。

针对老年代的特点，出现了”标记-整理“（Mark-Compact）算法，标记过程仍然与”标记-清除“算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

3.2.4 分代收集算法

当前商业虚拟机的垃圾收集都采用”分代收集“（Generational Collection）算法，这种算法没有新的思想，只是根据对象的存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代，每次垃圾回收收集是都发现有大批对象的死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用”标记-清理“或”标记-整理“算法来进行回收。

3.3 垃圾收集器

如果说收集算法是内存回收的方法论，垃圾收集器就是内存回收的具体实现。

3.3.1 Serial 收集器

Serial收集器是最基本、历史最悠久的收集器，曾经（在JDK1.3.1之前）是虚拟机新生代收集的唯一选择。这个收集器是一个单线程的收集器，它的”单线程“的意义不仅仅是说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程（Sun将这件事情称之为”Stop The World“），直到它收集结束。

直到现在为止，它依然是虚拟机运行在Client模式下的默认新生代收集器。它也有着优于其他收集器的地方：简单而高效，没有县城交互的开销。Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。

JVM client模式和Server模式
JVM工作在Server模式可以大大提高性能，但应用的启动会比client模式慢大概10%。当该参数不指定时，虚拟机启动检测主机是否为服务器，如果是，则以Server模式启动，否则以client模式启动。

当JVM用于启动GUI界面的交互应用时适合于使用client模式，当JVM用于运行服务器后台程序时建议用Server模式。

JVM在client模式默认-Xms是1M，-Xmx是64M；JVM在Server模式默认-Xms是128M，-Xmx是1024M。我们可以通过运行:Java -version来查看jvm默认工作在什么模式。

3.3.2 ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数（例如：-XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样。

ParNew是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是：除了Serial收集器外，目前只有它能与CMS收集器配合工作。

ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果。

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

3.3.3 Parallel Scavenge收集器

Parallel Scavenge收集器也是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。

Parallel Savenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughtput）。所谓吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）。

停顿时间越短就越适合需要与用户交互的程序，良好的相应速度能提升用户的体验；而高吞吐量则可以最高效的利用CPU时间，尽快的完成程序的运算任务，主要适合在后台运算而不需要太多交互发的任务。

Parallel Scavenge收集器提供了两个参数用户精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数及直接设置吞吐量大小的-XX:GCTimeRatio参数。

MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽力保证内存回收花费的时间不超过设定值。GC停顿时间缩短是以牺牲吞吐量核新生代空间来换取的：系统把新生代调小一些，这也导致垃圾回收此时更频繁。

GCTimeRatio参数的值应当是一个大于0小于100的整数，也就是垃圾回收时间占总时间的比率，相当于是吞吐量的倒数。默认值99，就是允许最大1%（1/(1+99)）的垃圾收集时间。

由于与吞吐量关系密切，Parallel Scavenge收集器也经常被成为“吞吐量优先”收集器。

3.3.4 Serial Old 收集器

Serail Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。这个收集器主要意义也是被Client模式下的虚拟机使用。如果在Server模式下，它主要还有两大用途：一个是在JDK1.5及之前的版本中与Parallel Scavenge收集器搭配使用，另一个就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure的时候使用。

3.3.5 Prallel Old 收集器

Parallel Old 是Prallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器是JDK1.6中才开始提供的，新生代Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了Serail Old(PS MarkSweep)收集器外别无选择。

直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

3.3.6 CMS收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。

CMS是基于“标记-清除”算法实现的，它相对于其他收集器更复杂，分为4个步骤：

• 初始标记 （CMS initial mark）
• 并发标记 （CMS concurrent mark）
• 重新标记 （CMS remark）
• 并发清除 （CMS concurrent sweep）

其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段及时进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记时间短。

由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发自行的。

CMS的有点是：并发收集、低停顿。

CMS的缺点是：

• CMS收集器对CPU资源非常敏感。
• CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。
• CMS是基于“标记-清除”的算法收集器，在收集结束时往往会产生大量空间碎片。

3.3.7 G1收集器

G1(Garbage First)收集器是当前收集器技术发展的最前沿成果。

• 它是基于“标记-整理”算法实现的收集器，就是说它不会产生空间碎片；
• 它可以非常精准的控制停顿；

G1收集器可以实现在基本不牺牲吞吐量的前提下完成低停顿的内存回收，这是由于它能够极力地避免全区域的垃圾收集，之前的收集器进行收集的范围都是整个新生代或老年代，而G1将整个Java堆（包括新生代、老年代）划分为多个大小固定的独立区域（Region），并且跟踪这些区域里面的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域（这就是Garbge First名字的由来）。区域划分及有优先级的区域回收，保证了G1收集器在有限时间内可以活动更改的收集效率。

3.4 内存分配与回收策略

Java技术体系中所提倡的自动内存管理最终可以归结为自动化地解决两个问题：给对象分配内存以及回收分配给对象的内存。

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

3.4.1 对象优先在Eden分配

大多数情况下，对象在新生代Eden区中分配。当Eden区中没有足够的空间进行分配时，虚拟机将发起一次Minor GC。

虚拟机提供了-XX:+PrintGCDetails这个收集器日志参数，告诉虚拟机在繁盛垃圾收集行为时打印内存回收日志，并且在进程退出的时候输出当前内存各区域的分配情况。

-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8

上面的参数限制了Java堆大小为20M，且不可扩展，其中10M分配给新生代，剩下的10M分配各老年代。-XX:SurvivorRatio=8决定了新生代的Eden区与一个Survivor区的空间比例是8比1。

新生代GC(Minor GC):指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
老年代GC（Major GC/Full GC）:发生在老年代的GC，出来了Major GC，经常会伴随至少一次的Minor GC(但不绝对，在ParallelScavenge收集器的收集策略里就有直接继续拧Major GC的策略选择过程)。MajorGC速度一般会比Minor GC慢10倍以上。

private static final int _1MB = 1024*1024;/***VM参数：-verbose:gc -Xms20M -Mmx20M -Xmn10M -*XX:SurvivorRatio=8*/public static void testAllocation(){    byte[] allocation1,allocation2,allocation3,allocation4;    allocatiuon1 = new byte[2*_1MB];    allocatiuon2 = new byte[2*_1MB];    allocatiuon3 = new byte[2*_1MB];    allocatiuon4 = new byte[4*_1MB];//出现一次Minor GC}

当执行分配allocation4对象的语句时会发生一次Minor GC，这次GC结果是新生代6651KB变为148KB，而总内存占用量则几乎没有减少（因为allocation1,2,3对象都存活）。这次GC发生的原因是给allocation4分配内存的时候，发现Eden已经被占用了6MB，剩余空间不足以分配allication4所需的4MB内存，因此发生Minor GC。GC期间虚拟机有风险已有的3个2MB对象全部无法放入Suvivor空间（Survivor空间只有1M大小，所以只靠通过份额皮担保机制提前转移到老年代去）。

这次GC结束后，4MB的allocation4独享被顺利分配在Eden中。因此程序执行完的结果是Eden占用4MB(allocation4占用)，Survivor空闲，老年代被占用6MB(被allocation1、2、3占用)。

3.4.2 大对象直接进入老年代

所谓大对象就是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串及数组。大对象对虚拟机的内存分配来说就是一个坏消息。

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

private static final int _1MB = 1024*1024;/***VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn20M -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=3145728*/public static void testPretenureSizeThreshold(){    byte[] allocation;    allocation = new bute[4*_1MB]; //直接分配在老年代中}

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

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

3.4.4 动态对象年龄判定

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

3.4.5 空间分配担保

在发生Minor GC时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小，如果大于，则改为直接进行一次Full GC。如果小于，则查看HandlePromotionFailure设置是否允许担保失败：如果允许，那只会进行Minor GC;如果不允许，则也要改为进行一次Full GC。

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

取平均值进行比较其实仍然是以后总动态概率的手段，如果某次Minor GC存活后的独享突增，圆圆高于平均值，依然会导致担保失败（Handle Promotion Failure）。如果出现HandlePromotionFailure失败，那就只好在失败后重新发起一次Full GC。虽然担保失败失绕的圈子最大，但大部分情况下还是会将HandlePromitionFailure开关打开，避免Full GC过于频繁。