【深入理解java虚拟机】-- 垃圾收集器与内存分配策略

本系列内容,大量引用自《深入理解java虚拟机》,说是照抄一遍也不为过。不过作者自己也加入了一些图文用来帮助理解。

对象是否存活

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

引用计数法

​ 给对象中添加一个引用计数器,每当有一个地方引用它时,计时器值就加1;当引用失效时,计数器值就减1;任何时刻计数器为0的对象,就是不可能再被使用的。这种方式虽然实现简单、效率也很高,但是主流的java虚拟机里面没有选用引用计数法来管理内存,其中最主要的原因是它很难解决对象之间相互循环引用的问题。例如:

1
2
3
4
5
6
7
8
9
10
11
Object q1 = new GcObject(); //实例1,引用数+1
Object q2 = new GcObject(); //实例2,引用数+1

q1.instance = q2; //将实例1中的instance熟悉指向实例2,实例2,引用数+1
q2.instance = q1; //将实例2中的instance熟悉指向实例1,实例1,引用数+1

q1 = null; //实例1,引用数-1
q2 = null; //实例2,引用数-1

//垃圾回收后,实例1,实例2还存在堆中,不会被回收
//System.gc();

​ 上面代表就描述了,引用计数器在实际使用中会出现的一个循环引用的问题。对象没有被其他地方引用,但是计数器值不为0,此时实例1、2无法被回收,也就是我们常说的内存泄漏。

​ 之前看到过一个问题,为什么jvm知道object的细节,但是在实现q1=null这条语句之前,不先将q1内部实例全部引用设置为null(也就是将q1.instance也置为null)呢?

问题是,虚拟机不能肯定q1.instance指向的也是垃圾,就不能随便修改它的内容。当遇到复杂的庞大的循环链结构时,我们又如何确定指向的对象会成为垃圾呢,就算是一个个寻找是否有其他对象引用,最终还是会存在循环引用问题。因此如果采用计数器法,那么必然要手动将instance置为null。

可达性分析算法

​ 在主流的商用程序语言的主流实现中,都是称通过可达性分析来判断对象是否存活的。这个算法的基本思路就是通过一系列的成为“GC Roots”的对象做为起始点,从这些节点开始向下搜索,搜索所走过的路径成为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链相连时,则证明此对象是不可用的。下图中,对象5、6、7虽然互相有关联,但是他们到GC Root是不可达的,所以他们江湖判定为是可回收的对象。

在java语言中,可做为GC Root的对象包括下面几种

  • 虚拟机栈(栈帧中的本地变量表)中引用的对象。
  • 元空间中类静态属性引用的对象
  • 元空间中常量引用的对象
  • 本地方法中JNI(即一般说的Native方法)引用的对象

引用

​ 无论是通过引用计数法判断对象的引用数量,还是通过可达性分析法判断对象的引用链是否可达,判断对象是否存货都与“引用“有关。JDK 1.2以前,java中的引用定义很传统:如果reference类型的数据中存储的数据代表的是另一块内存的起始地址,就成这块内存代表着一个引用。一个对象在这种定义下只有被引用或者没有被引用两种状态,对于如何描述一些”食之无味,弃之可惜“的对象就显得无能为力。

​ 因此在JDK 1.2以后,Java对引用的概念进行了扩充,将应用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)、虚引用(Phantom Reference)四种、这4中引用强度依次逐渐减弱。

  • 强引用:就是指在程序代码中普普遍存在的,类似”Object obj = new Object()“这类的引用,只要强引用还存在,垃圾收集器永远不会回收掉被引用的对象。
  • 软引用:用来描述一些还有用,但并非必需的对象。JVM在将要发生内存溢出前,会把这些对象回收。通过SoftReference类来实现软引用。
  • 弱引用:也是用来描述非必需对象的。当垃圾收集器工作时,无论当前内存是否足够,弱引用对象都会被回收。通过WeakReference类来实现弱引用时,可以指定一个ReferenceQueue,如果弱引用所引用的对象被回收,Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。
  • 虚引用:是最弱的一种引用关系。一个对象是否有虚引用的存在,完全不会对其生存时间构成影响;也无法通过虚引用来取的一个对象实例。一个对象设置虚引用关联的唯一目的就是能在这个对象被垃圾回收时收到一个系统通知。通过PhantomReference类来实现虚引用时必须指定一个ReferenceQueue队列,目标对象被回收前,它的引用会被放入该队列。目前在NIO中,就运用了虚引用管理堆外内存,通过虚引用指向堆外内存的地址,如果被回收,那么去堆外内存中查看对象是否存在,如果存在,那么将其回收。

