简述网站制作方案和主要内容,百度商店应用市场,深圳汇网网站建设,做网站推广哪些一、GC垃圾回收算法 标记-清除算法
算法分为“标记”和“清除”阶段#xff1a;标记存活的对象#xff0c; 统一回收所有未被标记的对象(一般选择这种)#xff1b;也可以反过来#xff0c;标记出所有需要回收的对象#xff0c;在标记完成后统一回收所有被标记的对象 。它…一、GC垃圾回收算法 标记-清除算法
算法分为“标记”和“清除”阶段标记存活的对象 统一回收所有未被标记的对象(一般选择这种)也可以反过来标记出所有需要回收的对象在标记完成后统一回收所有被标记的对象 。它是最基础的收集算法比较简单但是会带来两个明显的问题
效率问题 (如果需要标记的对象太多效率不高)空间问题标记清除后会产生大量不连续的碎片 标记-整理算法
根据老年代的特点特出的一种标记算法标记过程仍然与“标记-清除”算法一样但后续步骤不是直接对可回收对象回收而是让所有存活的对象向一端移动然后直接清理掉端边界以外的内存。 复制算法
为了解决效率问题“复制”收集算法出现了。它可以将内存分为大小相同的两块每次使用其中的一块。当这一块的内存使用完后就将还存活的对象复制到另一块去然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。 分代收集算法
当前虚拟机的垃圾收集都采用分代收集算法这种算法没有什么新的思想只是根据对象存活周期的不同将内存分为几块。一般将java堆分为新生代和老年代这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
比如在新生代中每次收集都会有大量对象(近99%)死去所以可以选择复制算法只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的而且没有额外的空间对它进行分配担保所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。注意“标记-清除”或“标记-整理”算法会比复制算法慢10倍以上。
二、GC垃圾回收器实现
常见的GC回收器的种类
1serial回收器在GC回收的时候停掉工作线程他是一个串行的回收器
2parallel回收器在GC回收的时候停掉工作线程这种GC回收器是并发执行的
3CMS他的全程是concurrent mark sweep他的主要优势是在GC回收的时候不需要全程stop the world
4G1:这个是从JDK7后推出的新的GC适应大型并发场景 衡量GC的指标主要是吞吐量、暂停时间。
吞吐量是CPU用于运行用户代码的时间与CPU总消耗时间的比值即吞吐量 运行用户代码时间 /运行用户代码时间垃圾收集时间。比如虚拟机总共运行了100分钟其中垃圾收集花掉1分钟那吞吐量就是99%。暂停时间是指一个时间段内应用程序线程暂停让GC线程执行的状态。例如GC期间100毫秒的暂停时间意味着在这100毫秒期间内没有应用程序线程是活动的。回收效率是指一次GC能真正回收的垃圾对象的数量以及能够回收的垃圾对象占实际垃圾对象的比例。
Serial收集器(-XX:UseSerialGC -XX:UseSerialOldGC)
Serial串行收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程 Stop The World 直到它收集结束。
新生代采用复制算法老年代采用标记-整理算法。
虚拟机的设计者们当然知道Stop The World带来的不良用户体验所以在后续的垃圾收集器设计中停顿时间在不断缩短仍然还有停顿寻找最优秀的垃圾收集器的过程仍然在继续。
Parallel收集器(-XX:UseParallelGC(年轻代),-XX:UseParallelOldGC(老年代))
Parallel收集器其实就是Serial收集器的多线程版本除了使用多线程进行垃圾收集外其余行为控制参数、收集算法、回收策略等等和Serial收集器类似。默认的收集线程数跟cpu核数相同当然也可以用参数(-XX:ParallelGCThreads)指定收集线程数但是一般不推荐修改。
Parallel Scavenge收集器关注点是吞吐量高效率的利用CPU。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间提高用户体验。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。 Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量如果对于收集器运作不太了解的话可以选择把内存管理优化交给虚拟机去完成也是一个不错的选择。
新生代采用复制算法老年代采用标记-整理算法。
CMS收集器(-XX:UseConcMarkSweepGC(old))
CMSConcurrent Mark Sweep收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用它是HotSpot虚拟机第一款真正意义上的并发收集器它第一次实现了让垃圾收集线程与用户线程基本上同时工作。
从名字中的Mark Sweep这两个词可以看出CMS收集器是一种 “标记-清除”算法实现的它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤
初始标记 暂停所有的其他线程(STW)并记录下gc roots直接能引用的对象速度很快。并发标记 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程 这个过程耗时较长但是不需要停顿用户线程 可以与垃圾收集线程一起并发运行。因为用户程序继续运行可能会有导致已经标记过的对象状态发生改变。重新标记 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录(主要是处理漏标问题)这个阶段的停顿时间一般会比初始标记阶段的时间稍长远远比并发标记阶段时间短。并发清理 开启用户线程同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理。
从它的名字就可以看出它是一款优秀的垃圾收集器主要优点并发收集、低停顿。但是它有下面几个明显的缺点
对CPU资源敏感会和服务抢资源无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾这种浮动垃圾只能等到下一次gc再清理了)它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。
G1收集器-XX:UseG1GC
G1回收器会将区域划分为region每个region可以是新生代也可以是老年代通过控制对region的回收做到对垃圾回收导致的STW可控。垃圾回收的阶段前3个阶段和CMS一致只是最后一个节点需要通过混合清除来回收新生代和老年代所有的对象
初始标记标记GC root对象需要暂停所有用户线程该过程会引发STW并发标记标记GC root可达的对象。最终标记标记在并发标记阶段产生的需回收对象。筛选回收对各个Region的回收成本和价值进行排序根据用心要求的GC停顿时间来选择需要GC的Region。 G1的优缺点分别为
优点1并发处理效率高2整体停顿STW的时间可控3新生掉和老年代都分为逻辑上的region通过GC的复制算法解决内存碎片的问题缺点引入了Remembered Set来保存内存引用信息所以增加了内存占用所以G1一般在大内存的服务端环境使用起步内存大小为8G。
GC垃圾回收器对比和总结
选择GC主要考虑的是使用场景一般嵌入式、内存较小的选择Serial收集器对于需求吞吐量大的常见可以选择Parallel收集器对于需求时延短的场景可以选择CMS收集器G1回收器整体是平衡了降低时延和增大吞吐量的要求适用于海量并发场景对系统资源也有较高的要求
三、GC垃圾回收器的常见机制
大对象直接进入老年代
大对象就是需要大量连续内存空间的对象比如字符串、数组。JVM参数 -XX:PretenureSizeThreshold 可以设置大对象的大小如果对象超过设置大小会直接进入老年代不会进入年轻代这个参数只在 Serial 和ParNew两个收集器下有效。
比如设置JVM参数-XX:PretenureSizeThreshold1000000 (单位是字节) -XX:UseSerialGC 再执行下上面的第一个程序会发现大对象直接进了老年代。这样做的原因是为了避免为大对象分配内存时的复制操作而降低效率。
长期存活的对象将进入老年代
既然虚拟机采用了分代收集的思想来管理内存那么内存回收时就必须能识别哪些对象应放在新生代哪些对象应放在老年代中。为了做到这一点虚拟机给每个对象一个对象年龄Age计数器。
如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活并且能被 Survivor 容纳的话将被移动到 Survivor 空间中并将对象年龄设为1。对象在 Survivor 中每熬过一次 MinorGC年龄就增加1岁当它的年龄增加到一定程度默认为15岁CMS收集器默认6岁不同的垃圾收集器会略微有点不同就会被晋升到老年代中。对象晋升到老年代的年龄阈值可以通过参数 -XX:MaxTenuringThreshold 来设置。
批量对象动态年龄判断
当前放对象的Survivor区域里(其中一块区域放对象的那块s区)一批对象的总大小大于这块Survivor区域内存大小的50%(-XX:TargetSurvivorRatio可以指定)那么此时大于等于这批对象年龄最大值的对象就可以直接进入老年代了例如Survivor区域里现在有一批对象年龄1年龄2年龄n的多个年龄对象总和超过了Survivor区域的50%此时就会把年龄n(含)以上的对象都放入老年代。这个规则其实是希望那些可能是长期存活的对象尽早进入老年代。
批量对象动态年龄判断机制一般是在minor gc之后触发的。
老年代空间分配担保机制
年轻代每次minor gc之前JVM都会计算下老年代剩余可用空间如果这个可用空间小于年轻代里现有的所有对象大小之和(包括垃圾对象)就会看一个“-XX:-HandlePromotionFailure”(jdk1.8默认就设置了)的参数是否设置了如果有这个参数就会看看老年代的可用内存大小是否大于之前每一次minor gc后进入老年代的对象的平均大小。
如果上一步结果是小于或者之前说的参数没有设置那么就会触发一次Full gc对老年代和年轻代一起回收一次垃圾如果回收完还是没有足够空间存放新的对象就会发生OOM当然如果minor gc之后剩余存活的需要挪动到老年代的对象大小还是大于老年代可用空间那么也会触发full gcfull gc完之后如果还是没有空间放minor gc之后的存活对象则也会发生“OOM”。
老年代空间分配担保机制判断是在minor gc之前触发的。 本文由博客一文多发平台 OpenWrite 发布
