Java之虚拟机垃圾收集器

本文阅读 53 分钟
首页 代码,Java 正文

我们知道经过半个多世纪的发展,今天的内存动态分配和内存回收技术已经相当的成熟,一切看起来都进入了“自动化”时代,那我们为什么还要了解垃圾收集和内存分配呢?这是因为当需要排查各种内存溢出、内存泄漏问题时,当垃圾收集成为系统达到更高并发量的瓶颈时,我们就必须对这些“自动化”的技术实施必要的监控和调节。

《Java之虚拟机》这篇文章中我们了解到Java内存运行时区域包含了多个部分,其中程序计数器、虚拟机栈、本地方法栈3个区域随线程而生,随线程而灭,栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上在类结构确定下来时就已知了,因此这几个区域的内存分配和回收都具备确定性,在这几个区域就不需要过多考虑如何回收的问题,当方法结束或者线程结束时,内存自然就跟随着回收了。

而Java堆和方法区这两个区域这有着很显著的不确定性:一个接口的多个实现类需要的内存可能会不一样,一个方法所执行的不同条件分支所需要的内存也可能不一样,只有处于运行期间,我们才能知道程序究竟会创建那些对象,创建多少对象,这部分内存的分配和回收是动态的。垃圾收集器所关注的正是这部分内存该如何管理。

特别要注意方法区的回收,Java虚拟机规范中确实说过可以不要求虚拟机的方法区进行垃圾回收,但并不是说方法区不能回收,方法区的回收主要包含两部分内容:废弃的常量无用的类。回收废弃的常量与回收Java堆中的对象非常的类似。以常量池中的字面量回收为例,假如一个字符串“abc”已经进入了常量池中,但是当前系统没有任何一个String对象是叫做“abc”的,换句话说。就是没有任何String对象引用常量池中的“abc”常量,也没有其他地方引用了这个字面量,如果这个时候发生内存回收,并且必要的话,这个“abc”常量就会被系统清理出常量池。常量池中的其他类(接口)、方法、字段的符号引用也与此类似。

而无用类的判断条件就要苛刻的多需要同时满足以下三个条件才可以

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

虚拟机可以对满足上述三个条件的无用类进行回收,这里说的仅仅是可以,而并不是和对象一样,不适用了就必然会回收。是否对类进行回收,HotSpot虚拟机提供了-Xnoclassgc参数进行控制,当然还有其他一些参数可对类的加载和卸载进行控制。

上面我们分析了垃圾回收器所要回收的内存区域,但是这些内存区域中哪些数据是可以回收的呢?当然是被jvm当作垃圾的数据也就是没有被用到的数据。那如何判断一个数据是不是“垃圾”呢?一般有两种判断对象是否存活的算法:引用计数算法可达性分析

引用计数算法

所谓引用计数法就是给对象中添加一个引用计数器,每当一个地方引用它时,计数器的值就+1,引用失效时,计数器的值就减1;任何时刻计数器为0的对象就是没有被引用的对象就是可以被回收的

客观的说,引用计数算法的实现简单,判定效率也很高,在大部分情况下都是一个不错的算法,很多著名的公司一些技术使用就是引用技术法。但是,在主流java虚拟机里面并没有选用引用计数器算法来管理内存,其中一个重要原因就是很难解决对象之间的相互循环引用的问题

可达性分析算法

这个算法的基本思想是通过一系列的称为“GC Roots”的根对象作为起始节点集,从这些节点开始根据引用关系向下搜索,搜索过程所走的路径称为“引用链”,当一个对象到GC Roots没有任何引用链,或者用图论的话说就是从GC Roots到这个对象不可达时,则证明此对象是不可能再被使用的

在java语言中,可作为GC Roots的对象包括一下几种

  • Java虚拟机栈(栈帧中的本地变量表)中引用对象,譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量。
  • 方法区中类静态属性引用的对象,譬如Java类的引用类型静态变量。
  • 方法区中常量引用的对象,譬如字符串常量池里的引用。
  • 本地方法栈中JNI(即一般说的native方法)引用的对象。
  • Java虚拟机内部的引用,如基本数据类型对应的Class对象,一些常驻的异常对象等,还有系统类加载器。
  • 所有被同步锁(synchronized关键字)持有的对象。
  • 反应Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。 除了这些固定的GC Root集合以外,根据用户所选用的垃圾收集器以及当前回收的内存区域不同,还可以有其他对象“临时性”地加入,共同构成完整的GC Roots集合。

