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

进行垃圾回收的时候肯定是要回收那些已经“死掉”的对象。所以以下就有了几个问题：

（1）哪些对象是死掉的（或者说是哪些对象需要去回收）？

（2）什么时候去回收？

（3）如何去回收？

判断对象是否死亡

有引用计数法和可达性分析两种方法。

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

缺点：当两个对象存在相互引用时候，无法回收。

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

如上图，object5、object6、object7与GC Roots是不相联的。所以它们是可以回收的。

在Java中，一般以下对象可以作为GC Roots:

（1）虚拟机栈（栈帧中的本地变量表）中引用的对象。

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

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

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

引用

判断对象是否死亡，需要用到引用的概念，在Java中一共有四种引用。

强引用就是指在程序代码之中普遍存在的，类似“Object obj=new Object（）”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。

软引用是用来描述一些还有用但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。提供了SoftReference类来实现软引用。

弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK 1.2之后，提供了WeakReference类来实现弱引用。

虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在 JDK 1.2之后，提供了PhantomReference类来实现虚引用。

对象死亡的二次标记

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

如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会放置在一个叫做 F-Queue的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。finalize（）方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize（）中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的 成员变量，那在第二次标记时它将被移除出“即将回收”的集合；如果对象这时候还没有逃脱，那基本上它就真的被回收了。

方法区中的回收

方法区中的垃圾回收性价比比较低，但是也是存在的。主要存在常量的回收和“无用类”的回收

常量回收：当方法区中的一个常量不再被引用就会被回收。

无用类回收：无用类的定义比较“苛刻”。

（1）该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。

（2）加载该类的ClassLoader已经被回收。

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

垃圾收集算法

标记-清除算法：算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有 被标记的对象。缺点：一个是效率问题，标记和清除两个过程的效率都不高;另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

 

复制算法：，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

 

复制算法用于新生代，新生代中的对象98%是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。 当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是 8:1（这个比例可以修改）。分配担保：当一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象时， 这些对象将直接通过分配担保机制进入老年代。

标记-清除-整理算法：标记过程仍然与“标记-清除”算法一样，然后让所有存活的对象都向一端移动，最后直接清理掉端边界以外的内存。

 

分代收集算法

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

枚举根节点

HotSpot的实现中，是使用一组称为OopMap的数据结构来记录那些地方存在对象的引用，这样就避免花费大量时间来进行GC Roots的可达性分析。使用OopMap枚举根节点的时候需要Stop The World。

安全点与安全区域

安全点：程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停。在GC发生时候需要让所有线程跑到最近的安全点停下来，让线程跑到安全点停下来有两种方式：抢占式中断（已经不用了）和主动式中断。安全点是用来解决如何进入GC的。

安全区域：安全区域是指在一段代码片段之中，引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的。我们也可以把Safe Region看做是被扩展了的Safepoint。

在程序不执行的时候，如线程处于Sleep状态或者Blocked状态，这时候线程无法响应JVM的中断请求，“走”到安全的地方去中断挂起，JVM也显然不太可能等待线程重新被分配CPU时间。对于这种情况，就需要安全区域（Safe Region）来解决。

在线程执行到Safe Region中的代码时，首先标识线程自己已经进入了Safe Region，那样，当 在这段时间里JVM要发起GC时，就不用管标识自己为Safe Region状态的线程了。在线程要离 开Safe Region时，它要检查系统是否已经完成了根节点枚举（或者是整个GC过程），如果完 成了，那线程就继续执行，否则它就必须等待直到收到可以安全离开Safe Region的信号为止。

垃圾收集器

Serial收集器：serial是一个单线程垃圾收集器，使用复制算法，在垃圾收集的时候需要Stop The World(暂停其他用户线程)。

 

优点：简单高效，适合在单个CPU工作环境下的新生代垃圾收集，没有线程切换开销。

ParNew收集器：ParNew收集器是Serial收集器的多线程版本，使用复制算法。比Serial并无多大创新点，但是除了Serial,也就它可以和一个非常重要的老年代垃圾收集器CMS配合使用。

 

优点:适合多CPU多线程下的新生代垃圾收集，可以和CMS配合使用。

Parallel Scavenge收集器：一个并行的新生代垃圾收集器，使用复制算法，与ParNew类似。Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX：GCTimeRatio参数。Parallel Scavenge收集器还有一个参数-XX：+UseAdaptiveSizePolicy值得关注。这是一个开关参数，当这个参数打开之后，虚拟机可以自己动态调整新生代大小、Eden和Survivor分区比例、晋升到老年代的年龄等细节参数。以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC 自适应的调节策略（GC Ergonomics）[1]。

优点：缩短垃圾收集时用户线程停顿的时间，达到一个可控的吞吐量。可使用GC自适用调节策略。

Serial Old收集器：serial的老年代收集器，单线程收集，使用标记-整理算法。可以作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

 

