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

缺乏、安全感 2023-02-21 11:57 42阅读 0赞

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

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

## 判断对象是否存活的算法 ##

### 引用计数法 ###

引用计数法的实现很简单。给对象中添加一个引用计数器，每当有一个地方引用了他时，引用计数器的值就加1，当引用失效时候，引用计数器的值就减1。任何时刻计数器为0的对象就是不可能再被使用的。引用计数法的判定效率很高，在大部分情况下他都是一个不错的算法，但是引用计数法很难解决对象之间的循环引用的问题。

public class ReferenceCountingGC { 
        public Object instance = null;
    
        public static void testGC() { 
            ReferenceCountingGC objA = new ReferenceCountingGC();
            ReferenceCountingGC objB = new ReferenceCountingGC();
            objA.instance = objB;
            objB.instance = objA;
            objA = null;
            objB = null;
            System.gc();
        }
    }

上例中objA与objB相互引用之后objA与objB又赋值为了null。实际上这两个对象已经不可能再被访问，但是因为他们相互引用着对方导致他们的引用计数器都不为0，GC收集器不会回收他们。

### 可达性分析算法 ###

在主流的商用程序语言的主流实现中，都是通过可达性分析算法来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为GC Roots的对象作为起始点，从这些节点向下进行搜索，搜索所走过的路径就成为引用链。当一个对象到GC Roots没有任何的引用链与之相连，则证明此对象是不可用的。在下图中，对象object5、object6、object7虽然互相有关联，但是他们到GC Roots是不可达的，所以他们将会被判定为是可以回收的对象。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0ODM5MTUw_size_16_color_FFFFFF_t_70]

Java 语言中，可以做为GC Roots的对象包括下面几种：

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

## JDK1.2之后的引用 ##

无论是通过引用计数器算法、还是通过可达性分析来判断对象是否存活都与对象的引用有关。在JDK1.2之前，java中的引用的定义很传统，如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址。就称为这块内存代表着一个引用。在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用。四种引用强度以此减弱。

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

## 对象的生死 ##

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

如果这个对象被判定有必要执行finalize()方法，那么会被放在一个叫F-Queue的队列中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里的执行只是说虚拟机会触发这个方法，但是并不承诺会等它运行结束。原因是如果finalize()方法执行缓慢或者发生死循环，很有可能导致F-Queue中的其他对象处于永久等待，甚至导致整个内存回收系统崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，如果在GC对F-Queue中对象进行第二次小规模的标记之前与任何一个对象建立关系，在第二次标记是它就可以被移出即将回收集合。否则就会被回收

## 回收方法区 ##

永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。假如一个字符串“abc”进入了常量池中，但是没有任何一个String对象是叫做“abc”的，这个“abc”常量就会被清理出常量池。

判断一个类是无用类需要同时满足下面三个条件：

*  该类的所有实例都已经被回收，也就是在Java堆中不存在该类的任何实例
 *  加载该类的ClassLoader已经被回收
 *  该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问类的方法。

## 垃圾收集算法 ##

### 标记-清除法 ###

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

### 复制算法 ###

为了解决效率问题，一种称为“复制”的收集算法出现了，他将可用内存按照容量划分为大小相等的两块，每次只使用其中的一块，当这一块的内存空间使用结束就讲还活着的对象复制到另一半上，然后把已经使用过得内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也不用考虑内存碎片的复杂情况。但是这种算法的代价是将内存缩小为了原来的一半。现在商业虚拟机采用这种收集算法来回收新生代，但是并不需要按照1：1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块比较小的Survivor空间，每次使用Eden和其中的一块Survivor空间。当回收时候，将Eden和Survivor中还存活的对象一次性地复制到另一块Survivor空间上，最后清理掉Eden和刚才使用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8：1。当Survivor空间不够用时，需要其他内存（这里指老年代）进行分配担保。

### 标记-整理法 ###

复制收集算法在对象存活率较高时效率会变低，所以在老年代中提出了标记-整理算法，标记过程跟标记-清除算法一样，整理过程中让所有存活的对象都向一端移动，然后直接清理掉端边界意外的内存。