一个对象在通过可达性分析后确认没有引用链的情况下就一定会被回收吗? 答案是否定的。即使在可达性分析算法中判定为不可达的对象,也不是“非死不可”的,这时候它们暂时处于“待斩”阶段,还有希望自救成功,因为确认一个对象真的死亡需要进行两次标记:一个对象在进行可达性分析后发现没有和GC Roots相连接的引用链,那它将会被第一次标记,随后进行一次筛选,筛选的条件是此对象是否有必要执行finalize()方法。假设当对象没有覆盖finalize()方法,或者finalize()方法已经被虚拟机调用过,虚拟机将这两种情况都视为“没有必要执行”。

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

引用分类

JDK1.2之前,Java中引用的定义很传统:如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址,就称该reference数据是代表某块内存、某个对象的引用。这种定义并没有什么不对,只是现在看来有些狭隘,一个对象在这种定义下只有“被引用”或者“未被引用”两种状态,无法覆盖这类对象:当内存空间还足够时,则保留在内存中,如果内存空间在进行垃圾收集后还是很紧张,则进行回收----很多系统的缓存功能都符合这样的应用场景。在JDK1.2之后,有了后面对引用概念的扩充,将引用分为:强引用,软引用,弱引用,虚引用四种。

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

垃圾收集算法的实现涉及大量的程序细节,且各个平台的虚拟机操作内存的方法都有差异,这里我们只介绍分代收集理论和几种算法的思想。

分代收集理论

当代商业虚拟机的垃圾收集,大多数都遵循了“分代收集“的理论进行设计,分代收集名为理论,实质是一套符合大多数程序运行实际情况的经验法则,它建立在两个分代假说之上:

  • 弱分代假说:绝大多数对象都是朝生夕灭的。
  • 强分代假说:熬过越多次垃圾收集过程对象就越难消亡。

这两个分代假说共同奠定了多款常用的垃圾收集器的一致的设计原则:收集器应该将Java堆划分出不同的区域,然后将回收对象依据其年龄(年龄即对象熬过垃圾收集过程的次数)分配到不同的区域之中存储。显而易见,如果一个区域中大多数对象都是朝生夕灭,难以熬过垃圾收集过程话,那么把他们集中放到一起,每次回收时只关注如何保留少量存活而不是去标记那些大量将要被回收的对象,就能以较低代价回收到大量的空间;如果剩下的都是难以消亡的对象,那把他们集中到一起,虚拟机便可以使用较低的频率来回收这个区域,这就同时兼顾了垃圾收集的时间开销和内存的空间有效利用。

在Java堆中划分出不同的区域之后,垃圾收集器才可以每次只回收其中某一个或者某些部分的区域----因而才有了“MinorGC“、“Major GC”,“Full GC”这样的回收类型的划分;也才能够针对不同的区域安排与里面存储对象存亡特征相匹配的垃圾收集算法。

把分代手机理论具体到现在的商用Java虚拟机里,设计者一般至少会把Java堆划分为新生代老年代两个区域。顾名思义,在新生代中,每次垃圾收集时都发现有大批对象死去,而每次回收后存活的少量对象,将会逐步晋升到老年代中存放。事实上,分代手机并非只是简单划分一下内存区域那么容易,它至少存在一个明显的困难:对象不是孤立的,对象之间会存在跨代引用