Parallel Old收集器：Parallel Scavenge收集器的老年代版本，使用标记-整理算法。可与Parallel Scavenge配合使用

 

CMS收集器：CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS使用的是标记-清除算法（为了获取更快地GC速度,同为老年代的垃圾收集算法“标记-整理”相对较慢）

CMS垃圾收集的四个步骤：

（1）初始标记（CMS initial mark）

（2）并发标记（CMS concurrent mark）

（3）重新标记（CMS remark）

（4）并发清除（CMS concurrent sweep）

初始标记仅仅标记初始标记仅仅标记一下GC Roots能直接关联到的对象。并发标记就是进程GC Roots的追踪过程。重新标记是为了修正并发标记期间用户线程继续运行导致标记发生改变的那一部分标记记录（因为只是在并发标记基础上做修改，不会占用太多时间）。并发清除就是将死亡的对象清除掉。

上面的四个步骤中：初始标记和重新标记需要Stop The World，但是这两个步骤本身的执行时间不长，并发标记和并发清除虽然要多一点时间，但是这两个阶段收集线程和用户线程可以并发执行。所以总的来说，CMS是一款比较优秀的垃圾收集器。

优点：并发收集、低停顿。

缺点：

(1) 既然是并发收集的，对CPU资源敏感，在CPU个数不多( < 4个)的时候表现一般。

(2) 可能出现“Concurrent Mode Failure”失败，而导致另一次Full GC的产生。CMS在并发清除的时候用户线程还在继续执行，这样会产生浮动垃圾，浮动垃圾要在下一次GC的时候才清理掉。这需要为浮动垃圾预留内存空间，而不是在老年代几乎满的时候才去收集。

(3) 使用标记-清除算法，收集后容易产生空间碎片（空间碎片可以合并整理，但是会导致收集变慢）。

 

G1收集器

G1（Garbage-First）收集器是当今收集器技术发展的最前沿成果之一。G1将内存空间分为大小相等的Region，但任然保留新生代老年代的概念。如下图：

 

优点：

（1）并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者 CPU核心）来缩短Stop-The-World停顿的时间。

（2）分代收集：与其他收集器一样，分代概念在G1中依然得以保留。不需要和其他垃圾收集器搭配使用。

（3）空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实 现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。

（4）可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关 注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一 个长度为M毫秒的时间片段内。G1选择回收具有“回收价值大(有限时间内回收后获得的空间大小尽量大)”的Region.

G1垃圾收集的步骤：

（1）初始标记（Initial Marking）

（2）并发标记（Concurrent Marking）

（3）最终标记（Final Marking）

（4）筛选回收（Live Data Counting and Evacuation）

 

CMS的收集过程与CMS很相似，初始标记和最终标记需要STW。最终标记和筛选标记不需要STW。与CMS不同之处在于筛选回收的时候G1优先收集可回收空间比较大的Region，这是为什么收集快的原因，并且可设置有限的收集时间（-XX:MaxGCPauseMills）。

每个region之间的对象引用通过remembered set来维护，每个region都有一个remembered set，remembered set中包含了引用当前region中对象的指针。虚拟机正是通过这个remembered set去避免对整个堆进行扫描来确认可回收的对象。

内存分配策略

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

先看看新生代GC和老年代GC的区别？

新生代GC（Minor 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区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。

（2）大对象直接进入老年代。虚拟机提供了一个-XX：PretenureSizeThreshold参数（Serial和ParNew支持这个参数），令大于这个设置值的对象直接在老年代分配，避免在新生代发生大量的复制。

（3）长期存活的对象将进入老年代。虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被 Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中 每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就 将会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX： MaxTenuringThreshold设置。

（4）动态对象年龄判定。新生代对象晋升到老年代不一定要达到MaxTenuringThreshold设置的年龄。在新生代中相同年龄的对象大小超过Survivor空间一半时，年龄大于等于该年龄的对象可以直接进入老年代，无需等待年龄增大到MaxTenuringThreshold。

（5）空间分配担保。最新的规则是老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full GC。

思考

什么时候会发生FullGC ？

（1）System.gc()的系统调用。大多数情况会进行一次FullGC。

（2）老年代空间不足。老年代剩余空间不足无法满足新生代晋升需要的空间触发FullGC，这是一种比较“正常”的触发FullGC方式。

（3）CMS GC时出现concurrent mode failed。Concurrent mode failed:也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。所以当用户线程占用较多空间而使得老年代空间不足也会触发FullGC。

（4）新生代对象在新生代进行Minor GC时，Survivor空间不足，对象直接进入老年代分配导致老年代空间不足提前触发FullGC。

（5）堆中分配很多大对象，大对象会直接进入老年代导致老年代空间不足触发FullGC。

（6）历次从新生代晋升到老年代的对象的平均大小超过老年代的剩余连续空间大小，空间担保策略会使得老年代触发FullGC。

总而言之，大多都是因为各种原因导致老年代空间不足触发FullGC。