### 分代收集算法 ###

分代收集算法根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代。根据各个年代的特点选择最适当的手机算法。在新生代中，每次垃圾收集时都有大批的对象死去，所以采用复制算法，老年代中的对象因为存活率高，所以使用标记-清理或标记-整理算法来进行回收。

## 垃圾收集器 ##

### Serial收集器 ###

Serial收集器是最基本、发展历史最悠久的收集器。这个收集器是一个单线程的收集器，但是它的“单线程”的意义并不仅仅说明它只会使用一个CPU或者一条收集线程去完成垃圾回收工作，更重要的是在他进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

### ParNew收集器 ###

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则，回收策略等都与Serial收集器完全一样，在实现上这两种收集器也共用了相当多的代码。

### Parallel Scavenge收集器 ###

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

停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率的利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。由于与吞吐量关系密切，Parallel Scavenge收集器也经常被称为吞吐量优先收集器。

### Serial Old收集器 ###

Serial Old收集器是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。这个收集器的主要意义在于给Client模式下的虚拟机使用。

### Parallel Old 收集器 ###

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

### CMS收集器 ###

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。CMS收集器基于”标记-清除“算法实现，整个运作过程分为四个步骤，包括：

*  初始标记
 *  并发标记
 *  重新标记
 *  并发清除

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

CMS是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停顿。但是CMS还远远打不到完美的程度，他有以下三个明显的缺点：

*  CMS收集器对CPU的资源很敏感，在并发阶段，虽然它不会导致用户线程停顿，但是会因为占用了一部分线程而导致应用程序变慢。CMS默认启动的回收线程数是（CPU+3）/ 4，也就是当CPU在四个以上时，并发回收时收集线程不少于25％的CPU资源，并且随着CPU数量的增加而下降。但是CPU不足4个时，CMS对用户程序的影响就可能会变得很大，如果本来CPU负载就比较大，还分出一般的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然降低了50%。为了应付这种情况，虚拟机提供了一种称为”增量式并发收集器”的CMS收集器变种，所做的事情和单CPU年代PC机操作系统使用抢占式来 模拟多任务机制的思想一样，就是在并发标记、清理的时候让GC线程、用户线程交替运行，尽量减少GC线程独占资源的时间，这样整个垃圾收集的过程会更长，但是对用户程序的影响就会显得更少。
 *  CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉他们，只好留待下一次GC时再清理掉。这一部分垃圾就称为浮动垃圾。由于垃圾回收阶段，用户线程还需要执行，那也就还需要有预留有足够的内存空间给用户线程使用。因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。
 *  CMS收集器是一款基于“标记-清除”算法实现的收集器，可能在收集结束时候产生大量的空间碎片。

### G1收集器 ###

G1（Garbage-First）是一款面向服务端应用的垃圾收集器。与其他GC收集器相比，G1具备如下特点：

*  并行与并发：G1能过充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿时间，部分其他收集器原本需要停顿的Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行
 *  分代收集：与其他收集器一样，分代概念在G1中仍然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的就对象以获取更好的收集效果。
 *  空间整合：与CMS的“标记-清理”算法不同，G1从整体来看是基于“基于-整理”算法实现的收集器，从局部上来看是基于“复制”算法，G1运作期间不会产生内存空间碎片，收集后能够提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
 *  可预测的停顿：这是G1相对于CMS的另一大优势，G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而使用G1收集器时，Java堆的内存布局与其他收集器有很大区别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但是新生代和老年代不再是无力隔离的了，他们都是一部分Region(不需要连续)的集合。

G1收集器之所以能够建立可以预测的停顿时间模型，是因为它可以有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限时间内可以获得尽可能高的收集效率。

## 内存分配与回收策略 ##

### 对象优先在Eden分配 ###

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

### 大对象直接进入老年代 ###

大对象是指需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组，经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够多的连续空间来存放他们

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

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

### 动态对象年龄判定 ###

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

### 空间分配担保 ###

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0ODM5MTUw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200630154945925.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0ODM5MTUw,size_16,color_FFFFFF,t_70