假如现在要进行一次只局限于新生代区域内的收集,但是新生代中的对象是完全有可能被老年代所引用的,为了找到该区域中的存活对象,不得不在固定的GC Roots之外,再额外遍历整个老年代中所有对象来确保可达性分析结果的正确性,反过来也是一样。遍历整个老年代所有对象的方案虽然理论上可行,但无疑会为内存回收带来很大的性能负担。为了解决这个问题,就需要对分代收集器理论添加第三条经验法则:

  • 跨代引用假说:跨代引用相对于同代引用来说仅占极少数。 这其实是可根据前两条假说逻辑推理得出的隐含推论:存在相互引用关系对象,是应该倾向于同时生存或者同时灭亡的。举例,如果某个新生代对象存在跨代引用,由于老年代对象难以消灭,该引用会使得新生代对象在收集时同样得以存活,进而在年龄增长之后晋升到老年代中,这时跨代引用也随机被消除了。 依据这条假说,我们就不应再为了少量的跨代引用去扫描整个老年代,也不必浪费空间专门记录每一个对象是否存在及存在哪些跨代引用,只需要在新生代上建立一个全局的数据结构(称为“记忆集”),这个结构把老年代划分成若干小块,标识出老年代的哪一块内存会存在跨代引用。此后当发生Minor GC时,只有包含了跨代引用的小块内存里的对象才会被加入到GC Roots进行扫描。虽然这种方法需要在对象改变引用关系(如将自己或者某个属性赋值)时维护记录数据的正确性,会增加一些运行时的开销,但比起收集时扫描整个老年代来说仍然是划算的。

我们再强调一下分代收集的分类

  • 新生代收集(Minor GC/Young GC):指目标只是新生代的垃圾收集。
  • 老年代收集(Major GC/Old GC):指目标只是老年代的垃圾收集。目前只要CMS收集器会有单独收集老年代的行为。
  • 混合收集:指目标是收集整个新生代以及部分老年代的垃圾收集。目前只有G1收集器会有这种行为。
  • 整堆收集(Full GC):收集整个Java堆和方法区的垃圾收集。

我们可以根据各个年代的特点选择最适合的收集算法。在新生代,每次垃圾收集时都发现有大批对象死去,只有少量存活,那就用复制算法,只需要付出少量存活对象的复制成本就可以完成收集。而老年代中,因为对象存活率高、没有额外的内存对它进行担保,就必须使用“标记-清理”或者“标记-整理”算法进行回收。

标记-清除算法

标记清除算法顾名思义包含两个阶段:标记和清除。首先标记出所有需要回收的对象,在标记完成后统一回收所有被标记的对象。标记过程就是对象是否属于垃圾的判定过程,这在上面讲垃圾对象标记判定算法时已经介绍过了。

标记清除算法是最基础的算法,其他的算法都是在此基础上对其不足进行改进而得到的。 缺点

  • 效率问题,如果Java堆中包含大量对象,而且其中大部分是需要被回收的,这时必须进行大量标记和清除动作,导致标记和清除两个过程的执行效率都随对象增长而降低。
  • 内存空间的碎片化问题,标记、清除之后会产生大量部连续的内存碎片,空间碎片太多可能会导致以后再程序运行过程中需要分配比较大对象时,无法找到足够的连续的内存而不得不提前触发另一次垃圾收集动作。

标记-复制算法

标记-复制算法常备简称为复制算法为了解决标记-清除算法面对大量可回收对象时执行效率低的问题。最初的标记-复制算法被称为“半区复制”:它将可用内存按容量分为大小相等的两块,每次只使用其中的一块。当这一块内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用过的内存空间一次清理掉。如果内存中多数对象都是存活的,这种算法将会产生大量的内存复制的开销,但对于多数对象都是可回收耳朵情况,算法需要复制的就是占少数的存活对象,而且每次都是针对整个半区进行内存回收,分配内存时也就不用考虑有空间碎片的复杂情况,只要移动堆顶指针,按顺序分配即可。这样实现简单,运行高效,不过其缺陷也显而易见,这种复制回收算法的代价是可用内存缩小为了原来的一半,空间浪费太多了。

后来,有人针对具备“朝生夕灭”特点的对象,提出了一种更优化的半区复制分代策略,称为“Appel式回收”。HotSpot虚拟机的Serial、Parnew等新生代收集器均采用了这种策略。Appel式回收的具体做法是把新生代分为一块较大的Eden空间和两块较小的Survivor空间,每次分配内存只使用Eden和其中一块Survivor。发生垃圾收集时,将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor空间上,然后直接清理掉Eden和已用过的那快Survivor空间。HotSpot虚拟机默认Eden和一块Survivor的大小比例是8:1,也即每次新生代中可用内存空间为整个新生代容量的90%,只有一个Survivor空间,即10%的新生代空间会被“浪费”的。但是,任何人都没法保证每次回收都只有不多于10%的对象存活,因此Appel式回收还有一个充当罕见情况的“逃生门”的安全设计----内存分配担保机制,即当Survivor空间不足以容纳一次Minor Gc之后存活的对象时,就需要依赖其他内存区域(实际上大多就是老年代),这对虚拟机来说是安全的,关于内存分配担保机制我们后面还会详细说。

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

