网站如何运作,网站建设需要些什么,域名备案系统,想做国外的客户做网站怎么弄2019独角兽企业重金招聘Python工程师标准 如果说收集算法是内存回收的方法论#xff0c;那么垃圾收集器就是内存回收的具体实现。 Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定#xff0c;因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可… 2019独角兽企业重金招聘Python工程师标准 如果说收集算法是内存回收的方法论那么垃圾收集器就是内存回收的具体实现。 Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大差别并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。 HotSpot虚拟机的垃圾回收器 图中展示了7种作用于不同分代的收集器如果两个收集器之间存在连线就说明它们可以搭配使用。虚拟机所处的区域则表示它是属于新生代收集器还是老年代收集器。 概念理解 并发和并行 这两个名词都是并发编程中的概念在谈论垃圾收集器的上下文语境中它们可以解释如下。 并行Parallel指多条垃圾收集线程并行工作但此时用户线程仍然处于等待状态。 并发Concurrent指用户线程与垃圾收集线程同时执行但不一定是并行的可能会交替执行用户程序在继续运行而垃圾收集程序运行于另一个CPU上。 Minor GC 和 Full GC 新生代GCMinor GC指发生在新生代的垃圾收集动作因为Java对象大多都具备朝生夕灭的特性所以Minor GC非常频繁一般回收速度也比较快。 老年代GCMajor GC / Full GC指发生在老年代的GC出现了Major GC经常会伴随至少一次的Minor GC但非绝对的在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程。Major GC的速度一般会比Minor GC慢10倍以上。 吞吐量 吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值即吞吐量 运行用户代码时间 /运行用户代码时间 垃圾收集时间。 虚拟机总共运行了100分钟其中垃圾收集花掉1分钟那吞吐量就是99%。 一、Serial收集器 Serial收集器是最基本、发展历史最悠久的收集器曾经在JDK 1.3.1之前是虚拟机新生代收集的唯一选择。 特性 这个收集器是一个单线程的收集器但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作更重要的是在它进行垃圾收集时必须暂停其他所有的工作线程直到它收集结束。Stop The World 应用场景 Serial收集器是虚拟机运行在Client模式下的默认新生代收集器。 优势 简单而高效与其他收集器的单线程比对于限定单个CPU的环境来说Serial收集器由于没有线程交互的开销专心做垃圾收集自然可以获得最高的单线程收集效率。 二、ParNew收集器 特性 ParNew收集器其实就是Serial收集器的多线程版本除了使用多条线程进行垃圾收集之外其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样在实现上这两种收集器也共用了相当多的代码。 应用场景 ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器。 很重要的原因是除了Serial收集器外目前只有它能与CMS收集器配合工作。 在JDK 1.5时期HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器——CMS收集器这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器它第一次实现了让垃圾收集线程与用户线程同时工作。 不幸的是CMS作为老年代的收集器却无法与JDK 1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作所以在JDK 1.5中使用CMS来收集老年代的时候新生代只能选择ParNew或者Serial收集器中的一个。 Serial收集器 VS ParNew收集器 ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果甚至由于存在线程交互的开销该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证可以超越Serial收集器。 然而随着可以使用的CPU的数量的增加它对于GC时系统资源的有效利用还是很有好处的。 三、Parallel Scavenge收集器 特性 Parallel Scavenge收集器是一个新生代收集器它也是使用复制算法的收集器又是并行的多线程收集器。 应用场景 停顿时间越短就越适合需要与用户交互的程序良好的响应速度能提升用户体验而高吞吐量则可以高效率地利用CPU时间尽快完成程序的运算任务主要适合在后台运算而不需要太多交互的任务。 对比分析 Parallel Scavenge收集器 VS CMS等收集器 Parallel Scavenge收集器的特点是它的关注点与其他收集器不同CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量Throughput。 由于与吞吐量关系密切Parallel Scavenge收集器也经常称为“吞吐量优先”收集器。 Parallel Scavenge收集器 VS ParNew收集器 Parallel Scavenge收集器与ParNew收集器的一个重要区别是它具有自适应调节策略。 GC自适应的调节策略 Parallel Scavenge收集器有一个参数-XX:UseAdaptiveSizePolicy。当这个参数打开之后就不需要手工指定新生代的大小、Eden与Survivor区的比例、晋升老年代对象年龄等细节参数了虚拟机会根据当前系统的运行情况收集性能监控信息动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量这种调节方式称为GC自适应的调节策略GC Ergonomics。 四、Serial Old收集器 特性 Serial Old是Serial收集器的老年代版本它同样是一个单线程收集器使用标记整理算法。 应用场景 Client模式 Serial Old收集器的主要意义也是在于给Client模式下的虚拟机使用。 Server模式 如果在Server模式下那么它主要还有两大用途一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge收集器搭配使用另一种用途就是作为CMS收集器的后备预案在并发收集发生Concurrent Mode Failure时使用。 五、Parallel Old收集器 特性 Parallel Old是Parallel Scavenge收集器的老年代版本使用多线程和“标记整理”算法。 应用场景 在注重吞吐量以及CPU资源敏感的场合都可以优先考虑Parallel Scavenge加Parallel Old收集器。 这个收集器是在JDK 1.6中才开始提供的在此之前新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是如果新生代选择了Parallel Scavenge收集器老年代除了Serial Old收集器外别无选择Parallel Scavenge收集器无法与CMS收集器配合工作。由于老年代Serial Old收集器在服务端应用性能上的“拖累”使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力在老年代很大而且硬件比较高级的环境中这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。直到Parallel Old收集器出现后“吞吐量优先”收集器终于有了比较名副其实的应用组合。 六、CMS收集器 特性 CMSConcurrent Mark Sweep收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上这类应用尤其重视服务的响应速度希望系统停顿时间最短以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。 CMS收集器是基于“标记—清除”算法实现的它的运作过程相对于前面几种收集器来说更复杂一些整个过程分为4个步骤 初始标记CMS initial mark 初始标记仅仅只是标记一下GC Roots能直接关联到的对象速度很快需要“Stop The World”。 并发标记CMS concurrent mark 并发标记阶段就是进行GC Roots Tracing的过程。 重新标记CMS remark 重新标记阶段是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录这个阶段的停顿时间一般会比初始标记阶段稍长一些但远比并发标记的时间短仍然需要“Stop The World”。 并发清除CMS concurrent sweep 并发清除阶段会清除对象。 由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作所以从总体上来说CMS收集器的内存回收过程是与用户线程一起并发执行的。 优点 CMS是一款优秀的收集器它的主要优点在名字上已经体现出来了并发收集、低停顿。 缺点 CMS收集器对CPU资源非常敏感 其实面向并发设计的程序都对CPU资源比较敏感。在并发阶段它虽然不会导致用户线程停顿但是会因为占用了一部分线程或者说CPU资源而导致应用程序变慢总吞吐量会降低。 CMS默认启动的回收线程数是CPU数量3/ 4也就是当CPU在4个以上时并发回收时垃圾收集线程不少于25%的CPU资源并且随着CPU数量的增加而下降。但是当CPU不足4个譬如2个时CMS对用户程序的影响就可能变得很大。 CMS收集器无法处理浮动垃圾 CMS收集器无法处理浮动垃圾可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。 由于CMS并发清理阶段用户线程还在运行着伴随程序运行自然就还会有新的垃圾不断产生这一部分垃圾出现在标记过程之后CMS无法在当次收集中处理掉它们只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。 也是由于在垃圾收集阶段用户线程还需要运行那也就还需要预留有足够的内存空间给用户线程使用因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集需要预留一部分空间提供并发收集时的程序运作使用。要是CMS运行期间预留的内存无法满足程序需要就会出现一次“Concurrent Mode Failure”失败这时虚拟机将启动后备预案临时启用Serial Old收集器来重新进行老年代的垃圾收集这样停顿时间就很长了。 CMS收集器会产生大量空间碎片 CMS是一款基于“标记—清除”算法实现的收集器这意味着收集结束时会有大量空间碎片产生。 空间碎片过多时将会给大对象分配带来很大麻烦往往会出现老年代还有很大空间剩余但是无法找到足够大的连续空间来分配当前对象不得不提前触发一次Full GC。 七、G1收集器 特性 G1Garbage-First是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是未来可以替换掉JDK 1.5中发布的CMS收集器。与其他GC收集器相比G1具备如下特点。 并行与并发 G1能充分利用多CPU、多核环境下的硬件优势使用多个CPU来缩短Stop-The-World停顿的时间部分其他收集器原本需要停顿Java线程执行的GC动作G1收集器仍然可以通过并发的方式让Java程序继续执行。 分代收集 与其他收集器一样分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。 空间整合 与CMS的“标记—清理”算法不同G1从整体来看是基于“标记—整理”算法实现的收集器从局部两个Region之间上来看是基于“复制”算法实现的但无论如何这两种算法都意味着G1运作期间不会产生内存空间碎片收集后能提供规整的可用内存。这种特性有利于程序长时间运行分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。 可预测的停顿 这是G1相对于CMS的另一大优势降低停顿时间是G1和CMS共同的关注点但G1除了追求低停顿外还能建立可预测的停顿时间模型能让使用者明确指定在一个长度为M毫秒的时间片段内消耗在垃圾收集上的时间不得超过N毫秒。 在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代而G1不再是这样。使用G1收集器时Java堆的内存布局就与其他收集器有很大差别它将整个Java堆划分为多个大小相等的独立区域Region虽然还保留有新生代和老年代的概念但新生代和老年代不再是物理隔离的了它们都是一部分Region不需要连续的集合。 G1收集器之所以能建立可预测的停顿时间模型是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小回收所获得的空间大小以及回收所需时间的经验值在后台维护一个优先列表每次根据允许的收集时间优先回收价值最大的Region这也就是Garbage-First名称的来由。这种使用Region划分内存空间以及有优先级的区域回收方式保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。 执行过程 G1收集器的运作大致可划分为以下几个步骤 初始标记Initial Marking 初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象并且修改TAMSNext Top at Mark Start的值让下一阶段用户程序并发运行时能在正确可用的Region中创建新对象这阶段需要停顿线程但耗时很短。 并发标记Concurrent Marking 并发标记阶段是从GC Root开始对堆中对象进行可达性分析找出存活的对象这阶段耗时较长但可与用户程序并发执行。 最终标记Final Marking 最终标记阶段是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中这阶段需要停顿线程但是可并行执行。 筛选回收Live Data Counting and Evacuation 筛选回收阶段首先对各个Region的回收价值和成本进行排序根据用户所期望的GC停顿时间来制定回收计划这个阶段其实也可以做到与用户程序一起并发执行但是因为只回收一部分Region时间是用户可控制的而且停顿用户线程将大幅提高收集效率。 八、总结 虽然我们是在对各个收集器进行比较但并非为了挑选出一个最好的收集器。因为直到现在为止还没有最好的收集器出现更加没有万能的收集器所以我们选择的只是对具体应用最合适的收集器。这点不需要多加解释就能证明如果有一种放之四海皆准、任何场景下都适用的完美收集器存在那HotSpot虚拟机就没必要实现那么多不同的收集器了。 转载于:https://my.oschina.net/gordonnemo/blog/3028955
