JVM(2)不同的垃圾回收器的比较

9 篇文章 0 订阅

4款Java垃圾回收器——错误的选择导致糟糕的性能

1.   -XX:+UseSerialGC   串行回收器

面向单线程环境的(比如说32位的或者Windows)以及比较小的堆。这个回收器工作的时候会将所有应用线程全部冻结,就这一点而言就使得它完全不可能会被服务端应用所采用。

2.并行/吞吐量回收器

下一个是并行回收器( Parallel collector)。这是JVM的默认回收器。优点就是它使用多个线程来扫描及压缩堆。它的缺点就是不管执行的是minor GC还是full GC它都会暂停应用线程。并行回收器最适合那些可以容许暂停的应用,它试图减少由回收器所引起的CPU开销。

3.CMS回收器

并行回收器之后就是CMS回收器了(concurrent-mark-sweep)。这个算法使用了多个线程(concurrent)来扫描堆并标记(mark)那些不再使用的可以回收(sweep)的对象。这个算法在两种情况下会进入一个”stop the world”的模式:当进行根对象的初始标记的时候 (老生代中线程入口点或静态变量可达的那些对象)以及当这个算法在并发运行的时候应用程序改变了堆的状态使得它不得不回去再次确认自己标记的对象都是正确的。

使用这个回收器最大的问题就是会碰到promotion failure,这是指在回收新生代及年老代时出现了竞争条件的情况。如果回收器需要将年轻的对象提升到年老代中,而这个时候年老代没有多余的空间了,它就只能先进行一次STW(Stop The World)的full GC了——这种情况正是CMS所希望避免的。为了确保这种情况不会发生,你要么就是增加老生代的大小(或者增加整个堆的大小),要么就是给回收器分配一些后台线程以便与对象分配的速度进行赛跑。

这个算法的另一个缺点就是和并行回收器相比,它使用的CPU资源会更多,它使用了多个线程来执行扫描和回收,这样才能让应用持续提供更高级别的吞吐量。对于大多数长期运行的程序而言,应用的暂停对它们是很不利的,这个时候可以考虑使用CMS回收器。尽管如此,这个算法也不是默认开启的。你得指定XX:+UseConcMarkSweepGC来启用它。假设你的堆小于4G,而你又希望分配更多的CPU资源以避免应用暂停,那么这就是你要选择的回收器。然而,如果堆大于4G的话,你可能更希望使用最后的这个——G1回收器。

4.G1回收器

G1( Garbage first)回收器在JDK 7update 4中首次引入,它的设计目标是能更好地支持大于4GB的堆。G1回收器将堆分为多个区域,大小从1MB到32MB不等,并使用多个后台线程来扫描它们。G1回收器会优先扫描那些包含垃圾最多的区域,这正是它的名字的由来(Garbage first)。这个回收器可以通过-XX:UseG1GC标记来启用。

这一策略减少了后台线程还未扫描完无用对象前堆就已经用光的可能性,而那种情况回收器就必须得暂停应用,这就会导致STW回收。G1的另一个好处就是它总是会进行堆的压缩,而CMS回收器只有在full GC的时候才会干这事。

过去几年里,大堆一直都是一个充满争议的领域,很多开发人员从单机器单JVM模型转向了单机器多JVM的微服务,组件化的架构。这是许多因素所驱动的,包括隔离程序的组件,简化部署,避免重新加载应用类到内存所产生的开销(Java 8中这点已经得到了改善)。

尽管如此,这么做最主要还是希望能避免大堆的GC中长时期的”stop the world”的暂停(在一次大的回收中需要花费数秒才能完成)。像Docker这样的容器技术也加速了这一进程,它们使得你可以很轻松地在同一台物理机上部署多个应用。

Java 8及G1回收器

Java 8 update 20所引入的一个很棒的优化就是G1回收器中的字符串去重(String deduplication)。由于字符串(包括它们内部的char[]数组)占用了大多数的堆空间,这项新的优化旨在使得G1回收器能识别出堆中那些重复出现的字符串并将它们指向同一个内部的char[]数组,以避免同一个字符串的多份拷贝,那样堆的使用效率会变得很低。你可以使用-XX:+UseStringDeduplication这个JVM参数来试一下这个特性。

Java 8及持久代

Java 8中最大的改变就是持久代的移除,它原本是用来给类元数据,驻留字符串,静态变量来分配空间的。这在以前都是需要开发人员来针对那些会加载大量类的应用来专门进行堆比例的优化及调整。许多年来都是如此,这也正是许多OutOfMemory异常的根源,因此由JVM来接管它真是再好不过了。即便如此,它本身并不会减少开发人员将应用解耦到不同的JVM中的可能性。