标记-整理算法

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

标记-清除算法与标记整理算法的本质差异在于前者是一种非移动式的回收算法,而后者是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策:

如果移动存活对象,尤其是在老年代这种每次回收都有大量对象存活区域,移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作,而且这种对象移动操作必须全程暂停用户应用程序才能进行,这就更加让使用者不得不小心翼翼地权衡其弊端了,像这样的停顿被最初的虚拟机设计者形象的称为“Stop The World”。

但如果跟标记-清理算法那样完全不考虑移动和整理存活对象的话,弥散于堆中的存活对象导致的空间碎片化问题就只能依赖更为复杂的内存分配器和内存访问器来解决。内存的访问是用户程序最频繁的操作,甚至都没有之一,假如在这个环节上增加了额外的负担,势必会直接影响应用程序的吞吐量。

基于以上两点,是否移动对象都存在弊端,移动则内存回收时更复杂,不移动则内存分配时更复杂。从垃圾收集的停顿时间来看,不移动对象停顿时间会更短,甚至可以不需要停顿,但是从整个程序的吞吐量来看,移动对象会更划算。

还有一种折中的解决方案可以不在内存分配和访问上增加太大额外负担,做法是让虚拟机平时多数时间都采用标记-清理算法,暂时容忍内存碎片的存在,直到内存空间的碎片化程度已经大到影响对象分配时,在采用标记-整理算法收集一次,以获得规整的内存空间。基于标记-清理算法的CMS收集器面临空间碎片过多时采用的就是这种处理方法

安全点和安全区域

这里讨论的收集器仅仅是JDK1.7之后HotSpot虚拟机所提供的,不同的虚拟机所使用的收集器是不同的,因为java虚拟机规范中对垃圾收集器该如何实现并没有任何规定。如下图:

如果两种收集器之间有连接线,说明他们可以配合使用。需要说明的是之所以会有这么多的收集器就是因为没有一个是万能的、放之四海而皆准、任何场景下都适用的完美收集器存在,换句话说就是这些收集器没有最好,只有最适合不同的场景。

Serial收集器:新生代收集器

Serial收集器是最基础的、历史发展最悠久的收集器,在Jdk1.3之前它是虚拟机新生代收集的唯一选择。Serial收集器是一个单线程的收集器,但它的“单线程”的意义并不仅仅说明它只会使用一个处理器或者一条收集线程区完成垃圾收集工作,更重要的是在它进行垃圾收集时,必须暂停其他所有的工作线程,直到它收集结束。这一点对很多应用来说是不能接受的。

Serial收集器是使用标记-复制算法的收集器。

事实上,迄今为止,它依然是HotSpot虚拟机运行在客户端模式下的默认新生代收集器,有着优于其他收集器的地方,那就是简单高效(与其他收集器的单线程相比),对于内存资源受限的环境,它是所有收集器里额外内存消耗最小的;对于单核处理器或处理器核心数较少的环境来说,Serial收集器由于没有线程交互的开销,专心做垃圾收集自然可以获得更高的单线程收集效率。在用户桌面的应用场景以及近年来流行的部分微服务应用中,分配给虚拟机管理的内存一般来说并不会特别大,收集几十兆甚至一两百兆的新生代,垃圾收集的停顿时间完全可以控制在十几、几十毫秒,最多一百多毫秒以内,只要不是频繁发生收集,这点停顿时间对许多用户来说是完全可以接受的,所以Serial收集器对于运行在客户端模式下的虚拟机来说是一个很好的选择。

ParNew收集器 :新生代收集器

ParNew收集器其实是Serial收集器的多线程版本,其他与Serial收集器相比并没有太多创新之处,很多配置参数和Serial是公用的,Serial的收集算法、stop the world、对象分配规则、回收策略等都是一样的。但是即便如此,它确实许多运行在Server模式下的虚拟机中首选的新生代收集器,其中最主要的原因是除了Serial收集器外,目前只有它能与CMS收集器配合工作

