JVM-064-垃圾回收器-垃圾回收器的新发展

介绍

  • GC仍然处于飞速发展之中,目前的默认选项G1 GC在不断的进行改进,很多我们原来认为的缺点,例如串行的Full GC、Card Table扫描的低效等,都已经被大幅改进,例如,JDK10以后,Full GC已经是并行运行,在很多场景下,其表现还略优于Parallel GC的并行Full GC实现。
  • 即使是Serial GC,虽然比较古老,但是简单的设计和实现未必就是过时的,它本身的开销,不管是GC相关数据结构的开销,还是线程的开销,都是非常小的,所以随着云计算的兴起,在Serverless等新的应用场景下,Serial GC找到了新的舞台。
  • 比较不幸的是CMS GC,因为其算法的理论缺陷等原因,虽然现在还有非常大的用户群体,但在JDK9中已经被标记为废弃,并在JDK14版本中移除
  • 现在G1回收器已成为默认回收器好几年了。我们还看到了引入了两个新的收集器:ZGC(JDK11出现)和Shenandoah(Open JDK12),其特点:主打低停顿时间
阅读更多

JVM-063-垃圾回收器-GC日志分析

常用参数配置

通过阅读GC日志,我们可以了解Java虚拟机内存分配与回收策略。

内存分配与垃圾回收的参数列表

  • -XX:+PrintGC :输出GC日志。类似:-verbose:gc
  • -XX:+PrintGCDetails :输出GC的详细日志
  • -XX:+PrintGCTimestamps :输出GC的时间戳(以基准时间的形式)
  • -XX:+PrintGCDatestamps :输出GC的时间戳(以日期的形式,如2013-05-04T21: 53: 59.234 +0800)
  • -XX:+PrintHeapAtGC :在进行GC的前后打印出堆的信息
  • -Xloggc:…/logs/gc.log :日志文件的输出路径
阅读更多

JVM-062-垃圾回收器-垃圾回收器总结

7 种垃圾回收器的比较

截止JDK1.8,一共有7款不同的垃圾收集器。每一款的垃圾收集器都有不同的特点,在具体使用的时候,需要根据具体的情况选用不同的垃圾收集器。

垃圾收集器 分类 作用位置 使用算法 特点 适用场景
Serial 串行运行 作用于新生代 复制算法 响应速度优先 适用于单CPU环境下的client模式
ParNew 并行运行 作用于新生代 复制算法 响应速度优先 多CPU环境Server模式下与CMS配合使用
Parallel 并行运行 作用于新生代 复制算法 吞吐晕优先 适用于后台运算而不需要太多交互的场景
Serial Old 串行运行 作用于老年代 标记-压缩算法 响应速度优先 适用于单CPU环境下的Client模式
Parallel old 并行运行 作用于老年代 标记-压缩算法 吞吐量优先 适用于后台运算而不需要太多交互的场景
CMS 并发运行 作用于老年代 标记-清除算法 响应速度优先 适用于互联网或B/S业务
G1 并发、并行 作用于新生代、老年代 标记-压缩算法、复制算法 响应速度优先 面向服务端应用
阅读更多

JVM-061-垃圾回收器-G1回收器-垃圾回收过程详情

过程一:年轻代GC

解释说明

  • JVM启动时,G1先准备好Eden区,程序在运行过程中不断创建对象到Eden区,当Eden空间耗尽时,G1会启动一次年轻代垃圾回收过程。

  • 年轻代回收只回收Eden区和Survivor区。

  • YGC时,首先G1停止应用程序的执行(Stop-The-World),G1创建回收集(Collection Set),回收集是指需要被回收的内存分段的集合,年轻代回收过程的回收集包含年轻代Eden区和Survivor区所有的内存分段。

图示

阅读更多

JVM-060-垃圾回收器-G1回收器-主要回收环节

主要环节

  1. 年轻代GC(Young GC)
  2. 老年代并发标记过程(Concurrent Marking)
  3. 混合回收(Mixed GC)
  4. Full GC (第四个环节,不是主要的;如果需要,单线程、独占式、高强度的Full GC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制,即强力回收。)
阅读更多

JVM-059-垃圾回收器-G1回收器-分区Region详解

引入

化整为零

使用G1收集器时,它将整个Java堆划分成约2048个大小相同的独立Region块,每个Region块大小根据堆空间的实际大小而定,整体被控制在1MB到32MB之间,且为2的N次幂,即1MB,2MB,4MB,8MB,16MB,32MB。可以通过 -XX:G1HeapRegionSize设定。所有的Region大小相同,且在JVM生命周期内不会被改变。

阅读更多

JVM-056-垃圾回收器-G1回收器-概述(区域化分代式)

引入

既然我们已经有了前面几个强大的 GC ,为什么还要发布 Garbage First(G1)GC?

  • 原因就在于应用程序所应对的业务越来越庞大、复杂,用户越来越多,没有GC就不能保证应用程序正常进行,而经常造成STW的GC又跟不上实际的需求,所以才会不断地尝试对GC进行优化。G1(Garbage-First)垃圾回收器是在Java7 update4之后引入的一个新的垃圾回收器,是当今收集器技术发展的最前沿成果之一。

  • 与此同时,为了适应现在不断扩大的内存和不断增加的处理器数量,进一步降低暂停时间(pause time),同时兼顾良好的吞吐量。

  • 官方给G1设定的目标是在延迟可控的情况下获得尽可能高的吞吐量,所以才担当起“全功能收集器”的重任与期望。

阅读更多

JVM-055-垃圾回收器-CMS回收器(低延时)

引入

  • 在JDK1.5时期,Hotspot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器:CMS(Concurrent-Mark-Sweep)收集器,这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器,它第一次实现了让垃圾收集线程与用户线程同时工作。
  • CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短(低延迟)就越适合与用户交互的程序,良好的响应速度能提升用户体验。
    • 目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
  • CMS的垃圾收集算法采用标记-清除算法,并且也会”Stop-the-World”
  • 不幸的是,CMS作为老年代的收集器,却无法与JDK1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作(因为实现的框架不一样,没办法兼容使用),所以在JDK1.5中使用CMS来收集老年代的时候,新生代只能选择ParNew或者Serial收集器中的一个。
  • 在G1出现之前,CMS使用还是非常广泛的。一直到今天,仍然有很多系统使用CMS GC。
阅读更多