背景介绍

本文主要针对于 ZGC 的一篇非常不错的介绍文档的翻译文本，为了更的立即 ZGC 的概念和特性，希望如果翻译或者知识点有问题，请大家多多指正和谅解。

相关资源

源码资源

• http://cr.openjdk.java.net/~pliden/zgc/
  

作者主页

• https://twitter.com/perliden
  

文章原文

• https://dinfuehr.github.io/blog/a-first-look-into-zgc/
  

shenandoah 

• https://wiki.openjdk.java.net/display/shenandoah/Main
  

compact algorithm

• https://en.wikipedia.org/wiki/Mark-compact_algorithm
  

内容开淦

概念定义

ZGC is a new garbage collector recently open-sourced by Oracle for the OpenJDK. It was mainly written by Per Liden. ZGC is similar to Shenandoah or Azul’s C4 that focus on reducing pause-times while still compacting the heap.

ZGC 是最近被 Oracle 公司开源的一个新型的垃圾回收器，目前已经放置移交给 OpenJDK 去管理，它主要是开发者是由 Per Liden 主导，ZGC 回收器与 Shenandoah 或者 Azul 的 C4 的特性非常相似，主要是为当压缩堆内存的时候减少停顿时间为目的。

Although I won't give a full introduction here, “compacting the heap” just means moving the still-alive objects to the start (or some other region) of the heap. This helps to reduce fragmentation but usually this also means that the whole application (that includes all of its threads) needs to be halted while the GC does its magic, this is usually referred to as stopping the world.

• 虽然我不能做一个啊特别详细且特别完整的介绍，对于“压缩堆内存”仅仅意味着移动仍然存活的对象到堆开始的位置（或者是某些其他的区域里面（其实说明的意思就是压缩内存空间，重新 relocation））。这将帮助我们减少内存碎片，但这也会导致 GC 时候会使得整个系统（包括所有的 VM 线程和 Mutator 线程）被中断暂停。这就是我们所谓的 STW（自己有感而发，没有按照原文翻译）。

Only when the GC is finished, the application can be resumed. In GC literature the application is often called mutator, since from the GC’s point of view the application mutates the heap. Depending on the size of the heap such a pause could take several seconds, which could be quite problematic for interactive applications.

仅仅当 GC 被完成后，整个应用才会恢复，在 GC 的字典里（中国人的叫法），应用是被叫做 Muator（我上面翻译的时候已经说了），因为从 GC 的角度来看，应用程序改变了堆内存的大小，根据堆内存的大小，这种暂停可能需要几秒钟的时间，但这对与交互方式非常看重的应用程序是非常严重的。

There are several ways to reduce pause times:

• The GC can employ multiple threads while compacting (parallel compaction).

• Compaction work can also be split across multiple pauses (incremental compaction).

• Compact the heap concurrently to the running application without stopping it (or just for a short time) (concurrent compaction).

• No compaction of the heap at all (an approach taken by e.g. Go’s GC).

这里有几种方法去处理减少暂停时间：

• GC 处理器可以使用多线程技术并行压缩内存空间机制。（并行压缩）

• 整体压缩阶段被拆分为跨多个子阶段发生 STW 暂停阶段。（暂停时间拆分）

• 在运行应用程序的同时可以进行堆内存的压缩，并且不会暂停应用线程。（并发压缩）

• 丝毫不进行堆内存的压缩操作机制。（禁用压缩）

ZGC uses concurrent compaction to keep pauses to a minimum, this is certainly not obvious to implement so I want to describe how this works. Why is this complicated?

• You need to copy an object to another memory address, at the same time another thread could read from or write into the old object.

• If copying succeeded there might still be arbitrary many references somewhere in the heap to the old object address that need to be updated to the new address.

I should also mention that although concurrent compaction seems to be the best solution to reduce pause time of the alternatives given above, there are definitely some tradeoffs involved. So if you don’t care about pause times, you might be better off using a GC that focuses on throughput instead.

ZGC 采用的是并发压缩机制去降低暂停的时间，并且会保持在很短的时间内（10 毫秒之内），但说起来这并不能完全描述出他如何工作的实现方式。为什么会这么复杂呢？

• 需要拷贝一个对象到另外一个内存地址，同时其他的线程能够读取或者写入原来的对象。

• 如果成功的执行拷贝，堆中的某些对象可能还存在着很多对之前对象的引用关系，需要更新成新对象的引用地址关系。

我应该可以看出来，并发压缩机制看起来算是最好的一个解决办法去减少暂停时间，肯定涉及到一些权衡。因此，如果您不关心暂停时间，那么最好使用关注吞吐量的 GC。

接下来一篇是 Load Barrier 特性机制，读屏障机制功能，敬请收看，未完待续... ...