网站开发+搜索,河北省承德市兴隆县建设局网站,专业团队p图,福州网站建设加q479185700目录
一、Serial收集器
二、ParNew收集器
三、Paralle Scavenge
四、Serial Old
五、Parallel Old
六、CMS收集器 6.1 CMS对处理器资源非常敏感 6.2 CMS容易出现浮动垃圾 6.3 产生内存碎片
七、G1 收集器
八、如何选择合适的垃圾收集器 JVM 垃圾收集器是Java虚…
目录
一、Serial收集器
二、ParNew收集器
三、Paralle Scavenge
四、Serial Old
五、Parallel Old
六、CMS收集器 6.1 CMS对处理器资源非常敏感 6.2 CMS容易出现浮动垃圾 6.3 产生内存碎片
七、G1 收集器
八、如何选择合适的垃圾收集器 JVM 垃圾收集器是Java虚拟机JVM中至关重要的组件负责自动管理程序运行时产生的内存分配与回收。垃圾收集器通过检测并回收堆内存中不再使用的对象从而保证了 Java 应用程序在持续运行过程中拥有足够的内存空间。 如果说收集算法是内存回收的方法论那垃圾收集器就是内存回收的实践者。各款经典的收集器之间的关系如下图如果两个收集器之间存在连线就说明他们可以搭配使用收集器所处的区域则表示它是属于新生代还是老年代。 一、Serial收集器 Serial 收集器是最基础、历史最悠久的收集器这个收集器是单线程工作的收集器他的“单线程”意义并不仅仅是说明它只会是有一个处理器或一条收集器线程去完成垃圾收集工作更重要的是强调它在垃圾收集时必须暂停其他所有工作线程直到它收集结束。 Serial 收集器依然是 HotSpot 虚拟机运行在客户端模式下的默认新生代收集器有着优于其他收集器的地方那就是简单而高效对于内存资源受限的环境他是所有收集器里额外内存消耗最小的。 对于单核处理器或处理器核心数较少的环境来说Serial 收集器由于没有线程交互的开销专心做垃圾收集自然可以获得最高单线程收集效率。近年来流行的微服务应用中分配给虚拟机的内存一般来说并不大收集十兆甚至几百兆的新生代垃圾收集的停顿时间完全可以控制在十几、几十毫秒内只要不是频繁发生收集是可以接受的。
二、ParNew收集器 ParNew 收集器实质上是 Serial 收集器多线程的并行版本除了同时使用多线程进行垃圾收集外其余的行为包括 Serial 收集器可用的所有控制参数都与 Serial 完全一致。 ParNew 除了支持多线程并行收集外其他与 Serial 收集器相比没有太多创新除了 Serial收集器外目前只有它能与 CMS 收集器配合工作。 CMS 收集器是 HotSpot 虚拟机中第一款真正意义上支持并发的垃圾收集器他首次实现了让垃圾收集线程和用户线程同时工作。
三、Paralle Scavenge Paralle Scavenge 收集器也是一款新生代收集器它同样是基于标记-复制算法实现的收集器也是能够并行收集的多线程收集器。 Paralle Scavenge 收集器的特点是它的关注点与其他收集器不同CMS 等收集器关注点是尽可能缩短垃圾收集时用户线程的停顿时间而 Paralle Scavenge 收集器的目标则是达到一个可控的吞吐量。所谓吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值即 Paralle Scavenge 提供了参数来用于精确控制吞吐量被称为是吞吐量优先处理器。默认吞吐量的值为 99即允许最大 1% 的垃圾回收时间。
四、Serial Old Serial Old 是 Serial 收集器老年代版本他同样是一款单线程收集器使用标记-整理算法。 五、Parallel Old Parallel Old 是 Parallel Scavenge 收集器的老年代版本支持多线程并发收集基于标记-整理算法。
六、CMS收集器 CMSConcurrent Mark Sweep收集器是一种以获取最短停顿时间为目标的收集器。从名字可以看出 CMS 是基于标记清除算法实现的。整个过程分为四个步骤
初始标记初始标记仅仅只是标记一下 GC Roots 能直接关联到的对象速度很快。并发标记并发标记阶段就是从 GC Roots 的直接关联对象开始遍历整个对象的过程这个过程耗时较长但不需要停顿用户线程可以与垃圾收集线程一起并发运行。重新标记是为了修正并发标记期间因为用户继续运作而导致标记产生变动的那一部分对象的标记记录。并发清除清理删除掉标记阶段判断的已经死亡的对象由于不需要移动存活对象所以整个阶段也是可以与用户线程同时并发。 由于整个过程中耗时最长的并发标记与并发清除中垃圾收集线程都可以与用户线程一起工作所以从整体上看CMS 收集器的内存回收过程与用户线程一起并发执行。 但是 CMS 也有一些明显的缺点 6.1 CMS对处理器资源非常敏感 事实上面向并发设计的程序都对处理器资源比较敏感。在并发阶段它虽然不会导致用户线程停顿但却会因为占用了一部分线程而导致应用程序变慢降低吞吐量。CMS 默认启动的回收线程数是处理器核心数量 3/ 4。也就是说如果处理器核心数在4个以上并发回收时垃圾回收线程只占用不超过 25% 的处理器运算资源。但是如果处理器核心不足4个时CMS对用户程序的影响就可能变得很大。如果应用的负载本来很高还要分出一半的运算能力去执行垃圾回收可能导致用户程序的执行速度大幅降低。为了缓解这种情况虚拟机提出了“增量式并发收集器 i-CMS”在并发标记、清理的时候让收集器线程、用户线程抢占式交替运行尽量减少收集线程的独占资源时间虽然垃圾收集时间会变成长但对用户影响小一些。实践证明这种方式效果很一般在jdk7开始i-CMS标记为过时不提倡使用。 6.2 CMS容易出现浮动垃圾 有可能出现“Concurrent Mode Dailure”失败而导致另一次完全“stop the word”的 Full GC 的产生。在 CMS 的并发标记和并发清理阶段用户线程还在继续进行程序在运行自然就还会伴随着垃圾对象的不断产生但这一部分垃圾对象是出现在标记过程结束以后CMS 无法清理掉它们之后等到下一次清理这部分垃圾被称为浮动垃圾。 同样也是由于在垃圾收集期间用户线程还需要持续运行那就还需要预留足够内存空间提供给用户线程因此 CMS 收集器不能像其他收集器那样等待老年代几乎快被填满了在进行垃圾收集必须预留一部分空间供并行收集时程序运行使用。在JDK5的默认配置下CMS收集器老年代使用68%的空间后会被激活。到JDK6提升到92%。 6.3 产生内存碎片 基于标记清除算法实现会产生大量内存碎片。往往会出现老年代还有很多空间但就是无法找到连续空间分配给当前对象而不得不提前触发一次 Full GC。
七、G1 收集器 Garbage First 简称 G1 收集器是一款主要面向服务端的垃圾收集器最初赋予他的期望是未来可以替换掉 JDK5 中发布的 CMS 收集器。JDK9 发布之日G1 宣告取代 Parrallel Scavenge和 Parrallel Old 组合成为服务端模式下默认垃圾收集器。而 CMS 沦落为不被推荐使用的收集器。 它开创了收集器面向局部收集的设计思路和基于 Region 的内存布局形式。在 G1 收集器出现之前的所有收集器包括 CMS 在内垃圾收集器的目标范围要么是整个新生代(Minor GC)要么就是整个老年代(Major GC)要么就是整个 Java 堆(Full GC)。而 G1 跳出了这个樊笼它可以面向堆内存任何部分来组成回收集进行回收衡量的标准不再是它属于哪个分代而是哪块内存中存放的垃圾数量最多回收收益最大这就是 G1 收集器的 Mixed GC 模式。 G1 不在坚持固定大小以及固定数量的分代区域划分而是把连续的 Java 堆划分为多个大小相等的独立区域Region每个 Region 都可以根据需要扮演新生代的 Eden 空间、Survior空间或者老年代空间。收集器能够扮演不同角色的 Region 采用不同的策略去处理。Region 中还有一类 Hunongous 区域专门用来存储大对象。G1 认为只有大小超过了一个 Region 容量一半的对象即可判定为大对象。每个 Region 的大小可以通过参数设定。 虽然 G1 仍然保留新生代和老年代的概念但新生代和老年代不再是固定的他们都是一系列区域的动态集合。G1 之所以能够建立可预测的停顿时间模型是因为它将 Region 作为最小的回收单元即每次收集到的内存空间都是 Region 大小的整数倍。更具体的处理思路是让 G1 去跟踪各个 Region 里面垃圾堆积的“价值”大小价值即回收所获得的空间大小以及回收所需的时间的经验值然后在后台维护一个优先级列表每次根据用户设定的停顿时间优先处理回收价值最大的那些 Region这也是 Garbage First 名字的由来。 G1 主要划分为以下四个步骤
初始标记仅仅只是标记一下 GC Roots 能直接关联到的对象并发标记从 GC Roots 开始对堆中对象进行可达性分析递归整个堆里的对象图找出要回收的对象最终标记对用户线程做另一个短暂的暂停用于处理并发阶段结束后仍遗留下来的数据。筛选回收负责更新 Region 的统计数据对各个 Region 的回收价值和成本进行排序根据用户所期望的停顿时间来指定回收计划。因为涉及到存活对象的移动所以是必须要暂停用户线程的。 G1 从整体看使用了标记-整理算法避免了 CMS 标记清除产生的内存空间碎片垃圾收集完成后能提供规整的可用内存。不过G1 相比 CMS 也有缺点G1 无论是为了垃圾收集产生的内存占用还是程序运行时额外执行负载都比 CMS 要高。 就内存而言虽然 G1 和 CMS 都使用卡表来处理跨代指针但 G1 的卡表实现更为复杂而且堆中每个 Region无论扮演的是新生代还是老年代角色都必须有一份卡表这导致 G1 的记忆集占用更多的内存。
八、如何选择合适的垃圾收集器 衡量垃圾收集器的三项重要指标是内存占用、吞吐量和延迟。 除了以上介绍的垃圾收集器还有些比较新的垃圾收集器如ZGC、Epsilon收集器有十多种收集器那么该如何选择呢主要从这3点考虑
应用程序的主要关注点是什么如果是数据分析、科学计算类的任务目标是能尽快算出结果那吞吐量就是主要的关注点如果是 SLA 应用那停顿时间直接影响服务质量严重的甚至导致事务超时这样延迟就是主要关注点而如果是客户端或者嵌入式应用那垃圾收集的内存占用则是不可忽视的。运行应用的基础设施如何譬如硬件规格要设计系统架构处理器的数量是多少分配内存大小选择的操作系统是 Linux、Solaris 还是 Windows 等。使用JDK的发行商是什么版本号是多少 选择垃圾收集器时还需要进行基准测试和监控以确定哪种收集器在实际运行环境中性能最佳。可以根据应用程序的实际内存分配和回收情况、CPU 利用率、响应时间和吞吐量指标等进行评估和调整。在生产环境中还可以通过 JMX 或者其他监控工具实时监控垃圾收集器的表现以便进行调优。 往期经典推荐
JVM 垃圾回收机制探秘对象生死判定与高效回收算法-CSDN博客
JVM内存模型深度解读-CSDN博客
Spring循环依赖的成因与破局-CSDN博客
Spring Cloud Nacos 引领服务治理新航向-CSDN博客
揭秘Redis中AOF与RDB的协同作战确保数据万无一失-CSDN博客