对象死亡判定

​ 即使在可达性分析算法中不可达的对象,也并非是“非死不可的”,这个时候它们暂时处于”缓刑“阶段,要真正宣告一个对象死亡,至少要经历两次标记过程:

  1. 通过可达性分析法判断对象的引用链不可达时,进行第一次标记,并且进行一次筛选,筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize方法或者该方法被虚拟机调用过,虚拟机将这两种情况视为“没有必要去执行”。

    如果该对象被判定为有必要执行finalize()方法,那么这个对象会被放置到一个叫做F-Queue的队列中,并在稍后由一个虚拟机自动建立的、低优先级的Finalize线程去执行它。这里所谓的”执行“就是去触发该方法,但并不会承诺等待它执行结束,这样做的原因是,如果对象在finalize()方法中执行缓慢,或者发生死循环,将会导致整个队列中的对象永久处于等待,甚至导知整个内存回收系统崩溃。

  2. finalize()方法是对象逃脱死亡命运的最后一次机会,稍后GC将对F-Queue中的对象进行第二次小规模的标记,如果对象要在finalize()中拯救自己——只要重新与引用链上的一个对象重新建立关联即可,譬如将自己(this关键字)赋值给某个类变量或者成员变量,那么在第二次标记的时候就会被移除“即将回收”的集合;如果对象这时候还没有逃脱,那么就会被真的回收了。

回收方法区

​ 很多人认为方法区是没有垃圾收集的,java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集,而且在方法区中进行垃圾收集的”性价比“一般比较低;在堆中,尤其是在新生代中,常规应用进行一次垃圾收集一般可以回收70%~95%的空间,而永久代的垃圾收集效率远低于此。

​ 永久代的垃圾收集主要回收两部分内容,废弃常量和无用的类。判断一个常量是否是”废弃常量“比较简单,而要判定一个类是否是”无用的类“的条件则相对苛刻许多。类需要同时满足一下三种条件才算是“无用的类”。

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

虚拟机可以对满足上述3个条件的无用类进行回收,这里仅仅是”可以“,而不是和对象一样不使用了就必然会回收。

垃圾收集算法

标记-清除算法

​ 最基础的收集算法(Mark-Sweep),顾名思义,先标记再清除。

​ 首先标记出所有需要回收的对象,再标记完成后统一回收所有被标记的对象。之所以说是最基础的收集算法,是因为后续的收集算法都是基于这种思路改进的。

优点:简单

缺点:

  1. 效率不高,标记和清除两个过程效率都不高
  2. 标记清除后会产生大量不连续的内存碎片,空间碎片较多可能会导知以后再程序运行过程中需要分配大对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

适用于老年代,一般和标记整理算法搭配使用,老年区可能经过多次GC后,才会采用标记整理的算法压缩内存

复制算法

​ 为了解决效率问题,复制收集算法出现了,它将可用内存按照容量划分为大小相等的两块,每次只需使用其中的一块。当这一块内存用完了,就将存活着的对象复制到另外一块上面。然后把已经使用过的内存空间一次清理掉。这样使的每次都是对整个半区进行内存回收,也不用考虑内存碎片的问题。只要移动指针,按顺序分配内存即可,实现简单,运行高效,不足之处在于内存的使用率太低。

​ 现在商业虚拟机都采用这种收集算法来回收新生代,有公司研究表明,新生代中的对象98&都是”朝生夕死“,所以并不需要按照1:1的比例来划分内存空间,而是将内存分为一块较大的Eden空间和两块较小的Survivor空间,每次使用Eden和其中一块Survivor。当回收时,将Eden和Survivor中还存活的对象一次性地复制到另一块Survivor空间上,最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机中默认Eden和Survivor的大小比例是8:1,也就是每次新生代中可用内存空间为整个新生代的90%,只有10%被浪费。当然,98%的对象可回收只是一般场景下的数据,我们没法保证每次回收的都只有不多于10%的对象存货,当Survivor空间不够是,需要依赖其他内存(这里指老年代)进行分配担保(Handle Promotion)。

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