ParNew收集器是使用标记-复制算法的收集器。

ParNew收集器也是使用-XX:+UseConcMarkSweepGC选项后得默认新生代收集器,也可以使用-XX:+UseParNewGC选项来强制指定它。同时可以使用-XX:ParallelGCThreads参数来限制垃圾收集得线程数,如果不适用此参数,默认开启得线程数和cpu数量相同。

Parallel Scavenge收集器:新生代收集器

Parallel Scavenge收集器是新生代收集器,他也是用复制算法得收集器,又是并行得多线程收集器。

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

Parallel Scavenge收集器提供两个参数用于精确控制吞吐量,分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。同时还提供过一个参数-XX:+UseAdaptiveSizePolicy需要特别注意,这是一个开关参数,打开后,就不需要手动指定新生代大小(-Xmn),Eden与Survivor区的比例(-XX:SurvivorRatio)。晋升老年代对象大小(-XX:PretenureSizeThreshold)等细节参数了,虚拟机会根据当前系统的运行情况收集性能监控信息,动态的设置这些参数以适应最适合的停顿时间或最大吞吐量,这种调整方式称为GC自适应调整策略。

Serial Old收集器:老年代收集器

Serial Old收集器是Serial的老年代版本,它同样是一个单线程收集器,使用标记-整理算法。

Parallel Old收集器:老年代收集器

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

CMS收集器:老年代收集器

CMS收集器是一种以获取最短回收停顿时间为目标的并发收集器。它是基于“标记-清除”算法实现的。

运作过程分为四个步骤

  1. 初始标记:仅仅是标记一下GC Roots能直接关联到的对象,速度很快。此过程需要Stop The World。
  2. 并发标记:并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程,这个过程耗时较长但是不需要停顿用户线程,可以与垃圾收集线程一起并发运行。
  3. 重新标记:则是为了修正并发标记期间因用户线程继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间一般会比初始标记阶段稍长一些,但是远比并发标记的时间短。此过程需要Stop The World。
  4. 并发清除:清理删除掉标记阶段判断的已经死亡的对象,由于不需要移动存活对象,所以这个阶段也是可以与用户线程同时并发的。

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

缺点:

  • CMS收集器对Cpu资源非常敏感。 事实上,面向并发设计的程序都对处理器资源比较敏感。在并发阶段,它虽然不会导致用户线程停顿,但却会因为占用了一部分线程而导致应用程序变慢,降低总吞吐量。CMS默认启动的回收线程数是(处理器核心数量+3)/4,这就是说当处理器核心数不足4个时,CMS对用户程序的影响就会变的很大。
  • Cms收集器无法处理浮动垃圾,可能出现“soncurrent Mode Failure”失败而导致另外一次完全“Stop The World”的FullGC的产生。 在CMS的并发标记和并发清理阶段,用户线程是还在继续运行的,程序在运行自然就还会伴随有信的垃圾对象不断产生,但这一部分垃圾对象是出现在标记过程结束以后,CMS无法在当次收集中处理掉它们,只好留待下一次垃圾收集时再清理掉。这一部分垃圾就称为“浮动垃圾”。同样也是由于垃圾收集阶段用户线程还需要持续运行,那就还需要预留足够内存空间提供给用户线程使用,因此CMS收集器不能像其他收集器那样等待到老年代几乎完全被填满了再进行收集,必须预留一部分空间供并发收集时的程序运作使用。使用-XX:CMSInitiatingOccu-pancyFraction的参数来设置CMS触发的百分比,JDK6时,CMS收集器的启动阈值就已经默认提升至92%。但这又会更容易面临另一种风险:要是CMS运行期间预留的内存无法满足程序分配程序分配新对象的需要,就会出现一次“并发失败”,这时候虚拟机将不得不启动后备预案:冻结用户线程的执行,临时启用Serial Old收集器来重新进行老年代的垃圾收集,但这样停顿时间就很长了。所以-XX:CMSInitiatingOccu-pancyFraction设置得太高将会很容易导致大量的并发失败产生,性能反而会降低,用户应在生产环境中根据实际应用情况来权衡设置。
  • 由于Cms使用“标记-清除”算法,所以会产生大量的空间碎片。 CMS是一款基于“标记-清除”算法实现的收集器,这就意味着收集结束时会有大量空间碎片产生。空间碎片过多时,将会给大对象分配带来很大的麻烦,往往会出现老年代还有很多剩余空间,但就是无法找到足够大的连续空间来分配当前对象,而不得不提前触发一次Full GC的情况。为了解决这个问题,CMS收集器提供了一个-XX:+UseCMS-CompactAtFullCollection开关参数(默认开启,Jdk9开始舍弃),用于在CMS收集器不得不进行Full GC时开启内存碎片的合并整理过程,由于这个内存整理必须移动存活对象,是无法并发的。这样空间碎片问题是解决了,但停顿时间又会变长,因此虚拟机设计者们又提供了另一个参数-XX:CMSFullGCsBefore-Compaction(Jdk9开始废弃),这个参数的作用是要求CMS收集器在执行过若干次(数值由参数值决定)不整理空间的Full GC之后,下一次进入Full GC前会先进行碎片整理(默认为0,表示每次进入Full GC时都进行碎片整理)。

