郑州建设工程协会网站,网站建设首先要,群晖wordpress中文,创新网站内容建设目录
判断一个对象是否死亡#xff1f;
1、引用计数法
2、可达性分析算法
三色标记
垃圾收集算法
1、分代收集理论
2、垃圾回收算法
标记-清除
标记-复制
标记-整理
CMS#xff08;Concurrent Mark Sweep#xff09;收集器
CMS垃圾收集器步骤
CMS垃圾收集器优…目录
判断一个对象是否死亡
1、引用计数法
2、可达性分析算法
三色标记
垃圾收集算法
1、分代收集理论
2、垃圾回收算法
标记-清除
标记-复制
标记-整理
CMSConcurrent Mark Sweep收集器
CMS垃圾收集器步骤
CMS垃圾收集器优缺点 垃圾收集需要完成的三件事情
哪些内存需要回收什么时候回收如何回收
判断一个对象是否死亡 在堆里面存放着Java世界中几乎所有的对象实例垃圾收集器在对堆进行回收前第一件事情就 是要确定这些对象之中哪些还“存活”着哪些已经“死去”“死去”即不可能再被任何途径使用的对 象)了 1、引用计数法
引用计数法在对象中添加一个引用计数器每当有一个地方引用它时计数器值就加一当引用失效时计数器值就减一任何时刻计数器为零的对象就是不可能再被使用的。
客观地说引用计数算法Reference Counting虽然占用了一些额外的内存空间来进行计数但 它的原理简单判定效率也很高在大多数情况下它都是一个不错的算法。但是在Java领域至少主流的Java虚拟机里面都没有选用引用计数算法来管理内存主要原因是这个看似简单的算法有很多例外情况要考虑必须要配合大量额外处理才能保证正确地工作譬如单纯的引用计数 就很难解决对象之间相互循环引用的问题。举个例子对象objA和objB都有字段instance赋值令objA.instanceobjB及objB.instanceobjA除此之外这两个对象再无任何引用实际上这两个对象已经不可能再被访问但是它们因为互相引用着对方导致它们的引用计数都不为零引用计数算法也就无法回收它们。
2、可达性分析算法
当前主流的商用程序语言的内存管理子系统都是通过可达性分析Reachability Analysis算法来判定对象是否存活的。这个算法的基本思路就是通过一系列称为“GC Roots”的根对象作为起始节点集从这些节点开始根据引用关系向下搜索搜索过程所走过的路径称为“引用链Reference Chain如果某个对象到GC Roots间没有任何引用链相连或者用图论的话来说就是从GC Roots到这个对象不可达时则证明此对象是不可能再被使用的。 如图所示对象object 5、object 6、object 7虽然互有关联但是它们到GC Roots是不可达的因此它们将会被判定为可回收的对象。
三色标记
上面曾经提到了当前主流编程语言的垃圾收集器基本上都是依靠可达性分析算法来判定对象是否存活的可达性分析算法理论上要求全过程都基于一个能保障一致性的快照中才能够进行分析这意味着必须全程冻结用户线程的运行。从GC Roots再继续往下遍历对象图这一步骤的停顿时间就必定会与Java堆容量直接成正比例关系了堆越大存储的对象越多对象图结构越复杂要标记更多对象而产生的停顿时间自然就更长这听起来是理所当然的事情。要知道包含“标记”阶段是所有追踪式垃圾收集算法的共同特征如果这个阶段会随着堆变大而等比例增加停顿时间其影响就会波及几乎所有的垃圾收集器同理可知如果能够削减这部分停顿时间的话那收益也将会是系统性的。 想解决或者降低用户线程的停顿就要先搞清楚为什么必须在一个能保障一致性的快照上才能进 行对象图的遍历为了能解释清楚这个问题我们引入三色标记Tri-color Marking作为工具来辅助推导把遍历对象图过程中遇到的对象按照“是否访问过”这个条件标记成以下三种颜色
白色表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段所有的对象都是白色的若在分析结束的阶段仍然是白色的对象即代表不可达。黑色表示对象已经被垃圾收集器访问过且这个对象的所有引用都已经扫描过。黑色的对象代表已经扫描过它是安全存活的如果有其他对象引用指向了黑色对象无须重新扫描一遍。黑色对象不可能直接不经过灰色对象指向某个白色对象。灰色表示对象已经被垃圾收集器访问过但这个对象上至少存在一个引用还没有被扫描过。
关于可达性分析的扫描过程把它看作对象图上一股以灰色为波峰的波纹从黑向白推进的过程。如果用户线程此时是冻结的只有收集器线程在工作那不会有任何问题。但如果用户线程与收集器是并发工作呢收集器在对象图上标记颜色同时用户线程在修改引用关系——即修改对象图的结构这样可能出现两种后果。一种是把原本消亡的对象错误标记为存活这不是好事但其实是可以容忍的只不过产生了一点逃过本次收集的浮动垃圾而已下次收集清理掉就好。另一种是把原本存活的对象错误标记为已消亡这就是非常致命的后果了程序肯定会因此发生错误
下面演示了这样的致命错误具体是如何产生的 当且仅当以下两个条件同时满足时会产生“对象消失”的问题即原本应该是黑色的对象被误标为白色
赋值器插入了一条或多条从黑色对象到白色对象的新引用赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。
因此我们要解决并发扫描时的对象消失问题只需破坏这两个条件的任意一个即可。由此分别 产生了两种解决方案增量更新和原始快照
增量更新要破坏的是第一个条件当黑色对象插入新的指向白色对象的引用关系时就将这个新插入的引用记录下来等并发扫描结束之后再将这些记录过的引用关系中的黑色对象为根重新扫描一次。这可以简化理解为黑色对象一旦新插入了指向白色对象的引用之后它就变回灰色对象了。原始快照要破坏的是第二个条件当灰色对象要删除指向白色对象的引用关系时就将这个要删除的引用记录下来在并发扫描结束之后再将这些记录过的引用关系中的灰色对象为根重新扫描一次。这也可以简化理解为无论引用关系删除与否都会按照刚刚开始扫描那一刻的对象图快照来进行搜索。
以上无论是对引用关系记录的插入还是删除虚拟机的记录操作都是通过写屏障实现的。在 HotSpot虚拟机中增量更新和原始快照这两种解决方案都有实际应用譬如CMS是基于增量更新来做并发标记的G1、Shenandoah则是用原始快照来实现。
垃圾收集算法
1、分代收集理论
当前商业虚拟机的垃圾收集器大多数都遵循了“分代收集”Generational Collection的理论进 行设计分代收集名为理论实质是一套符合大多数程序运行实际情况的经验法则它建立在两个分代假说之上
1弱分代假说Weak Generational Hypothesis绝大多数对象都是朝生夕灭的。2强分代假说Strong Generational Hypothesis熬过越多次垃圾收集过程的对象就越难以消亡
这两个分代假说共同奠定了多款常用的垃圾收集器的一致的设计原则收集器应该将Java堆划分出不同的区域然后将回收对象依据其年龄年龄即对象熬过垃圾收集过程的次数分配到不同的区域之中存储。显而易见如果一个区域中大多数对象都是朝生夕灭难以熬过垃圾收集过程的话那么把它们集中放在一起每次回收时只关注如何保留少量存活而不是去标记那些大量将要被回收的对象就能以较低代价回收到大量的空间如果剩下的都是难以消亡的对象那把它们集中放在一块虚拟机便可以使用较低的频率来回收这个区域这就同时兼顾了垃圾收集的时间开销和内存的空间有效利用。
设计者一般至少会把Java堆划分为新生代Young Generation和老年代Old Generation两个区域。顾名思义在新生代中每次垃圾收集时都发现有大批对象死去而每次回收后存活的少量对象将会逐步晋升到老年代中存放。
分代收集并非只是简单划分一下内存区域那么容易它至少存在一个明显的困难对象不是孤立的对象之间会存在跨代引用。假如要现在进行一次只局限于新生代区域内的收集Minor GC但新生代中的对象是完全有可能被老年代所引用的为了找出该区域中的存活对象不得不在固定的GC Roots之外再额外遍历整个老年代中所有对象来确保可达性分析结果的正确性反过来也是一样。遍历整个老年代所有对象的方案虽然理论上可行但无疑会为内存回收带来很大的性能负担。为了解决这个问题就需要对分代收集理论添加第三条经验法则 3 跨代引用假说 Intergenerational Reference Hypothesis 跨代引用相对于同代引用来说仅占极少数。
这其实是可根据前两条假说逻辑推理得出的隐含推论存在互相引用关系的两个对象是应该倾 向于同时生存或者同时消亡的。举个例子如果某个新生代对象存在跨代引用由于老年代对象难以消亡该引用会使得新生代对象在收集时同样得以存活进而在年龄增长之后晋升到老年代中这时跨代引用也随即被消除了。 依据这条假说我们就不应再为了少量的跨代引用去扫描整个老年代也不必浪费空间专门记录 每一个对象是否存在及存在哪些跨代引用只需在新生代上建立一个全局的数据结构该结构被称 为“记忆集”Remembered Set这个结构把老年代划分成若干小块标识出老年代的哪一块内存会存在跨代引用。此后当发生Minor GC时只有包含了跨代引用的小块内存里的对象才会被加入到GC Roots进行扫描。虽然这种方法需要在对象改变引用关系如将自己或者某个属性赋值时维护记录数据的正确性会增加一些运行时的开销但比起收集时扫描整个老年代来说仍然是划算的。
2、垃圾回收算法
标记-清除
标记所有需要清除的对象统一回收也可标记存活清理未标记效率不稳定内存空间碎片化
算法分为“标记”和“清除”两个阶段首先标记出所有需要回收的对象在标记完成后统一回收掉所有被标记的对象也可以反过来标记存活的对象统一回收所有未被标记的对象。标记过程就是对象是否属于垃圾的判定过程。 之所以说它是最基础的收集算法是因为后续的收集算法大多都是以标记-清除算法为基础对其 缺点进行改进而得到的。它的主要缺点有两个第一个是执行效率不稳定如果Java堆中包含大量对象而且其中大部分是需要被回收的这时必须进行大量标记和清除的动作导致标记和清除两个过程的执行效率都随对象数量增长而降低第二个是内存空间的碎片化问题标记、清除之后会产生大量不连续的内存碎片空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。 标记-复制
用一半留一半清理时复制存活到未用的一半清空另一半内存规整内存利用率低STW
标记-复制算法常被简称为复制算法。为了解决标记-清除算法面对大量可回收对象时执行效率低的问题1969年Fenichel提出了一种称为“半区复制”Semispace Copying的垃圾收集算法它将可用内存按容量划分为大小相等的两块每次只使用其中的一块。当这一块的内存用完了就将还存活着的对象复制到另外一块上面然后再把已使用过的内存空间一次清理掉。如果内存中多数对象都是存活的这种算法将会产生大量的内存间复制的开销但对于多数对象都是可回收的情况算法需要复制的就是占少数的存活对象而且每次都是针对整个半区进行内存回收分配内存时也就不用考虑有空间碎片的复杂情况只要移动堆顶指针按顺序分配即可。这样实现简单运行高效不过其缺陷也显而易见这种复制回收算法的代价是将可用内存缩小为了原来的一半空间浪费未免太多了一点。 用Java虚拟机大多都优先采用了这种收集算法去回收新生代把新生代分为一块较大的Eden空间和两块较小的Survivor空间每次分配内存只使用Eden和其中一块Survivor。发生垃圾搜集时将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor空间上然后直接清理掉Eden和已用过的那块Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1:1。如果另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象这些对象便将通过分配担保机制直接进入老年代
标记-整理
移动存货到一边边界线以外全部清除内存规整需要移动对象STW对象越多STW时间越长
针对老年代对象的存亡特征1974年Edward Lueders提出了另外一种有针对性的“标记-整理”Mark-Compact算法其中的标记过程仍然与“标记-清除”算法一样但后续步骤不是直接对可回收对象进行清理而是让所有存活的对象都向内存空间一端移动然后直接清理掉边界以外的内 存。 标记-清除算法与标记-整理算法的本质差异在于前者是一种非移动式的回收算法而后者是移动 式的。是否移动回收后的存活对象是一项优缺点并存的风险决策如果移动存活对象尤其是在老年代这种每次回收都有大量对象存活区域移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作而且这种对象移动操作必须全程暂停用户应用程序才能进行这就更加让使用者不得不小心翼翼地权衡其弊端了像这样的停顿被最初的虚拟机设计者形象地描述为“Stop The World”。
但如果跟标记-清除算法那样完全不考虑移动和整理存活对象的话弥散于堆中的存活对象导致的 空间碎片化问题就只能依赖更为复杂的内存分配器和内存访问器来解决。譬如通过“分区空闲分配链表”来解决内存分配问题。内存的访问是用户程序最频繁的操作甚至都没有之一假如在这个环节上增加了额外的负担势必会直接影响应用程序的吞吐量。
基于以上两点是否移动对象都存在弊端移动则内存回收时会更复杂不移动则内存分配时会 更复杂。从垃圾收集的停顿时间来看不移动对象停顿时间会更短甚至可以不需要停顿但是从整个程序的吞吐量来看移动对象会更划算。即使不移动对象会使得收集器的效率提升一些但因内存分配和访问相比垃圾收集频率要高得多这部分的耗时增加总吞吐量仍然是下降的。HotSpot虚拟机里面关注吞吐量的Parallel Scavenge收集器是基于标记-整理算法的而关注延迟的CMS收集器则是基于标记-清除算法的。
另外还有一种“和稀泥式”解决方案可以不在内存分配和访问上增加太大额外负担做法是让虚 拟机平时多数时间都采用标记-清除算法暂时容忍内存碎片的存在直到内存空间的碎片化程度已经大到影响对象分配时再采用标记-整理算法收集一次以获得规整的内存空间。前面提到的基于标记-清除算法的CMS收集器面临空间碎片过多时采用的就是这种处理办法。
CMSConcurrent Mark Sweep收集器
CMS (Concurrent Mark Sweep)是一种以最短停顿时间为目标的收集器使用CMS并不能达到GC效率最高总体GC时间最小)但它能尽可能降低GC时服务的停顿时间CMS收集器使用的是标记-清除算法。
CMS垃圾收集器步骤
1)初始标记(CMS initial mark) 暂停所有的其他线程(STW)。记录下 GC ROOT直接引用对象速度很快。
2)并发标记(CMS concurrent mark) 并发标记阶段就是从 GC ROOT行的直接关联对象开始遍历整个对象的过程这个过程耗时比较长但是不需要停顿用户线程可以与垃圾收集器一起并发运行。因此用户程序继续运行,可能会导致已经标记过的对象状态发生变化。
3)重新标记(CMS remark) 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。这个阶段的停顿时间一般比初始标记阶段的时间稍长远远比并发标记阶段时间短。主要是用到三色标记里的增量更新算法
4并发清除CMS concurrent sweep) 开启用户线程同时GC线程开始对未标记的区域做清扫这个阶段如果有新增对象会被标记为黑色不做任何处理。
5)并发重置 重置本次GC过程中标记数据。 CMS垃圾收集器优缺点
从它的名字可以看出他是一款优秀的垃圾收集器主要优点∶并发收集、低停顿。但是它有以下几个明显的缺点:
对于CPU资源敏感会和服务抢资源);无法处理浮动垃圾在并发标记和并发清理阶段又产生垃圾这种浮动垃圾只能等到下次gc的时候在进行清理了)由于在垃圾收集阶段用户线程还需要持续运行那就还需要预留足够内存空间提供给用户线程使用因此CMS收集器不能像其他收集器那样等待到老年代几乎完全被填满了再进行收集必须预留一部分空间供并发收集时的程序运作使用。在JDK5的默认设置下CMS收集器当老年代使用了68%的空间后就会被激活这是一个偏保守的设置,到了JDK 6时CMS收集器的启动阈值就已经默认提升至92%。但这又会更容易面临另一种风险要是CMS运行期间预留的内存无法满足程序分配新对象的需要就会出现一次“并发失败”Concurrent Mode Failure这时候虚拟机将不得不启动后备预案冻结用户线程的执行临时启用Serial Old收集器来重新进行老年代的垃圾收集但这样停顿时间就很长了。所以参数-XXCMSInitiatingOccupancyFraction设置得太高将会很容易导致大量的并发失败产生性能反而降低用户应在生产环境中根据实际应用情况来权衡设置。它使用的收集算法“标记-清除”算法会导致结束时候又大量空间碎片产生当然通过参数–XX:UseCMSCompactAtFullCollection可以让JVM在执行标记清除完成后再做整理。空间碎片过多时将会给大对象分配带来很大麻烦往往会出现老年代还有很多剩余空间但就是无法找到足够大的连续空间来分配当前对象而不得不提前触发一次Full GC的情况。在CMS收集器不得不进行Full GC时开启内存碎片的合并整理过程由于这个内存整理必须移动存活对象是无法并发的。这样空间碎片问题是解决了但停顿时间又会变长因此虚拟机设计者们还提供了另外一个参数-XXCMSFullGCsBefore-Compaction此参数从JDK 9开始废弃这个参数的作用是要求CMS收集器在执行过若干次数量由参数值决定不整理空间的Full GC之后下一次进入Full GC前会先进行碎片整理默认值为0表示每次进入Full GC时都进行碎片整理。
