• JVM:垃圾收集器与内存分配策略(2)


    1. 垃圾收集器

    我们先来明确一个观点:虽然我们是在对各个收集器进行比较,但并非为了挑选一个最好的收集器出来。因为直到现在为止还没有最好的收集器出现,更加没有万能的收集器,所以我们选择的只是对具体应用最合适的收集器

    1. Serial 收集器
    2. ParNew 收集器
    3. Parallel Scavenge 收集器
    4. Serail Old 收集器
    5. Parallel Old 收集器
    6. CMS 收集器
    7. G1 收集器

    垃圾收集器的常用相关参数:

    1. UseSerialGC:虚拟机运行在Client模式下的默认值,打开此开关后,使用Serial+Serial Old的收集器组合进行内存回收
    2. UseParNewGC:打开此开关后,使用ParNew+Serial Old的收集器组合进行内存回收
    3. UseConcMarkSweepGC:打开此开关后,使用ParNew+CMS+Serial Old的收集器组合进行内存回收。Serial Old收集器将作为CMS收集器出现Concurrent Mode Failure失败后的后备收集器使用
    4. UseParallelGC:虚拟机运行在Server模式下的默认值,打开此开关后,使用ParallelScavenge+Serial Old(PS MarkSweep)的收集器组合进行内存回收
    5. UseParallelOldGC:打开此开关后,使用·Parallel Scavenge+Parallel Old·的收集器组合进行内存回收
    6. SurvivorRatio:新生代中Eden区域与Survivor区域的容量比值,默认为8,代表Eden:Survivor=8:1
    7. PretenureSizeThreshold:直接晋升到老年代的对象大小,设置这个参数后,大于这个参数的对象
      将直接在老年代分配
    8. MaxTenuringThreshold:晋升到老年代的对象年龄。每个对象在坚持过一次Minor GC之后,年龄就加1,当超过这个参数值时就进入老年代
    9. UseAdaptiveSizePolicy:动态调整Java堆中各个区域的大小以及进入老年代的年龄
    10. HandlePromotionFailure:是否允许分配担保失败,即老年代的剩余空间不足以应付新生代的整个Eden和Survivor区的所有对象都存活的极端情况
    11. ParallelGCThreads:设置并行GC时进行内存回收的线程数
    12. GCTimeRatio:GC时间占总时间的比率,默认值为99,即允许1%的GC时间。仅在使用Parallel Scavenge收集器时生效
    13. MaxGCPauseMillis:设置GC的最大停顿时间。仅在使用Parallel Scavenge收集器时生效
    14. CMSInitiatingOccupancyFraction:设置CMS收集器在老年代空间被使用多少后触发垃圾收集。默认值为
      68%,仅在使用CMS收集器时生效
    15. UseCMSCompactAtFullCollection:设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片整理。仅
      在使用CMS收集器时生效
    16. CMSFullGCsBeforeCompaction:设置CMS收集器在进行若干次垃圾收集后再启动一次内存碎片整理。仅在使用CMS收集器时生效

    2. 内存分配与回收策略

    对象的内存分配,往大方向上讲,就是在堆上分配,对象主要分配在新生代的Eden区上,如果启动了本地线程分配缓冲,将按线程优先在TLAB上分配。少数情况下也可能直接分配在老年代中,规则不定,取决于垃圾收集器组合还有虚拟机中与内存相关的参数设置

    2.1 对象优先在Eden分配

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

    在运行时通过-Xms20M-Xmx20M-Xmnl0M这3个参数限制Java堆大小为20MB,且不可扩展,其中10MB分配给新生代,剩下的10MB分配给老年代

    -XX:SurvivorRatio=8决定了新生代中Eden区与一个Survivor区的空间比例是8比1

    注意:

    • 新生代GC(Minor GC):指发生在新生代的垃圾收集动作,因为Java对象大多都具备朝生夕灭的特性,所以Minor GC非常频繁,一般回收速度也比较快
    • 老年代GC(Major GC/Full GC):指发生在老年代的GC,出现了Major GC,经常会伴随至少一次的Minor GC(但非绝对的,在ParallelScavenge收集器的收集策略里就有直接进行Major GC的策略选择过程)。MajorGC的速度一般会比Minor GC慢10倍以上。

    2.2 大对象直接进入老年代

    虚拟机提供了一个-XX:PretenureSizeThreshold参数,令大于这个设置值的对象直接在老年代中分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存拷贝(复习一下:新生代采用复制算法收集内存)。

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

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

    对象晋升老年代的年龄阀值,可以通过参数-XX:Max TenuringThreshold来设置。

    2.4 动态对象年龄判定

    为了能更好地适应不同程序的内存状况,虚拟机并不总是要求对象的年龄必须达到Max TenuringThreshold才能晋升老年代,如果在Survivor空间中相同年龄所有对象大小的总和大Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代,无须等到Max TenuringThreshold中要求的年龄

    2.5 空间分配担保

    在发生Minor GC时,虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小,如果大于,则改为直接进行一次F1GC。如果小于,则查看HandlePromotionFailure设置是否允许担保失败;如果允许,那只会进行Minor GC:如果不允许,则也要改为进行一次Full GC。

    前面提到过,新生代使用复制收集算法,但为了内存利用率,只使用其中一个Survivor空间来作为轮换备份,因此当出现大量对象在Minor GC后仍然存活的情况时(最极端就是内存回收后新生代中所有对象都存活),就需要老年代进行分配担保,让Survivor无法容纳的对象直接进入老年代。与生活中的贷款担保类似,老年代要进行这样的担保,前提是老年代本身还有容纳这些对象的剩余空间,一共有多少对象会活下来,在实际完成内存回收之前是无法明确知道的,所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值,与老年代的剩余空间进行比较,决定是否进行Full GC来让老年代腾出更多空间。取平均值进行比较其实仍然是一种动态概率的手段,也就是说如果某次MiorGC存话后的对象突增,远远高于平均值的话,依然会导致担保失败(HandlePromotion Failure)。如果出现了HandlePromotionFailure失败,那就只好在失败后重新发起一次Fu1GC。虽然担保失败时绕的圈子是最大的,但大部分情况下都还是会将HandlePromotionFailure开关打开,避免Full GC过于频繁

  • 相关阅读:
    面向对象分析与设计_用例图
    Revit建模中如何快速画好幕墙?
    Android学习笔记 23. ViewPager
    Kafka保证消息幂等以及解决方案
    怎么在r里导入自己下载的基因芯片数据
    为什么我的k8s的master节点和node节点的状态都是notready呢
    【踩坑】POST 方法的基于摘要的协商缓存实现
    java毕业设计在线文档管理系统Mybatis+系统+数据库+调试部署
    three.js简介
    算法复杂度分析笔记
  • 原文地址:https://blog.csdn.net/qq_37776700/article/details/127897899