G1收集器:两代都可以使用

Garbage First(简称G1)收集器湿垃圾收集器技术发展历史上的里程碑式的成果,它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。 G1是一款主要面向服务端应用的垃圾收集器。JDK9发布之日,G1成为服务端模式下的默认的垃圾收集器,而CMS则沦落至被声明为不推荐使用的收集器。

G1可以面向堆内存任何部分来组成回收集进行回收,衡量标准不再是它属于哪个分代,而是哪块内存垃圾数量最多,回收收益最大,这就是G1收集器的Mixed GC模式。

G1开创的基于Region的堆内存布局是它能够实现这个目标的关键。虽然G1也仍是遵循分代收集理论设计的,但其堆内存的布局与其他收集器有这非常明显的差异:G1不在坚持固定大小以及固定数量的分代区域划分,而是把连续的Java堆划分为大小相等的独立区域(Region),每一个Region都可以根据需要,扮演新生代的Eden空间、Survivor空间,或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理。

Region中还有一类特殊的Humongous区域,专门用来存储大对象。G1认为只要大小超过了一个Region容量一半的独享即可判定为大对象。每个Region的大小可以通过参数-XX:G1HeapRegionSize设定,取值范围为1MB~32MB,且应为2的N次幂。而对于那些超过了整个Region容量的超级大对象,将会被存放在N个连续的Humongous Region之中,G1的大多数行为都把Humongous Region作为老年代的一部分来进行看待。

虽然G1仍然保留新生代和老年代的概念,但新生代和老年代不再是固定的了,他们都是一系列区域(不需要连续)的动态集合。G1收集器之所以能建立可预测的停顿时间模型,是因为它将Region作为单词回收的最小单元,即每次收集到的内存空间都是Region大小的整数倍,这样可以有计划地避免在整个Java堆中进行全区域的垃圾收集。再具体点就是让G1收集器去跟踪各个Region里面的垃圾堆积的价值大小,价值即回收所获得的空间大小以及回收所需时间的经验值,然后在后台维护一个优先级列表,每次根据用户设定允许的收集停顿时间(-XX:MaxGCPauseMillis指定,默认是200毫秒),优先处理回收价值收益最大的那些Region,这也就是“Garbage First”名字的来由。这种使用Region划分内存空间,以及具有优先级的区域回收方式,保证了G1收集器在有限的时间内获取尽可能高的收集效率。

G1收集器的运作过程大致可划分为以下四个步骤:

  • 初始标记:仅仅是标记以下GC Roots能直接关联到的对象,并且修改TAMS指针的值,让下一阶段用户线程并发运行时,能正确的在可用的Region中分配新对象。这个阶段需要挺短用户线程,但是耗时很短。
  • 并发标记:从GC Root开始对堆中对象进行可达性分析,递归扫描整个堆里的对象图,找出要回收的对象,这阶段耗时较长,但可以与用户程序并发执行。当对象图扫描完成以后,还要重新处理SATB记录下的在并发时有引用变动的对象。
  • 最终标记:对用户线程做短暂的停顿,用于处理并发阶段结束后仍遗留下来的最后那少量的SATB记录。
  • 筛选回收:负责更新Region的统计数据,对各个Region的回收价值和成本进行排序,根据用户所期望的停顿时间来制定回收计划,可以自由选择任意多个Region构成回收集,然后把决定回收的那一部分Region的存活对象复制到空的Region中,再清理掉整个就Region的全部空间。这里的操作设计存活对象的移动,是必须暂停用户线程,由多条收集器线程并行完成的

