外贸网站建设官网,中国菲律宾合作,wordpress中介模板,顺德建设网站公司垃圾收集算法有如下几种#xff1a; 分代收集理论#xff1a;年龄代和老年代选择各自的垃圾收集算法。 复制算法#xff1a;可达性分析算法找非垃圾对象#xff0c;然后把非垃圾对象移动到另一端#xff0c;这一端的垃圾对象清除#xff0c;该方法浪费内…垃圾收集算法有如下几种 分代收集理论年龄代和老年代选择各自的垃圾收集算法。 复制算法可达性分析算法找非垃圾对象然后把非垃圾对象移动到另一端这一端的垃圾对象清除该方法浪费内存用于年轻代。 标记清除算法非垃圾对象标记好没有标记的全清除掉存在效率问题(如果需要标记的对象太多效率不高)、空间问题(标记清除后会产生大量不连续的碎片) 标记整理算法标记过程仍然与“标记-清除”算法一样但后续步骤不是直接对可回收对象回收。而是让所有存活的对象向一端移动然后直接清理掉边界外的内存。
垃圾收集器
serial垃圾收集器(-XX:UseSerialGC(年轻代使用) -XX:UseSerialOldGC(FullGC时使用)) 其时单线程的在进行垃圾收集工作的时候必须暂停其他所有工作线程(STW)。优势是单核时快简单易于理解只能收集几十M到几百M。新生代采用复制算法老年代使用标记整理算法。Parallel Scavenge收集器(-XX:useParallelGC(年轻代) -XX:UseParallelOldGC(老年代)) STW时多线程收集新生代采用复制算法老年代采用标记整理算法。ParNew收集器(-XX:UseParNewGC) 跟Parallel差不多Parallel无法跟CMS配合。CMS是老年代的。CMS收集器(-XX:UseConcMarkSweepGC) JDK1.8默认年轻代和老年代是ParallelGC、ParallelOldGCSWT时间长(内存大时) CMS收集器时一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用它是HotSpot虚拟机第一款真正意义上的并发收集器它第一次实现了让垃圾收集线程与用户线程(基本上)同时工作。 初始标记暂停所有其他线程(STW)并记录下gc roots直接能引用的对象速度很快并发标记并发标记阶段是从GC Root的直接关联对象开始遍历整个对象的过程这个过程耗时较长但不需要停顿用户线程可以与赖叽收集器线程一起并发运行。因为用户线程继续运行可能会导致已经标记的对象状态发生改变。重新标记重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录这个阶段的停顿时间一般会比初始标记阶段的时间稍长远远比并发标记时间短主要用到三色标记里的增量更新算法啊做重新标记。并发清理开启用户线程同时GC线程开始对胃标记的区域做清扫这个阶段如果有新增对象会被标记为黑色不做任何处理。并发重置重置本次GC过程中的标记数据。 (Parallel更在意吞吐量CPU执行垃圾收集的时间越短吞吐量越高) 缺点对CPU资源敏感(会和服务抢资源) 无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾这种浮动垃圾只能等到下一次再清理了) 它使用的回收算法“标记-清除”算法会导致收集结束时会有大量空间碎片当然可以通过参数-XX:UseCMSCompactAtFullCollection可以让JVM再执行完标记清除后再做整理。 执行过程中的不确定性会存在上一次垃圾回收还没执行完然后垃圾回收又被触发的情况。“特别是在并发标记和并发清理阶段会出现”一边回收系统一边运行也许没回收完再次出发Full GC也就是“concurrent mode failure”此时会进入STW用serial old垃圾收集器来回收。
CMS相关核心参数
-XX:UseConcMarkSweepGC启用CMS-XX:ConcGCThreads并发的GC线程数-XX:UseCMSCompactAtFullCollectionFull GC之后做压缩整理(减少碎片)-XX:CMSFullGCsBeforeCompaction多次Full GC之后压缩一次默认是0代表每次Full GC后都会压缩一次。-XX:CMSInitiatingOccupancyFraction当老年代使用达到该比例时会出发Full GC(默认92是百分比)-XX:UseCMSInitiatingOccupancyOnly只使用设定的回收阀值如果不指定JVM仅在第一次使用设定值后续则会自动调整-XX:CMSScavengeBeforeRemark在CMS GC前启动一次minor gc目的在于减少老年代对年轻代的引用降低CMS GC的标记阶段的开销一般CMS的GC耗时80%都在标记阶段-XX:CMSParallelInitialMarkEnabled表示在初始标记的时候多线程执行缩短STW-XX:CMSParallelRemarkEnabled在重新标记的时候多线程执行缩短STW
三色标记 在并发标记过程中因为标记期间应用程序还在继续跑对象间的引用可能发生变化多标或漏标的情况就有可能发生 (三色标记)把我们所有的对象在GC可达性分析过程中把对象分为3种
黑色表示对象已经被垃圾收集器访问过且这个对象的所有引用都已经扫描过。黑色对象代表已经扫描过它是安全存活的如果有其他对象引用指向了黑色对象无须重新扫描一遍。黑色对象不可能直接(不经过灰色对象)指向某个白色对象。灰色表示对象已经被垃圾收集器访问过但这个对象上至少存在一个引用还没有被扫描过。白色表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段所有对象都是白色的若在分析结束的阶段仍然是白色的对象即代表不可达。
多标-浮动垃圾
在并发标记过程中如果由于方法运行结束导致部分局部变量(gcroot)被销毁这个gcroot引用的对象之前又被扫描过(被标记为非垃圾对象)那么本轮GC不会回收这部分内存这部分本应该回收但是没有回收到的内存被称之为“浮动垃圾”。浮动垃圾并不会影响垃圾回收的正确性只是需要等到下一轮垃圾回收中才被清除。 另外针对并发标记(还有并发清理)开始后产生的新对象通常的做法是直接全部当成黑色本轮不会进行清除。这部分对象期间可能也会变为垃圾们这也算是浮动垃圾的一部分。
漏标——读写屏障 有两种解决方案增量更新和原始快照。 增量更新在你的所有对象如果在作赋值把A的成员变量指向D指针搞一个集合存起来(重新标记过程中找到之前记录的新增的引用重新扫描A重新标记为灰色灰色还会重新扫描)。把新增那些引用的源头和它引用的对象都记录到一个集合。重新标记为灰色以后再扫。就是当黑色对象插入新的指向白色对象的引用关系时就将这个新插入的引用记录下来等并发扫描结束之后再将这些记录过的引用关系中的黑色对象为根重新扫描一次。这可以简化为黑色对象一旦新插入了指向白色对象的引用之后它就变为灰色对象了。 原始快照就是当灰色对象要删除指向白色对象的引用关系时就将这个要删除的引用记录下来在并发扫描结束之后再将这些记录过的引用关系中的灰色对象为根重新扫描一次这样就能扫到白色对象将白色对象直接标为黑色。 以上无论是对引用关系记录的插入还是删除虚拟机的记录操作都是通过写屏障实现的。 写屏障要么在赋值操作之前要么之后把引用丢入集合在写操作前面做一些事后面做一些事我们叫代码的操作屏障。 现代追踪式(可达性分析)的垃圾回收器几乎都借鉴了三色标记的算法思想尽管实现的方式不尽相同比如白色/黑色集合一般都不会出现(但是有其他体现颜色的方法)、灰色集合可以通过栈/队列/缓存日志等方式进行实现、遍历方式可以式广度/深度遍历等等。 对于读写屏障以Java HotSpot VM为例其并发标记对漏标的处理方案如下
CMS写屏障增量更新G1Shenandoah写屏障SATBZGC读屏障 工程实现中读写屏障还有其他功能比如写屏障可以用于记录跨代/区引用的变化读屏障可以用于支持移动对象的并发执行等。功能之外还有性能的考虑所以对于选择哪种每款垃圾回收器都有自己的想法。
记忆集与卡表 JVM扫描时对跨代引用如果一个对象被老年代引用没办法通过gc root直接在年轻代找在年轻代空间开辟了一小块区域维护老年代对年轻代所有的引用。跨代引用很少用CardTable实现只要有一个对象引用到年轻代对象标记为dirty。CardTable底层实现是一个数组除了记录是否为脏记录卡页的起始内存地址根据起始地址找到卡页里所有对象也加到年轻代的扫描机。卡页在老年代维护每页的状态信息和地址在年轻代。