每个回收器都有许多不同的开关和选项来进行调优,这可能会增加吞吐量,也可能会减少,这取决于你的应用的具体的行为了。在下一篇文章中我们会深入讲解配置这些算法的关键策略。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
前 言   致 谢   第一部分 走近Java   第1章 走近Java / 2   1.1 概述 / 2   1.2 Java技术体系 / 3   1.3 Java发展史 / 5   1.4 展望Java技术的未来 / 9   1.4.1 模块化 / 9   1.4.2 混合语言 / 9   1.4.3 多核并行 / 11   1.4.4 进一步丰富语法 / 12   1.4.5 64位虚拟机 / 13   1.5 实战:自己编译JDK / 13   1.5.1 获取JDK源码 / 13   1.5.2 系统需求 / 14   1.5.3 构建编译环境 / 15   1.5.4 准备依赖项 / 17   1.5.5 进行编译 / 18   1.6 本章小结 / 21   第二部分 自动内存管理机制   第2章 Java内存区域与内存溢出异常 / 24   2.1 概述 / 24   2.2 运行时数据区域 / 25   2.2.1 程序计数 / 25   2.2.2 Java虚拟机栈 / 26   2.2.3 本地方法栈 / 27   2.2.4 Java堆 / 27   2.2.5 方法区 / 28   2.2.6 运行时常量池 / 29   2.2.7 直接内存 / 29   2.3 对象访问 / 30   2.4 实战:OutOfMemoryError异常 / 32   2.4.1 Java堆溢出 / 32   2.4.2 虚拟机栈和本地方法栈溢出 / 35   2.4.3 运行时常量池溢出 / 38   2.4.4 方法区溢出 / 39   2.4.5 本机直接内存溢出 / 41   2.5 本章小结 / 42   第3章 垃圾收集与内存分配策略 / 43   3.1 概述 / 43   3.2 对象已死? / 44   3.2.1 引用计数算法 / 44   3.2.2 根搜索算法 / 46   3.2.3 再谈引用 / 47   3.2.4 生存还是死亡? / 48   3.2.5 回收方法区 / 50   3.3 垃圾收集算法 / 51   3.3.1 标记 -清除算法 / 51   3.3.2 复制算法 / 52   3.3.3 标记-整理算法 / 54   3.3.4 分代收集算法 / 54   3.4 垃圾收集 / 55   3.4.1 Serial收集 / 56   3.4.2 ParNew收集 / 57   3.4.3 Parallel Scavenge收集 / 59   3.4.4 Serial Old收集 / 60   3.4.5 Parallel Old收集 / 61   3.4.6 CMS收集 / 61   3.4.7 G1收集 / 64   3.4.8 垃圾收集参数总结 / 64   3.5 内存分配与回收策略 / 65   3.5.1 对象优先在Eden分配 / 66   3.5.2 大对象直接进入老年代 / 68   3.5.3 长期存活的对象将进入老年代 / 69   3.5.4 动态对象年龄判定 / 71   3.5.5 空间分配担保 / 73   3.6 本章小结 / 75   第4章 虚拟机性能监控与故障处理工具 / 76   4.1 概述 / 76   4.2 JDK的命令行工具 / 76   4.2.1 jps:虚拟机进程状况工具 / 79   4.2.2 jstat:虚拟机统计信息监视工具 / 80   4.2.3 jinfo:Java配置信息工具 / 82   4.2.4 jmap:Java内存映像工具 / 82   4.2.5 jhat:虚拟机堆转储快照分析工具 / 84   4.2.6 jstack:Java堆栈跟踪工具 / 85   4.3 JDK的可视化工具 / 87   4.3.1 JConsole:Java监视与管理控制台 / 88   4.3.2 VisualVM:多合一故障处理工具 / 96   4.4 本章小结 / 105   第5章 调优案例分析与实战 / 106   5.1 概述 / 106   5.2 案例分析 / 106   5.2.1 高性能硬件上的程序部署策略 / 106   5.2.2 集群间同步导致的内存溢出 / 109   5.2.3 堆外内存导致的溢出错误 / 110   5.2.4 外部命令导致系统缓慢 / 112   5.2.5 服务JVM进程崩溃 / 113   5.3 实战:Eclipse运行速度调优 / 114   5.3.1 调优前的程序运行状态 / 114   5.3.2 升级JDK 1.6的性能变化及兼容问题 / 117   5.3.3 编译时间和类加载时间的优化 / 122   5.3.4 调

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值