网站数据分析案例,濮阳网站建设优化,济南网站建设山东聚搜网咨询,沃噻网站建设流程垃圾收集算法与垃圾收集器ParNew CMS
垃圾收集算法
#### f
分代收集理论 当前虚拟机的垃圾收集都采用分代收集算法。根据对象存活周期不同将内存分为几块#xff0c;一般将java堆分为新生代和老年代#xff0c;然后根据各个年代的特点选择不同的垃圾收集算法。 在新…垃圾收集算法与垃圾收集器ParNew CMS
垃圾收集算法
#### f
分代收集理论 当前虚拟机的垃圾收集都采用分代收集算法。根据对象存活周期不同将内存分为几块一般将java堆分为新生代和老年代然后根据各个年代的特点选择不同的垃圾收集算法。 在新生代中每次收集都会有大量对象死去所以可以选择复制算法。只需要付出少量对象的复制成本就可以完成每次垃圾收集。 而老年代的对象存活记录是比较高的而且没有额外的空间对它进行担保所以必须选择“标记-清除”和”标记整理“算法进行垃圾收集。 “标记-清除”或“标记-整理”算法会比复制算法慢10倍以上
标记-复制算法
将内存分为大小相同的两块每次使用一块。当这一块的内存使用完后就将还存活的对象复制到另一去然后再把使用的空间一次清理掉。这样就使每次回收的内存回收都是对内存区间的一般进行回收。 标记-清除算法 算法分为“标记”和“清除”阶段标记存活的对象统一回收所有未被标记的对象也可以反过来标记出所有需要回收的对象在标记完成之后统一回收所有被标记的对象。它是最基础的收集算法。 会带来两个明显的问题 效率问题如果需要标记的对象过多效率不高空间问题标记清除后会产生大量不连续的碎片
标记-整理
标记过程和”标记-清除算法“一样但后续的步骤不熟直接对可回收对象进行回收而是让所有存活的对象向另一端移动然后清理掉端边界以外的内存 垃圾收集器 收集算法是内存回收的方法论垃圾收集器是内存回收的具体实现
能做的是根据具体的应用选择适合自己的垃圾收集器
Serial收集器(-XX:UseSericalGC -XX:UseSerialOldGC)
Serial(串行)收集器是最基本的历史最悠久的垃圾收集器。它只会用一条线程去完成垃圾收集工作它在进行垃圾收集的时候必须暂停其他所有的“工作线程”(Stop the World)直到它收集结束。
新生代复制算法老年代采用标记-整理算法 Serial Old收集器是Serial收集器的老年代版本它同样是一个单线程收集器。
它主要有两个用途一种用途是在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用另一种用途是作为CMS收集器的后备方案。
Parallel Scavenge收集器(-XX:UseParallelGC(年轻代) -XX:UseParallelOldGC老年代)
Parallel收集器就是Serial收集器的多线程版本除了使用多线程进行垃圾收集外其余行为控制参数、收集算法、回收策略等等和Serial收集器类似。默认的收集线程数跟CPU核数相同也可以用参数(-XX:ParallelGCThreads)指定收集线程数但是一般不推荐修改
Parallel Scavenge收集器关注点是吞吐量高效利用CPU。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间提高用户体验。吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量。
新生代采用复制算法老年代采用标记-整理算法 Parallel Old收集器是Parallel Scavenge收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源的场合都可以优先考虑Parallel Scavenge收集器和Parallel Old收集器JDK8默认的新生代和老年代收集器
ParNew收集器(-XX:UseParNewGC)
ParNew收集器其实跟Parallel收集器很类似区别主要在于它可以和CMS收集器配合使用
新生代采用复制算法 除了Serial收集器外只有它能与CMS收集器配合工作
CMS收集器(-XX:UseConcMarkSweepGC(老年代))
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。它是HotSpot虚拟机第一款真正意义上的并发收集器它第一次实现了让垃圾收集线程与用户线程基本上同时工作。
CMS是“标记-清除”算法实现的它的运作过程分为四个阶段 初始标记暂停所有的其他线程STW并记录下GC Roots直接能应用的对象速度很快 并发标记并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程整个过程耗时较长但是不需要停顿用户线程可以与垃圾收集线程一起并发运行。用户线程继续运行可能会有已经标记过的对象状态发生改变 重新标记:重新标记就是为了修正并发标记期间因为用户线程继续运行而导致标记产生变动的那一部分对象的标记记录主要是处理漏标问题这个阶段的停顿时间一般比初始标记时间稍长远远比并发标记阶段时间短主要用到三色标记里的增量更新算法做重新标记 并发清理开启用户线程同时GC线程会对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理。 并发重置重置本次GC过程中的标记数据
主要优点并发收集低停顿
缺点
对CPU资源敏感会和服务器抢资源无法处理浮动垃圾在并发标记和并发清理阶段有产生垃圾这种浮动垃圾只能等到下一次GC再清理了它使用的回收算法“标记-清除”算法会导致收集结束后会有大量的空间碎片产生当然可以通过参数-XX:UseCMSCompactAtFullCollection可以让JVM在执行完成标记清除后再做整理执行过程中的不确定性会存在上一次垃圾回收还没执行完然后垃圾回收又被触发的情况特别是在并发标记和并发清理阶段出现一边回收系统一边运行也许还没回收完再次触发Full GC,也就是“concurrent mode failure”此时会进入stop the world用serial Old垃圾收集器来收集
CMS相关参数
-XX:UseConcMarkSweepGC启用cms-XX:ConcGCThreads并发的GC线程数-XX:UseCMSCompactAtFullCollectionFullGC之后做压缩整理减少碎片-XX:CMSFullGCsBeforeCompaction多少次FullGC之后压缩一次默认是0代表每次FullGC后都会压缩一次-XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC默认是92这是百分比-XX:UseCMSInitiatingOccupancyOnly只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)如果不指定JVM仅在第一次使用设定值后续则会自动调整-XX:CMSScavengeBeforeRemark在CMS GC前启动一次minor gc降低CMS GC标记阶段**(也会对年轻代一起做标记如果在minor gc就干掉了很多对垃圾对象标记阶段就会减少一些标记时间)**时的开销一般CMS的GC耗时 80%都在标记阶段-XX:CMSParallellnitialMarkEnabled表示在初始标记的时候多线程执行缩短STW-XX:CMSParallelRemarkEnabled在重新标记的时候多线程执行缩短STW;
亿级流量电商系统如何优化JVM参数设置ParNew CMS
大型电商系统后端现在一般都是拆分为多个子系统部署的比如商品系统库存系统订单系统促销系统会员系统等等。
我们这里以比较核心的订单系统为例 对于8G内存我们一般是分配4G内存给JVM正常的JVM参数配置如下
-Xms3072M -Xmx3072M -Xss1M -XX:MetaspaceSize256M -XX:MaxMetaspaceSize256M -XX:SurvivorRatio8这样设置可能会由于动态对象年龄判断原则导致频繁full gc。
于是我们可以更新下JVM参数设置
-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize256M -XX:MaxMetaspaceSize256M -XX:SurvivorRatio8 这样就降低了因为对象动态年龄判断原则导致的对象频繁进入老年代的问题很多优化就是让短期存活的对象尽量留着survivor里面不要进入老年代这样在minor GC的时候这些对象都会被回收不会进入老年代从而导致full GC
对于对象年龄应该为多少才移动到老年代比较合适本例中一次minor gc要间隔二三十秒大多数对象一般在几秒内就会变为垃圾完全可以将默认的15岁改小一点比如改为5那么意味着对象要经过5次minor gc才会进入老年代整个时间也有一两分钟了如果对象这么长时间都没被回收完全可以认为这些对象是会存活的比较长的对象可以移动到老年代而不是继续一直占用survivor区空间。
对于多大的对象直接进入老年代(参数-XX:PretenureSizeThreshold)这个一般可以结合你自己系统看下有没有什么大对象生成预估下大对象的大小一般来说设置为1M就差不多了很少有超过1M的大对象这些对象一般就是你系统初始化分配的缓存对象比如大的缓存ListMap之类的对象。
可以适当调整JVM参数如下
-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize256M -XX:MaxMetaspaceSize256M -XX:SurvivorRatio8
-XX:MaxTenuringThreshold5 -XX:PretenureSizeThreshold1M 对于JDK8默认的垃圾回收器是-XX:UseParallelGC(年轻代)和-XX:UseParallelOldGC(老年代)如果内存较大(超过4个G只是经验值)系统对停顿时间比较敏感我们可以使用ParNewCMS(-XX:UseParNewGC -XX:UseConcMarkSweepGC**)**
对于老年代CMS的参数如何设置我们可以思考下首先我们想下当前这个系统有哪些对象可能会长期存活躲过5次以上minor gc最终进入老年代。
无非就是那些Spring容器里的Bean线程池对象一些初始化缓存数据对象等这些加起来充其量也就几十MB。
还有就是某次minor gc完了之后还有超过一两百M的对象存活那么就会直接进入老年代比如突然某一秒瞬间要处理五六百单那么每秒生成的对象可能有一百多M再加上整个系统可能压力剧增一个订单要好几秒才能处理完下一秒可能又有很多订单过来。
我们可以估算下大概每隔五六分钟出现一次这样的情况那么大概半小时到一小时之间就可能因为老年代满了触发一次Full GCFull GC的触发条件还有我们之前说过的老年代空间分配担保机制历次的minor gc挪动到老年代的对象大小肯定是非常小的所以几乎不会在minor gc触发之前由于老年代空间分配担保失败而产生full gc其实在半小时后发生full gc这时候已经过了抢购的最高峰期后续可能几小时才做一次FullGC。
对于碎片整理因为都是1小时或几小时才做一次FullGC是可以每做完一次就开始碎片整理或者两到三次之后再做一次也行。
综上只要年轻代参数设置合理老年代CMS的参数设置基本都可以用默认值如下所示
-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize256M -XX:MaxMetaspaceSize256M -XX:SurvivorRatio8
-XX:MaxTenuringThreshold5 -XX:PretenureSizeThreshold1M -XX:UseParNewGC -XX:UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction92 -XX:UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction3垃圾收集算法底层算法实现
三色标记
在并发标记的过程中因为标记期间应用线程还在继续跑对象间的引用可能发生变化多标和漏标的情况就有可能发生漏标的问题主要引入三色标记来解决
三色标记是把GC Roots可达性分析遍历对象过程中遇到的对象按照”是否访问过“这个条件标记成以下三种颜色
黑色:表示对象已经被垃圾收集器访问过且这个对象的所有引用都已经被扫描过。黑色的对象代表以及扫描过它是安全存活的如果有其他对象那个引用指向了黑色对象无需重新扫描一遍。黑色对象不能直接不经过灰色对象指向某个白色对象灰色表示对象已经被垃圾收集器访问过但这个对象至少存在一个引用还没有被扫描到白色表示对象尚未被垃圾收集器访问过。在可达性分析刚刚开始的阶段所有的对象但是白色的若在分析结束阶段仍然是白色的对象即代表不可达 /*** 垃圾收集算法细节之三色标记* 为了简化例子代码写法可能不规范请忽略* Created by 诸葛老师*/
public class ThreeColorRemark {public static void main(String[] args) {A a new A();//开始做并发标记D d a.b.d; // 1.读a.b.d null; // 2.写a.d d; // 3.写}
}class A {B b new B();D d null;
}class B {C c new C();D d new D();
}class C {
}class D {
}多标-浮动垃圾
在并发标记过程中如果由于方法运行结束导致部分局部变量GC、Roots被销毁这个GC Roots引用的对象之前又被扫描过被标记未非垃圾对象那么本次GC不会回收这部分内存这部分本应该回收但是没有回收到的内存被称之为”浮动垃圾“。浮动垃圾并不会影响垃圾回收的正确性只是需要等到下一轮垃圾回收才会被清除
另外针对并发标记还有并发清理开始后产生的新对象通常做法是直接全部当成黑色本轮不会进行清除。这部分对象期间可能也会变为垃圾这也算浮动垃圾的一部分
漏标-读写屏障
漏标会导致被引用的对象被当成垃圾误删除必须解决有两种解决方法增量更新和原始快照增量更新就是当黑色对象插入新的指向白色对象的引用关系时就将这个新插入的引用记录下来等并发扫描结束之后再将这些记录过的引用关系中的黑色对象为根重新扫描一次可用简单理解为黑色对象一旦新插入了指向白色对象的引用后它就变为灰色对象了原始快照就是当灰色对象要删除指向白色对象的引用关系时就将这个要删除的引用记录下来在并发扫描结束后再将这些记录过的引用关系中的灰色对象为根再扫描一次这样就能扫描到白色的对象将白色的对象直接标记为黑色目的就是让这种对象在本次GC清理中能活下来待下一轮GC的时候重新扫描这个对象也有可能是浮动垃圾以上无论是对引用关系记录的插入还是删除虚拟机的记录操作都是通过写屏障实现的
写屏障
给某个对象的成员变量赋值时底层代码
/**
* param field 某对象的成员变量如 a.b.d
* param new_value 新值如 null
*/
void oop_field_store(oop* field, oop new_value) { *field new_value; // 赋值操作
} 所谓的写屏障就是指在赋值操作前后加入一些处理
void oop_field_store(oop* field, oop new_value) { pre_write_barrier(field); // 写屏障-写前操作*field new_value; post_write_barrier(field, value); // 写屏障-写后操作
}写屏障实现SATB
当对象B的成员变量的引用发生变化时比如引用消失a.b.d null可以利用写屏障将B原来成员变量的引用对象D记录下来
void pre_write_barrier(oop* field) {oop old_value *field; // 获取旧值remark_set.add(old_value); // 记录原来的引用对象
}写屏障实现增量更新
当对象的成员变量的引用发生变化时比如新增引用a.d d),我们可以利用写屏障将A新的成员变量引用对象D记录下来
void post_write_barrier(oop* field, oop new_value) { remark_set.add(new_value); // 记录新引用的对象
}读屏障
oop oop_field_load(oop* field) {pre_load_barrier(field); // 读屏障-读取前操作return *field;
}读屏障是直接针对第一步D d a.b.d当读取成员变量时都记录下来
void pre_load_barrier(oop* field) { oop old_value *field;remark_set.add(old_value); // 记录读取到的对象
}现代追踪式可达性分析的垃圾回收器几乎都借鉴了三色标记的算法思想尽管实现的方式不尽相同比如白色/黑色集合一般都不会出现但是有其他体现颜色的地方、灰色集合可以通过栈/队列/缓存日志等方式进行实现、遍历方式可以是广度/深度遍历等等。
对于读写屏障以Java HotSpot VM为例其并发标记时对漏标的处理方案如下
CMS写屏障 增量更新G1Shenandoah写屏障 SATBZGC读屏障
记忆集与卡表
在新生代做GCRoots可达性扫描过程中可能会碰到跨代引用的对象这种如果又去对老年代再去扫描效率太低了。
为此在新生代可以引入记录集Remember Set的数据结构记录从非收集区到收集区的指针集合避免把整个老年代加入GCRoots扫描范围。事实上并不只是新生代、 老年代之间才有跨代引用的问题 所有涉及部分区域收集Partial GC 行为的垃圾收集器 典型的如G1、 ZGC和Shenandoah收集器 都会面临相同的问题。
垃圾收集场景中收集器只需通过记忆集判断出某一块非收集区域是否存在指向收集区域的指针即可无需了解跨代引用指针的全部细节。
hotspot使用一种叫做“卡表”(Cardtable)的方式实现记忆集也是目前最常用的一种方式。关于卡表与记忆集的关系 可以类比为Java语言中HashMap与Map的关系。
卡表是使用一个字节数组实现CARD_TABLE[ ]每个元素对应着其标识的内存区域一块特定大小的内存块称为“卡页”。
hotSpot使用的卡页是2^9大小即512字节 一个卡页中可包含多个对象只要有一个对象的字段存在跨代指针其对应的卡表的元素标识就变成1表示该元素变脏否则为0.
GC时只要筛选本收集区的卡表中变脏的元素加入GCRoots里。
卡表的维护
卡表变脏上面已经说了但是需要知道如何让卡表变脏即发生引用字段赋值时如何更新卡表对应的标识为1。
Hotspot使用写屏障维护卡表状态。
