永康网站网站建设,石家庄网站搭建定制,微信 wordpress 群发,网站建设-猴王网络本文从几种JVM垃圾回收方式及原理出发#xff0c;研究了在 SPEC jbb2015基准测试中不同垃圾回收方式对于JVM 性能的影响#xff0c;并通过最终测试数据对比#xff0c;给出了不同应用场景下如何选择垃圾回收策略的方法。 目录
3 几种垃圾回收器
3.1 串行回收器
3.2 并行回… 本文从几种JVM垃圾回收方式及原理出发研究了在 SPEC jbb2015基准测试中不同垃圾回收方式对于JVM 性能的影响并通过最终测试数据对比给出了不同应用场景下如何选择垃圾回收策略的方法。 目录
3 几种垃圾回收器
3.1 串行回收器
3.2 并行回收器
3.3 CMS回收器
3.4 G1回收器
3.5 Z回收器
4 垃圾回收器性能比较 3 几种垃圾回收器
垃圾收集算法可以看作 Java 虚拟机内存回收的抽象策略而垃圾收集器则是其内存回收的具体实现。Java 虚拟机中垃圾回收器不只一种在不同的应用场景下如何选择性能最佳的垃圾回收器 是需要有清楚认识的下面介绍几种常见的垃圾回收器。
3.1 串行回收器
串行回收器是一种单线程垃圾回收器在进行每次垃圾回收时只有一个线程工作Java 应用程序中的其他所有线程暂停等待垃圾回收完成“Stop-The-World”过程。在实时性要求高的应用 场景下往往会造成用户体验不佳。串行回收器在新生代中使用复制算法老年代中使用标记压缩法。
3.2 并行回收器
并行回收器在串行回收器的基础上做了改进它使用多个线程同时进行垃圾回收可以有效减少垃圾回收所需的时间。新生代中使用复制算法老年代使用标记压缩算法。并行回收器关注系统的吞吐量可以通过 -XX:MaxGCPauseMills 和 -XX:GCTimeRatio 控制的垃圾回收最大停顿时间和吞吐量。但须指出的是减少一次收集的最大停顿时间就会同时减少系统吞吐量增大系统吞吐量又可能会同时增加一次垃圾回收的最大停顿时间。
3.3 CMS回收器
CMS回收器使用标记清除算法利用多线程并行回收侧重于系统停顿时间。CMS工作时首先经过初始标记与并发标记来标记出需要回收的对象、通过预清理做清理前的准备及控制停顿时间、再经过重新标记修正并发标记的数据、最后进行并发清除以及并发重置为下次回收做准备 。
3.4 G1回收器
G1 回收器可以视为 CMS 回收器的替代品它使用了独特的分区算法相比于之前介绍的垃圾回收器将堆内存划分为固定内存大小的年轻代、老代和永久代JDK1.8 后被元空间取代G1 回收器将堆分割成一组大小相等的区域每个区域是一个连续的虚拟内存范围某些区域被功能与年轻代老年代相同但是它们没有固定的大小这为内存使用提供了更大的灵活性。在进行垃圾回收时 G1 回收器可以只选择部分区域且部分垃圾回收工作能与 Java 应 用程序并行提高回收效率的同时相应降低停顿时间。G1 回收器虽然也使用标记清除法但与 CMS 不同的是 G1 可以有效复制移动对象消除了潜在的内存碎片问题。此外G1 还允许用户自行设定所需的暂停时间。
3.5 Z回收器
ZGC 是从 JDK11 中引入的一种新的支持弹性伸缩的低延迟垃圾收集器主要实现了三大目标停顿时间不超过 10ms、停顿时间不随堆或实时设置的大小而增加、支持从 8MB 到 16TB 的堆内存。ZGC的一个核心设计原则是使用读屏障load barrier和着色指针 colored pointer。在 Java 中加载对象的行为会受到读屏障的影响而着色指针具有供读屏障使用的信息它使 ZGC 能够查找、标记、定位和重新映射对象这有助于降低垃圾回收的开销并极大降低停顿时间且对吞吐量影响最大不超过 15%。作为一个并发的垃圾收集器ZGC 所有的工作都是在 Java 应用程序线程执行时完成的这极大地减少了垃圾回收对应用程序响应时间的影响。而且 Z 回收器现在还处于持续开发阶段后续的开发目标是达到垃圾回收停顿时间不超过 1ms。
4 垃圾回收器性能比较
SPEC jbb2015 测试模拟了一个典型的商业应用的三层架构环境 中的中间层工作包含商业逻辑、对象操作等目的是衡量服务器 Java 应用之性能。模型建立在一个全球型连锁超市的 IT 基础架构 之上通过线上线下购物、库存管理、供应链管理、用户购买行为的数据挖掘等业务来评估整个系统的吞吐量及响应时间随着整个系统业务量不断增加时的性能表现。SPECjbb2015 支持多种测试运行配置、支持虚拟化以及云环境使用户能够全面分析和解决可能 存在于包括硬件、操作系统、JVM 和应用程序层的性能瓶颈问题。
SPEC jbb2015 测试结果包含主要包含两个测试指标 Max-jOPS 和 Critical-jOPS。最大性能指标 Max-jOPS 是系统最大每秒钟处理的 Java 操作数可以看做在业务响应不失败的情况下服务器 的极限吞吐量反映的是系统极限 Java 应用性能。关键性能指标 Critical-jOPS 是系统在 5 个关键 SLA服务水平协议10ms 25ms50ms75ms 和 100ms 响应时间下平均每秒 Java 操作数。选择这些点是为了保证不同行业使用的响应时间目标的合理分布可以看做衡量的是在响应时间有限的情况下的系统吞吐量。
