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

目录

1.垃圾对象判定

1.1.引用计数法（Reference Counting）

1.2. 可达性分析法（Reachability Analysis）

1.3.引用

2.垃圾收集算法

2.1.标记-清除算法

2.2.复制算法

2.3.标记-整理算法

2.4.分代收集算法

3.垃圾收集器

Serial收集器

ParNew收集器

Parallel Scavenge收集器

Serial Old收集器

CMS收集器

G1收集器

4.内存分配

 对象优先在Eden分配

大对象直接进入老年区

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

动态对象年龄判定

空间分配担保

---

 

1.垃圾对象判定

JVM垃圾收集器在对堆进行回收前，第一件事就是判断进行垃圾对象的判定，确定哪些对象还“存活”着，哪些对象已经“死去”。

1.1.引用计数法（Reference Counting）

给对象添加一个引用计数器，每当有一个地方引用它时。计数器值加1；当引用时效时，计数器值减1；任何时刻计数器为0的对象就是不能再被使用的。引用计数算法的实现简单，判定效率也很高，在大部分情况下它都是一个不错的选择，当 Java 语言并没有选择这种算法来进行垃圾回收，主要原因是它很难解决对象之间的相互循环引用问题。

1.2. 可达性分析法（Reachability Analysis）

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

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

在 Java 语言里，可作为 GC Roots 的兑现包括下面几种：

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

1.3.引用

• 强引用（Strong Reference）

只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。类似“Object obj = new Object()”

• 软引用（Soft Reference）

描述一些还有用但非必须的对象。对于软引用关联的对象，在内存不够时，才会进行回收。

• 弱引用（Weak Reference）

弱引用，只能存活到下一次垃圾收集发生之前。在进行垃圾回收时，不管当前内存空间足够与否，都会回收它的内存。

• 虚引用（Phantom Rererence）

为一个对象设置虚引用关联的唯一目的就是能在这个对象被回收时收到一个系统通知。

2.垃圾收集算法

2.1.标记-清除算法

标记-清除（Mark-Sweep）

•         首先标记出所有需要回收的对象
•         在标记完成后统一回收所有被标记的对象。

缺点：1.效率问题，标记和清除两个过程的效率都不高

           2.空间问题，标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后程序在运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前出发另一次垃圾收集动作。

效率问题

2.2.复制算法

将可用内存按容量大小划分为大小相等的两块，每次只使用其中的一块。当一块内存使用完了，就将还存活着的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况。

缺点：只是用了一半的内存

现在的商业虚拟机都采用这种算法来回收新生代。将内存分为Eden和from Survivor、to Survivor，HotSpot虚拟机默认Eden:Survivor=8:1。每次使用Eden和一个Survivor，当回收时，将Eden和Survivor中还存活的对象复制到另一块Survivor上，当内存不够使，依赖老年代进行分配担保。

2.3.标记-整理算法

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

2.4.分代收集算法

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

3.垃圾收集器

HotSpot垃圾收集器

• Serial收集器

单线程收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集时，必须暂停其他所有的工作线程（stop the world），直到它收集结束。

优势：简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程效率。

• ParNew收集器

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

• Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器，与其他收集器的关注点不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）。

• Serial Old收集器

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器。

• Parallel Old收集器

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

• 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收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。

• CMS收集器无法处理浮动垃圾，可能出现“Conurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会产生新的垃圾，这一部分垃圾出现在标记过程之后，CMS无法在档次收集中处理掉它们，只好留待下一次GC时再清理掉。这部分垃圾就称为“浮动垃圾”。

• CMS是一款基于“标记-清除”算法实现的收集器，所以会有大量空间碎片问题。

• G1收集器

1. 并行与并发 能充分利用多CPU，多核环境下的硬件优势，缩短Stop-The-World停顿的时间，同时可以通过并发的方式让Java程序继续执行

2. 分代收集 可以不需要其他收集器的配合管理整个堆，但是仍采用不同的方式去处理分代的对象。将整个堆划分为一个个等大小的区域，内存的回收和划分都以region为单位

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

4. 可预测停顿 能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

4.内存分配

对象的内存分配，往大方向讲，就是在堆上分配（但也可能经过JIT编译后被拆散为标量类型并间接地栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。

•  对象优先在Eden分配

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

• 大对象直接进入老年区

所谓大对象是指，需要大量连续内存空间的Java对象,最典型的大对象就是那种很长的字符串以及数组。

• 长期存活的对象将进入老年区

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

• 动态对象年龄判定

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

• 空间分配担保

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