优点:简单,高效

缺点:内存使用率低

适用于新生代,针对频繁的回收,通过空间换时间方法提高回收的效率,同时保持内存的使用率在一个可接受的范围。

标记-整理算法

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

​ 根据老年的特性,有人提出来另外一种“标记-整理”算法,标记过程与“标记-清除”算法一样,但后续的步骤不是直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,然后清理掉端边界以外的内存。

优点:简单,节省空间

缺点:比标记-清除算法还多了整理这一步,而整理的效率也很低

适用于老年代,不会频繁的回收,同时具有压缩功能,节省老年代内存,减小触发Full GC收集的次数

分代收集算法

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

hptspot的算法实现

​ 前面介绍了对象存活判定算法和垃圾收集算法,而在HotSpot虚拟机上是实现这些算法时,必须对算法的执行效率有严格的考量,才能保证虚拟机高效运行。

枚举根节点

​ 前面可达性分析法中说过通过GC Roots节点找引用链,通过是否可达判断对象的存活。而GC Root节点主要在全局的引用(例如常量或类静态属性)与执行上下文(例如栈帧中的本地变量表),如何快速高效找出可作为GC Root的节点,便成为了一个问题。

​ 可达性分析必须在一个能确保一致性的快照中进行,也就是说在执行可达性分析时,不能出现分析过程中对象引用关系还在不断发生变化的情况,否则分析结果的准确性无法得到保证。这点是导致GC进行时必须停顿所有java执行线程的其中一个重要原因,即使是在号称(几乎)不会发生停顿的CMS收集器中,枚举根节点时也是必须要停顿的。

​ 由于目前主流的java虚拟机使用的都是准确性GC,所以当前执行系统停顿下来时,并不需要一个不漏地检查完所有执行上下文和全局的引用位置,虚拟机应当是有办法直接得知哪些地方存放者对象的引用,在HotSpot的实现中,是使用一组称为OopMap的数据结构来达到这个目的得,在类加载完成的时候,HotSpot就把对象内什么偏移量上是什么类型的数据计算出来,在JIT编译过程中,也会在特点的位置记录下来栈和寄存器中哪些位置是引用,这样GC在扫描时就可以直接得知这些信息了。

安全点

​ 枚举根节点通过OopMap中记录的数据,可以快速准确的完成GC Roots枚举,但是又会导致引用关系变化,或者说OopMap内容变化的指令非常多,如果每一条都生成对应的OopMap,将会需要大量的额外空间,这样GC的空间成本太高。因此在实际中,HotSpot也没有为每条指令都生成OopMap,只是在“特定的位置”记录这些信息,这些位置被称为安全点(Safepoint),即程序执行时并非在所有地方都能停顿下来开始GC,只有到达安全点时才能在暂停。

​ 安全点的选定既不能太少以至于让GC等待时间太长,也不能过于频繁以致于过分增大运行时的负荷。所以安全点的选定基本上是以程序“是否具有让程序长时间执行的特征”为标准进行选定的,因为每条指令执行的时间都非常短暂,程序不太可能因为指令流长度太长这个原因而过长时间运行,“长时间执行”的最明显的特征就是指令序列服用,例如方法调用、循环跳转、异常跳转等,所以具有这些功能的指令才会产生Safepoint。

​ 对于Safepoint,另一个需要考虑的问题就是如何在GC发生时让所有线程都“跑”到最近的安全点上再停顿下来。有两种方案可供选择:抢先式中断和主动式中断,其中抢先式中断不需要线程的执行代码主动区配合,在GC发生时,首先把所有的线程全部中断,如果发现有线程中断的地方不在安全点上,就恢复线程,就让它“跑“到安全点上。不过现在几乎没有虚拟机采用抢先式中断来暂停线程而响应GC事件。

​ 而主动中断的思想是当前GC需要中断线程的时候,不直接对线程操作,仅仅简单的设置一个标记,各个线程执行时主动去轮询这个标志,发现中断标志位真时就自己中断挂起,轮询标志的地方和安全点是重合的,另外再加上创建对象需要分配内存的地址。

安全区域