内存分配与回收策略

首先我们要清楚,内存分配规则并不是百分之百固定的,其细节取决于当前使用的是哪种垃圾收集器组合,还有虚拟机中与内存相关的参数的设置。下面我们说一下几种最普遍的内存分配规则:

  • 对象优先在Eden分配 大多数情况下,对象在新生代Eden区中分配。当Eden区没有足够内存进行分配时,虚拟机将发起一次MinorGC。MinorGC后如果发现Eden中存活的对象不超过了Survivor的大小,则移动到Survivor,如果超过了Survivor的大小,则这部分对象就直接放到老年代
  • 大对象直接进入老年代:最典型的大对象就是那种很长的字符串,或者元素数量和庞大的数组。比遇到大对象更加坏的情况就是遇到一群“朝生夕灭”的短命大对象,写程序时一定要注意避免。在Java虚拟机中要避免大对象的原因是,在分配空间时,它容易导致内存明明还有不少空间时就提前触发垃圾收集,以获取足够的连续的空间,而当复制对象时,大对象就意味着高额的内存复制开销。HotSpot虚拟机提供了-XX:PreTenureSizeThreashold参数,指定大于该设置值的对象直接在老年代分配,这样做的目的就是避免在Eden区及两人Survivor区之间来回复制操作。
  • 长期存活的对象直接进入老年代:虚拟机会给每个对象定义一个对象年龄计数器,存储在对象头中。对象通常在Eden区中诞生,如果经过第一次Minor GC后仍然存活,并且能够被Survivor容纳的话,该对象会被移动到Survivor空间中,并且将其对象年龄设为1岁。对象在Survivor去中每熬过一次Minor GC,年龄就增加1岁,当年龄增加到一定程度(默认为15),就会被晋升到老年代中。
  • 动态对象年龄判定:为了更好地适应不同程序的内存状况,HotSpot虚拟机并不是永远要求对象的年龄必须达到-XX:MaxTenuringThreshold才能晋升老年代,如果在Survivor空间中低于或等于某年龄的所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代,无须等到-XX:MaxTenuringThreshold中要求的年龄。
  • 空间分配担保:在发生Minor GC之前,虚拟机必须先检查老年代最大可用的连续空间是否大于新生代所有对象总空间,如果这个条件成立,那这一次Minor GC可以确保是安全的,如果不成立,则虚拟机会先查看-XX:HandlePromotionFailure参数的设置值是否允许担保失败;如果允许,那会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小,如果大于,将尝试进行一次Minor GC,尽管这次Minor GC是有风险的;如果小于,或者XX:HandlePromotionFailure设置不允许冒险,那这时就要改为进行一次Full GC。 我们知道只使用一个Survivor空间作为轮换备份,因此当出现大量对象在Minor GC后仍然存活的情况----最极端的情况就是内存回收后新生代中所有对象都存活,需要老年代进行分配担保,把Survivor无法容纳的对象直接送入老年代。前提是老年代本身还有容纳这些对象的剩余空间,但一共有多少对象会在这次回收中活下来在实际完成内存回收之前是无法确定的,所以只能取之前每一次回收晋升到老年代对象容量的平均大小作为经验值,与老年代的剩余空间进行比较,决定是否进行Full GC来让老年代腾出更多空间。

暂略

本文为互联网自动采集或经作者授权后发布,本文观点不代表立场,若侵权下架请联系我们删帖处理!文章出自:https://blog.csdn.net/qq_38571892/article/details/123052540
-- 展开阅读全文 --
Web安全—逻辑越权漏洞(BAC)
« 上一篇 03-13
Redis底层数据结构--简单动态字符串
下一篇 » 04-10

发表评论

成为第一个评论的人

热门文章

标签TAG

最近回复