这篇文章主要介绍“如何理解内存布局及GC原理”，在日常操作中，相信很多人在如何理解内存布局及GC原理问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”如何理解内存布局及GC原理”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
创新互联主要从事网页设计、PC网站建设（电脑版网站建设）、wap网站建设（手机版网站建设）、成都响应式网站建设公司、程序开发、网站优化、微网站、小程序定制开发等，凭借多年来在互联网的打拼，我们在互联网网站建设行业积累了丰富的网站设计制作、成都网站设计、网站设计、网络营销经验，集策划、开发、设计、营销、管理等多方位专业化运作于一体。
ZGC（The Z Garbage Collector）是 JDK 11 中推出的一款低延迟垃圾回收器，它的设计目标包括： 在G1的基础上，做了很多改进（JDK 11 开始引入）
停顿时间不超过 10ms；
停顿时间不会随着堆的大小，或者活跃对象的大小而增加；
支持 8MB~4TB 级别的堆（未来支持 16TB）。
从设计目标来看，我们知道 ZGC 适用于大内存低延迟服务的内存管理和回收。本文主要介绍 ZGC 在低延时场景中的应用和卓越表现，文章内容主要分为四部分：
GC 之痛 ：介绍实际业务中遇到的 GC 痛点，并分析 CMS 收集器和 G1 收集器停顿时间瓶颈；
ZGC 原理 ：分析 ZGC 停顿时间比 G1 或 CMS 更短的本质原因，以及背后的技术原理；
ZGC 调优实践 ：重点分享对 ZGC 调优的理解，并分析若干个实际调优案例；
升级 ZGC 效果 ：展示在生产环境应用 ZGC 取得的效果。
很多低延迟高可用Java服务的系统可用性经常受 GC 停顿的困扰。GC 停顿指垃圾回收期间 STW（Stop The World），当 STW 时，所有应用线程停止活动，等待GC停顿结束。
以美团风控服务为例，部分上游业务要求风控服务 65ms 内返回结果，并且可用性要达到 99.99%。但因为 GC 停顿，我们未能达到上述可用性目标。当时使用的是 CMS 垃圾回收器，单次 Young GC 40ms，一分钟 10 次，接口平均响应时间 30ms。通过计算可知，有（ 40ms + 30ms ) * 10 次 / 60000ms = 1.12%的请求的响应时间会增加 0 ~ 40ms 不等，其中 30ms * 10 次 / 60000ms = 0.5%的请求响应时间会增加 40ms。
可见，GC 停顿对响应时间的影响较大。为了降低 GC 停顿对系统可用性的影响，我们从降低单次 GC 时间和降低 GC 频率两个角度出发进行了调优，还测试过G1垃圾回收器，但这三项措施均未能降低 GC 对服务可用性的影响。
介绍ZGC之前，首先回顾一下 CMS 和 G1 的 GC 过程以及停顿时间的瓶颈。CMS 新生代的 Young GC、G1 和 ZGC 都基于标记-复制算法，但算法具体实现的不同就导致了巨大的性能差异。
标记-复制算法应用在 CMS 新生代（ParNew 是 CMS 默认的新生代垃圾回收器）和 G1 垃圾回收器中。
标记-复制算法可以分为四个阶段：
标记阶段，即从 GC Roots 集合开始，标记活跃对象；
清理阶段，即清理所有不活跃的对象
转移阶段，即把活跃对象复制到新的内存地址上；
重定位阶段，因为转移导致对象的地址发生了变化，在重定位阶段，所有指向对象旧地址的指针都要调整到对象新的地址上。
下面以 G1 为例，通过 G1 中标记-复制算法过程（G1 的 Young GC 和 Mixed GC 均采用该算法），分析 G1 停顿耗时的主要瓶颈。G1 垃圾回收周期如下图所示：
G1 的混合回收过程可以分为标记阶段、清理阶段和复制阶段。
初始标记阶段是指从 GC Roots 出发标记全部直接子节点的过程，该阶段是 STW 的。由于 GC Roots 数量不多，通常该阶段耗时非常短。
并发标记阶段是指从 GC Roots 开始对堆中对象进行可达性分析，找出存活对象。该阶段是并发的，即应用线程和 GC 线程可以同时活动。 并发标记耗时相对长很多，但因为不是 STW，所以我们不太关心该阶段耗时的长短。
重新标记那些在并发标记阶段发生变化的对象。该阶段是 STW 的。
清理阶段清点出有存活对象的分区和没有存活对象的分区，该阶段不会清理垃圾对象，也不会执行存活对象的复制。该阶段是 STW 的,因此此阶段不会出现浮动对象。
复制算法中的转移阶段需要分配新内存和复制对象的成员变量。转移阶段是 STW 的，其中内存分配通常耗时非常短，但对象成员变量的复制耗时有可能较长，这是因为复制耗时与存活对象数量与对象复杂度成正比。对象越复杂，复制耗时越长。（不会存在内存碎片且不适合大对象的赋值迁移）
初始标记因为只标记 GC Roots，耗时较短。(STW)
再标记因为对象数少，耗时也较短。
清理阶段因为内存分区数量少，耗时也较短。(STW)
转移阶段要处理所有存活的对象，耗时会较长。(STW)
因此，G1 停顿时间的瓶颈主要是标记-复制中的转移阶段 STW。为什么转移阶段不能和标记阶段一样并发执行呢？主要是 G1 未能解决转移过程中准确定位对象地址的问题。
G1 的 Young GC 和 CMS 的 Young GC，其标记-复制全过程 STW，这里不再详细阐述。
与CMS中的ParNew和G1类似，ZGC 也采用标记-复制算法，不过 ZGC对该算法做了重大改进：ZGC 在标记、转移和重定位阶段几乎都是并发的，这是 ZGC 实现停顿时间小于 10ms 目标的最关键原因。
ZGC 垃圾回收周期如下图所示： 
ZGC只有三个 STW 阶段： 初始标记 ， 再标记 ， 初始转移 。
其中，初始标记和初始转移分别都只需要扫描所有 GC Roots，其处理时间和 GC Roots 的数量成正比，一般情况耗时非常短；再标记阶段 STW 时间很短，最多 1ms，超过 1ms 则再次进入并发标记阶段。即，ZGC几乎所有暂停都只依赖于 GC Roots 集合大小，停顿时间不会随着堆的大小或者活跃对象的大小而增加。与 ZGC 对比，G1的转移阶段完全STW的，且停顿时间随存活对象的大小增加而增加。
ZGC只有三个 STW 阶段：初始标记 ， 再标记 ， 初始转移。其中，初始标记和初始转移分别都只需要扫描所有 GC Roots，其处理时间和 GC Roots 的数量成正比，一般情况耗时非常短；再标记阶段 STW 时间很短，最多1ms，超过1ms则再次进入并发标记阶段。即，ZGC 几乎所有暂停都只依赖于GC Roots集合大小，停顿时间不会随着堆的大小或者活跃对象的大小而增加。与 ZGC 对比，G1 的转移阶段完全 STW 的，且停顿时间随存活对象的大小增加而增加。
ZGC 通过着色指针和读屏障技术，解决了转移过程中准确访问对象的问题，实现了并发转移。
大致原理描述如下：并发转移中“并发”意味着 GC 线程在转移对象的过程中，应用线程也在不停地访问对象。假设对象发生转移，但对象地址未及时更新，那么应用线程可能访问到旧地址，从而造成错误。ZGC中，应用线程访问对象将触发“读屏障”，如果发现对象被移动了，那么“读屏障”会把读出来的指针更新到对象的新地址上，这样应用线程始终访问的都是对象的新地址。那么，JVM 是如何判断对象被移动过呢？就是利用对象引用的地址，即着色指针。下面介绍着色指针和读屏障技术细节。
着色指针是一种将信息存储在指针中的技术。
ZGC 仅支持 64 位系统，它把 64 位虚拟地址空间划分为多个子空间，如下图所示： 
其中，[0~4TB) 对应 Java 堆，[4TB ~ 8TB) 称为 M0 地址空间，[8TB ~ 12TB) 称为 M1 地址空间，[12TB ~ 16TB) 预留未使用，[16TB ~ 20TB) 称为 Remapped 空间。
当应用程序创建对象时，首先在堆空间申请一个虚拟地址，但该虚拟地址并不会映射到真正的物理地址。ZGC 同时会为该对象在 M0、M1 和 Remapped 地址空间分别申请一个虚拟地址，且这三个虚拟地址对应同一个物理地址，但这三个空间在同一时间有且只有一个空间有效。ZGC 之所以设置三个虚拟地址空间，是因为它使用“空间换时间”思想，去降低 GC 停顿时间。“空间换时间”中的空间是虚拟空间，而不是真正的物理空间。后续章节将详细介绍这三个空间的切换过程。
与上述地址空间划分相对应，ZGC 实际仅使用 64 位地址空间的第 0~41 位，而第 42~45 位存储元数据，第 47~63 位固定为 0。ZGC 将对象存活信息存储在 42~45 位中，这与传统的垃圾回收并将对象存活信息放在对象头中完全不同。
读屏障是 JVM 向应用代码插入一小段代码的技术。当应用线程从堆中读取对象引用时，就会执行这段代码。需要注意的是，仅“从堆中读取对象引用”才会触发这段代码。