​ 前面说了通过让所有线程集中”跑“到Safepoint,来进入GC,如果此时程序处于Sleep状态或者Blocked状态,这时候线程无法响应JVM的中断请求,去安全的地方挂起,这个时候就需要安全区域来(Safe Region)解决。

​ 安全区域是指再一段代码片段中,引用关系不会发生变化。这个区域中任何地方GC都是安全的,可以把Safe Region看做是被扩展的Safepoint。

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

垃圾收集器

​ 上面展示了不同分代的收集器,如果两个收集器之间存在连线,就说明他们可以搭配使用。虚拟机所处的区域,则表示它属于新生代收集器还是老年代收集器。

Serial收集器

​ 采用复制算法的单线程收集器,进行垃圾收集器必须暂停其他所有工作线程,直到它收集结束(Stop The Word)。由于没有线程开销,可以在单CPU环境下获得最高的单线程收集效率。比较适合在运行在Client模式下的虚拟机。

ParNew收集器

​ Serial收集器的多线程版本,除了使用多条线程进行垃圾收集之外,其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、收集策略等都与Serial收集器完全一样。

除了Serial收集器外,目前只有它能和CMS收集器(Concurrent Mark Sweep)配合工作。

Parallel Scavenge收集器

​ 使用复制算法并行的多线程新生代收集器,看起来和ParNew一样。不过Parallel Scavenge收集器关注点与其他收集器不同,CMS更关注缩短用户收集时线程的停顿时间,而Parallel Scavenge目标是达到一个可控的吞吐量。

所谓吞吐量就是CPU用于运行用户代码与CPU总消耗时间的比值,即 吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间),虚拟机总共运行了100分钟,其中垃圾收集花掉1分钟,那吞吐量就是99%。

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

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

​ MaxGCPauseMills参数设置一个值,收集器尽量保证内存回收花费的时间不超过设定值。但是GC停顿时间缩短是以牺牲吞吐量为代价的,比如:停顿时间设置较少,原先收集500M,现在只收集300M,但这也导致垃圾收集更频繁,原先10秒收集一次,每次停顿100毫秒,现在变为5秒收集一次,每次停顿70毫秒,停顿时间变少了,但是吞吐量也下来了。

无法与CMS收集器配合工作

Serial Old收集器

​ Serial收集器的老年代版本,采用“标记-整理”算法,也是适用于Client模式下的虚拟机。不过同样适用于Server端,jdk1.5以及之前的版本中与Parallel Scavenge收集器搭配使用,还有就是作为CMS收集器的后备预案,在并发收集发生Concurrent Mode Failure时使用。

Parallel Old

​ 看名字就知道,是Parallel Scavenge收集器的老年代版本,使用多线程和“标记-整理”算法。是jdk1.6之后才提供的,抛弃了上面的Serial Old收集器,主要是Serial Old作为一个单线程收集器会拖后腿。无法将整体应用上获得吞吐量最大化的效果。还不如ParNew+CMS给力。

​ Parallel Scavenge+Parallel Old组合,本着“吞吐量优先”的原则,在注重吞吐量以及CPU资源敏感的场合下,都可以优先此组合。

CMS收集器

​ CMS(Concurrent Mark Sweep)收集器关注于获取最短回收停顿时间为目标的收集器,基于“标记-清除”算法实现,它的运作过程比前几款收集器更复杂,整个过程分为4个步骤

  • 初始标记(CMS initial mark): 标记GC Roots能直接关联的对象,速度很快,标记时需要Stop The World。
  • 并发标记(CMS concurrent mark): 进行GC Roots Tracing的过程。耗时长,但是可以与用户线程一起工作。
  • 重新标记:修正并发标记期间因用户程序继续运作而导知标记产生变动的那一部分对象的标记记录,也会Stop The World,并且停顿时间一般会比初始标记阶段稍长一些,但比并发标记时间短。
  • 并发清楚:清除标记的垃圾,耗时长,可以与用户线程一起工作。

CMS的缺点:

  1. CMS收集器对CPU资源非常敏感。在并发阶段,会因为占用一部分线程而导致应用程序变慢,总吞吐量会降低。
  2. 无法处理浮动垃圾,可能出现“Concurrent Mode Failure”失败而导知另一次Full Gc的产生。由于在垃圾收集阶段用户线程还需要运行,那也就需要预留足够的内存空间给用户线程使用,因此CMS不能等到老年代满了才收集,需要预留一部分空间提供并发收集时的程序运作使用。JDK 1.6中,CMS收集器启动阈值为92%(可以通过-XX:CMSInitiatingOccupancyFraction来设置),要是预留的内存无法满足需要,就会出现一次“Concurrent Mode Failure”失败,这时虚拟机启动后备预案:临时启动Serial Old收集器来重新进行老年代的垃圾收集,这样停顿就很高了。所以说-XX:CMSInitiatingOccupancyFraction设置的太高,容易导知大量“Concurrent Mode Failure”失败,性能反而降低。
  3. CMS基于‘“标记-清除”算法实现,收集结束时会有大量空间碎片。因此CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数(默认开启),用于在CMS收集器顶不住要进行Full GC时开启内存碎片的合并整理过程,但是副作用就是停顿时间会变长。虚拟机设计者还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction,用来设置执行了多少次不压缩的Full GC后,跟着来一次带压缩的(默认为0,标识每次Full GC时都要进行碎片整理)。

G1收集器

​ G1收集器中还保留着新生代,老年代的概念,但是它们不再是物理隔离的了。在G1中,内存空间被分割成一个个的Region区,所谓新生代和老年代,都是由一个个Region组成的。同时G1也不需要跟别的收集器一起配合使用,自己就可以完成所有的收集工作,一款全能收集器。

​ 与CMS的“标记-清除”算法不同,G1从整体上看时基于“标记-整理”算法实现的收集器,从局部(两个Region之间)上来看是基于“复制”算法实现的,无论如何,这两种算法都意味着G1运行期间不会产生内存空间碎片。

​ 在G1收集器中,Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用,虚拟机都是使用Remembered Set来避免全堆扫描的。G1中每一个Region都有一个与之对应的Remembered Set,虚拟机发现程序在对Reference类型的数据进行写操作时,会产生一个Write Barrier展示中断写操作,检查Reference引用的对象是否处以不同的Region之中(在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象),如果是,便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中,当进行内存回收时,在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

​ 如果不计算维护Remembered Set的操作,G1收集器的运作大致可划分为一下几个步骤:

  • 初始标记:跟CMS收集器一样,标记GC Roots能直接关联的对象
  • 并发标记:从GC Root开始对堆中对象进行可达性分析,找出存活对象,这步耗时久,但是可以与用户程序并发执行。
  • 最终标记:由于并发标记阶段,用户线程仍然在运行,会对标记产生一些偏差,通过Remembered Set Log记录这些变化,此阶段会将这些变化合并到remembered set中,需要停顿线程,但是可以并行执行。
  • 最终筛选:对各个Region回收价值和成本排序,根据用户期望的GC停顿时间来制定回收计划。

内存分配与回收策略

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

对象优先在eden分配

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

大对象直接进入老年代

​ 所谓大对象是指,需要大量连续内存空间的对象,最典型的就是很长的字符串以及数组。虚拟机提供了一个-XX:PretenureSizeThreshold参数,令大于这个设置值的对象直接在老年代中分配,避免在Eden和两个Survivor区之间发生大量的内存复制。

长期存活对象进入老年代

​ 虚拟机给每个对象定义了一个对象年龄计数器。Eden中的对象经历过第一次Minor GC后仍然存活,并且能被Survivor容纳的话,将被移动到Survivor空间中,并且对象年龄设置为1。每经历一次Minor GC,年龄数+1,年龄增加到一定程度(CMS默认6,其他默认15,可以通过-XX:MaxTenuringThreshold参数设置),就会晋升到老年代中。

动态对象年龄判定

​ 虚拟机并不是永远要求对象年龄必须达到MaxTenuringThreshold设置的值才能晋升到老年代,如果Survivor中相同年龄所有对象大小的总和大于Survivor空间的一般,年龄大于或者等于该年龄的对象就可以直接进入老年代。

空间分配担保

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

​ JDK 1.6以后,规则变为只要老年代的连续空间大于新生代对象总大小或历次晋升的平均大小就行进行Minor GC,否则进行Full GC。

总结

垃圾收集器与内存分配策略到这里就结束了。后面会将JVM中所有的参数专门整合为一章,方便查找。:small_airplane:

#

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×