ZGC为何在你的服务中仍触发Full GC？5个隐藏配置错误正在悄悄毁掉低延迟承诺！

最新推荐文章于 2026-05-23 09:45:15 发布
原创 最新推荐文章于 2026-05-23 09:45:15 发布 · 333 阅读 · 6 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测

第一章：ZGC低延迟承诺失效的真相溯源

ZGC（Z Garbage Collector）自JDK 11引入以来，以“亚毫秒级停顿”为标志性承诺，被广泛用于对延迟极度敏感的金融、实时风控与高并发API网关场景。然而生产实践中频繁出现STW时间突破10ms甚至百毫秒的现象，表面看违背设计初衷，实则源于对ZGC运行约束条件的系统性误读。

关键触发因素分析

  • 堆外内存压力导致元数据分配阻塞ZGC并发标记线程
  • 大对象（≥2MB）未启用-XX:+ZUncommitDelay时引发周期性内存归还抖动
  • Linux cgroup v1环境下未配置memory.high导致OOM Killer误杀ZGC工作线程

诊断工具链验证

使用JDK自带工具捕获真实停顿根因： 
# 启用ZGC详细日志（含各阶段耗时与线程状态）
java -XX:+UseZGC -Xlog:gc*,gc+phases=debug,gc+heap=debug,gc+ref=debug \
     -Xlog:safepoint -Xmx16g -jar app.jar
日志中需重点排查Concurrent Reset Relocation Set和Pause Mark End阶段的异常延迟，它们往往暴露了并发线程被抢占或I/O阻塞问题。

ZGC参数敏感性对照表

参数默认值高延迟风险场景推荐调优值
-XX:ZCollectionInterval0（禁用）突发流量下未主动触发回收5（秒）
-XX:ZUncommitDelay300（秒）云环境弹性伸缩时内存释放滞后60（秒）

内核级干扰验证

在容器化部署中，可通过以下命令确认ZGC线程是否遭遇CPU调度压制： 
# 检查ZGC并发线程（z_stat, z_worker_*）的调度延迟
sudo perf sched latency -s max -n 20 | grep "z_"
# 若max delay > 5ms，需调整cgroup CPU bandwidth或启用SCHED_FIFO
该命令输出将直接揭示操作系统层面对ZGC关键线程的调度保障缺失，是多数“低延迟失效”案例的终极归因。

第二章：堆内存配置中的致命陷阱

2.1 堆大小设置不当导致ZGC无法启动并发周期

ZGC要求堆大小必须满足最小并发标记阈值，否则直接退化为 Full GC 且不触发任何并发周期。
关键约束条件
  • ZGC 默认要求初始堆（-Xms）≥ 4GB，否则拒绝启用并发标记
  • 堆上限（-Xmx）与下限（-Xms）差异过大时，ZGC 可能因内存碎片或元数据不足而跳过并发周期
典型错误配置
# ❌ 错误：堆过小，ZGC 启动日志将显示 "Concurrent GC disabled"
java -XX:+UseZGC -Xms512m -Xmx2g MyApp
该配置违反 ZGC 最小堆要求（4GB），JVM 在初始化阶段即禁用所有并发阶段，仅执行 STW 的 Full GC。
ZGC 堆尺寸合规对照表
配置项推荐值是否触发并发周期
-Xms4g -Xmx4g✅ 最小可行单值是
-Xms8g -Xmx16g✅ 推荐生产范围是
-Xms2g -Xmx8g❌ 动态扩展易引发元数据压力否

2.2 初始堆（-Xms）与最大堆（-Xmx）不一致引发的元数据压力

堆大小动态伸缩的代价
当 -Xms=512m 与 -Xmx=4g 显著不匹配时，JVM 在运行中频繁扩容堆空间，导致 Metaspace 区域伴随每次 Full GC 触发类元数据重扫描与清理，加剧内存碎片与回收延迟。
典型 JVM 启动参数对比
场景-Xms-XmxMetaspace 压力表现
均衡配置2g2g稳定，类加载后元数据复用率高
悬殊配置512m4gGC 频次↑37%，Metaspace 耗时占比达 22%
监控建议
# 实时观察 Metaspace 动态行为
jstat -gcmetacapacity <pid> 1s
# 输出字段：MC（Metaspace 容量）、MU（已使用）、CCSC（压缩类空间容量）
该命令持续输出元数据区容量变化趋势；若 MC 频繁波动且 MU/MA 比值长期 >90%，表明初始堆过小已诱发元数据管理失衡。

2.3 非对齐堆大小（非2的幂次）触发隐式Full GC回退机制

触发条件与内核行为
当JVM启动时指定堆大小（如 -Xms1536m -Xmx1536m）未对齐至2的幂次（如1024M、2048M），G1或ZGC等现代收集器可能在初始化阶段拒绝使用优化路径，自动降级至Serial+CMS兼容模式，进而诱发首次Full GC。
关键参数验证
  • UseG1GC 启用时，G1HeapRegionSize 必须为2的幂次，否则触发VMOperation回退
  • MaxHeapSize 若为1536M（1.5GiB），其二进制表示含非连续高位，导致页映射表碎片化
典型日志片段
[gc,init] Heap size 1536M is not aligned to region size 2048K → falling back to conservative GC mode
该日志表明：区域大小计算失败后，JVM强制启用UseSerialGC兜底策略，绕过并行标记逻辑。
对齐建议对照表
指定值是否2ⁿ(MiB)运行时行为
1024✓启用G1并发标记
1536✗隐式Full GC + Serial GC回退

2.4 ZPage大小与对象分配模式不匹配导致内存碎片化加剧

ZPage尺寸固定性与对象大小分布的冲突
ZGC将堆划分为固定大小（如2MB）的ZPage，但Java应用中对象尺寸呈幂律分布：大量小对象（<128B）与少量大对象（>512KB）并存。当小对象密集分配时，单个ZPage无法被完全利用，产生内部碎片；而大对象又可能跨页导致外部碎片。
典型分配失配场景
  • 默认ZPage大小为2MB，但60%的对象小于256B
  • 频繁分配1–4KB对象时，每页仅容纳512–2048个对象，尾部剩余空间无法复用
碎片率量化对比
对象平均尺寸ZPage利用率内部碎片率
128B6.3%93.7%
4KB99.2%0.8%
运行时诊断代码
// 获取ZPage统计（JDK 21+ JVM TI扩展）
ZPageStats stats = ZHeap.getInstance().getPageStats();
System.out.printf("Avg utilization: %.1f%%, Fragmented pages: %d%n", 
    stats.avgUtilization() * 100, stats.fragmentedCount());
该代码调用ZGC内部统计接口，avgUtilization()返回所有活跃ZPage的加权平均填充率，fragmentedCount()统计利用率低于10%的页面数量，直接反映碎片化严重程度。

2.5 忽略ZGC专用堆外元数据区（Metaspace + Native Memory）容量约束

Metaspace动态扩容机制
ZGC默认不设Metaspace上限，依赖ClassUnloading与G1-like的元空间垃圾回收策略： 
java -XX:+UseZGC -XX:MaxMetaspaceSize=0 -jar app.jar
MaxMetaspaceSize=0 表示禁用硬性限制，由JVM根据类加载行为自动伸缩；ZGC通过并发元空间扫描避免Stop-The-World。
本地内存分配策略
ZGC将部分元数据结构（如Forwarding Tables、Mark Bitmaps）置于Native Memory，绕过Java堆管理：
  • Forwarding Table：每页8KB，按需映射，非预分配
  • Mark Bitmap：双缓冲设计，仅活跃区域驻留物理内存
ZGC元数据内存对比
组件是否受-Xmx约束典型增长模式
Metaspace否随类加载线性增长，卸载后释放
Forwarding Table否随堆大小对数增长（O(log₂ heap)）

第三章：运行时参数组合的隐蔽冲突

3.1 -XX:+UseZGC与JVM版本/OS内核特性不兼容的实证分析

典型启动失败场景
java -XX:+UseZGC -version
# 报错：Unrecognized VM option '+UseZGC'
# 或：ZGC is not supported on this platform
该错误表明JVM未启用ZGC支持，常见于OpenJDK 11早期构建版或Linux内核低于4.14（缺少userfaultfd系统调用）。
兼容性验证矩阵
JVM版本最低内核要求ZGC默认启用
OpenJDK 11.0.1+Linux 4.14+否（需显式开启）
OpenJDK 15+Linux 4.17+是（但受限于内核功能）
关键内核依赖检查
  • /proc/sys/vm/transparent_hugepage 必须为 always 或 madvise
  • userfaultfd 系统调用需在CONFIG_USERFAULTFD=y下编译

3.2 并发标记线程数（-XX:ZCollectionInterval）误配引发STW膨胀

参数语义混淆陷阱
`-XX:ZCollectionInterval` 实际控制的是 ZGC 中两次并发 GC 周期的**最小时间间隔（毫秒）**，而非并发标记线程数——后者由 `-XX:ParallelGCThreads` 或 ZGC 自动推导的 `ConcGCThreads` 决定。常见误配是将该参数设为极小值（如 10），导致 GC 频繁触发。 
java -XX:+UseZGC \
     -XX:ZCollectionInterval=50 \
     -Xms4g -Xmx4g MyApp
此配置强制 ZGC 每 50ms 尝试启动一次 GC，但若堆存活对象未显著增长，ZGC 仍需执行完整并发标记→转移流程，期间 **Initial Mark** 和 **Remark** 阶段会触发 STW，造成 STW 次数激增。
STW 膨胀实测对比
配置平均 STW 次数/秒单次 STW 峰值（ms）
-XX:ZCollectionInterval=508.24.7
-XX:ZCollectionInterval=50000.31.1
调优建议
  • 生产环境应移除该参数，交由 ZGC 自适应调度；
  • 仅在压测中模拟高频回收场景时临时启用，并同步监控 `ZStatistics::pause` 日志；

3.3 -XX:ZUncommitDelay与应用内存波动节奏错位导致频繁退化

ZUncommitDelay 的语义本质
该参数定义 ZGC 在回收空闲堆内存页前的等待时长（毫秒），默认值为 300。若设置过短，ZGC 可能在应用即将再次分配内存前就主动归还页，造成“刚释放、立刻申请”的震荡。
典型错位场景复现
// JVM 启动参数示例（危险配置）
-XX:+UseZGC -Xms4g -Xmx4g -XX:ZUncommitDelay=50
当应用每 80ms 触发一次批量日志刷写（峰值分配 ~128MB），ZGC 却在 50ms 后强行退化已空闲页，迫使后续分配触发昂贵的 mmap 系统调用。
延迟匹配建议
  • 通过 GC 日志提取 `ZUncommit` 频次与应用周期性行为时间戳对齐分析
  • 将 -XX:ZUncommitDelay 设为略大于应用最大稳定空闲窗口（如 400–600ms）

第四章：监控与诊断配置的盲区漏洞

4.1 缺失ZGC专用JVM日志（-Xlog:gc*,zgc*）导致退化路径不可见

ZGC退化行为依赖日志可观测性
ZGC在遭遇内存压力、大对象分配或并发标记失败时，可能退化为Serial GC或Full GC。但若未启用ZGC专属日志，这些关键决策点将完全静默。
正确日志配置示例
-Xlog:gc*,zgc*,gc+heap=debug,gc+ref=debug:stdout:time,tags,level:file=logs/zgc.log:uptime,level,pid,tid
该配置启用ZGC事件（zgc*）、GC周期（gc*）、堆变更与引用处理日志，并按时间戳、线程ID等维度结构化输出，确保退化触发条件（如zgc_gc_cycle_start后无zgc_gc_cycle_end而出现gc+serial）可追溯。
常见缺失日志导致的盲区
  • 仅用-Xlog:gc：遗漏ZGC内部阶段（如Relocation Set构建失败）
  • 未启用gc+heap=debug：无法定位退化前的内存碎片率或TLAB耗尽信号

4.2 JFR事件采样粒度不足掩盖ZGC关键阶段耗时异常

问题现象
JFR默认配置下，ZGCPauseMarkStart、ZGCPauseMarkEnd等ZGC关键事件以“采样模式”触发，而非全量记录，导致亚毫秒级暂停被合并或丢弃。
验证配置差异
# 启用全量ZGC事件采集（推荐调试用）
jcmd <pid> VM.native_memory summary scale=MB
jfr start name=ZGCDebug settings=profile -XX:StartFlightRecording=settings=zgc-debug.jfc
该命令启用自定义zgc-debug.jfc配置，将jdk.ZGCPauseMarkStart事件设为threshold="0 ns"，禁用采样过滤。
JFR事件粒度对比
事件类型默认阈值实际捕获精度
ZGCPauseRelocateStart10 ms≥10 ms才记录
ZGCPauseMarkEnd5 ms＜5 ms的标记结束耗时完全丢失

4.3 Prometheus指标未暴露ZGC退化触发器（如ZMarkStackUsage、ZRelocateQueueSize）

ZGC关键退化指标缺失现状
ZGC在发生退化（如转为Serial GC）前，依赖内部状态如标记栈使用率与重定位队列长度。但JVM默认导出的`jvm_gc_zgc_*`指标中，ZMarkStackUsage和ZRelocateQueueSize未被Prometheus JMX Exporter映射。
手动暴露指标配置示例
# jmx_exporter config.yml
rules:
- pattern: 'java.lang<type=GarbageCollector, name=ZGC><([^>]+)>(.+)'
  name: jvm_gc_zgc_$2
  value: $3
  labels:
    $1: $2
该配置仅捕获顶层属性，而ZMarkStackUsage等为嵌套MBean属性（如sun.management.ManagedMemoryManagerImpl->ZMarkStackUsage），需显式声明路径匹配规则。
关键指标语义对照表
指标名单位退化阈值参考
ZMarkStackUsage百分比>95% 持续30s 易触发并发标记失败
ZRelocateQueueSize元素数>10M 表明重定位压力过大

4.4 GC日志解析脚本忽略ZGC特有的“Allocation Stall”与“Relocation Stall”语义

问题根源
传统GC日志解析脚本（如基于G1/CMS日志设计）默认将所有含“stall”字样的事件归类为停顿（Stop-The-World），但ZGC的Allocation Stall和Relocation Stall本质是**非阻塞式等待**——前者因内存分配器暂未就绪而短暂自旋，后者因重定位线程负载高而延迟申请页，均不触发STW。
关键日志特征对比
事件类型ZGC语义传统脚本误判
Allocation Stall用户线程自旋等待新内存页计入“GC Pause Time”
Relocation Stall等待重定位完成的轻量级让出计入“Concurrent Phase Pause”
修复逻辑示例
# 忽略ZGC特有stall行（正则增强）
if re.match(r'^(Allocation|Relocation) Stall', line):
    continue  # 跳过解析，不计入任何暂停指标
该代码通过前置模式匹配，在日志行解析入口直接过滤两类ZGC stall事件，避免后续统计模块错误聚合。参数line为原始日志行，正则使用锚定符^确保精确匹配事件起始，防止误伤含相似子串的正常日志。

第五章：通往真正亚毫秒级停顿的终极实践路径

ZGC 在 Kubernetes 中的生产调优
在某高频交易系统中，将 ZGC 与 cgroup v2 内存控制器协同配置后，99.9th 百分位 GC 停顿从 1.8ms 降至 0.37ms。关键配置如下： 
<jvmArgs>
  -XX:+UseZGC
  -XX:ZCollectionInterval=5
  -XX:+UnlockExperimentalVMOptions
  -XX:+ZProactive
  --add-opens java.base/jdk.internal.misc=ALL-UNNAMED
</jvmArgs>
内存页大小对延迟的决定性影响
启用大页（HugePages）可显著减少 TLB miss 导致的微停顿。实测对比（4KB vs 2MB 页面）：
指标4KB 标准页2MB 透明大页
平均 GC 暂停0.92ms0.23ms
TLB miss 率12.7%0.8%
99.99th 延迟抖动3.1ms0.41ms
硬件协同优化清单
  • 禁用 Intel SpeedStep 和 AMD Cool'n'Quiet，锁定 CPU 频率至基础主频
  • BIOS 中启用 Sub-NUMA Clustering（SNC）以缩短远程内存访问延迟
  • 将 JVM 进程绑定至隔离 CPU 核心集（isolcpus=1-7,9-15），并关闭 IRQ 干扰
实时监控闭环反馈机制

部署 Prometheus + Grafana 实时追踪 ZGC 的 ZGCCycle、ZGCPauseTime 及 ZPageAllocationRate 指标；当 99th 暂停时间连续 3 分钟 > 0.5ms 时，自动触发 JVM 参数热调整脚本。

ProceChat
关注
深度解析ZGC：高效垃圾回收的应用与优化
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
04-07 177万+
随着现代应用对性能的要求不断提高，ZGC（Z Garbage Collector）作为一种低暂停时间的垃圾回收器，已成为处理大规模堆内存的理想选择。本文介绍了 ZGC 的基本原理与技术架构，重点分析了其在 JDK11 中的应用与优化策略。通过对 ZGC 性能特点的探索，本文旨在帮助开发者深入理解其在高并发、大数据场景下的表现，以及如何通过合理调优提升系统的内存管理效率和稳定性。
垃圾回收之CMS、G1、ZGC对比
互联网架构师笔记
04-01 3074
ZGC在JDK15达到production-ready，JDK17是第一个开始推出成熟的ZGC的长期支持的ZGC版本。
ZGC 垃圾回收器
程序猿进阶
04-11 2134
ZGC（The Z Garbage Collector）是JDK 11中推出的一款低延迟垃圾回收器，它的设计目标包括： 【1】停顿时间不超过10ms； 【2】停顿时间不会随着堆的大小，或者活跃对象的大小而增加，影响它的是 GCRoot对象； 【3】支持 8MB~4TB级别的堆（未来支持16TB）； 从设计目标来看，ZGC适用于大内存低延迟服务的内存管理和回收。本文主要介绍 ZGC在低延时场景中的应用和卓越表现，文章内容主要分为四部分： 【1】GC之痛：介绍实际业务中遇到的 GC痛点，并分析 CMS收集器和
jvm垃圾回收器 - ZGC
最新发布
tongluowan007的博客
05-23 314
在ZGC的一轮GC周期中，对象存活（不用回收）的表示是：指向它的指针颜色被设置为当前周期使用的标记色（例如Marked0或Marked1）。凡是没有被染上该颜色的对象，就被视为垃圾，可以回收。这也就是为什么ZGC的标记过程也常被称为“染色指针标记”。读屏障不是一道物理屏障，而是一小段由JIT自动插入到应用程序中的机器码。每次应用程序从堆中读取一个对象引用（例如），JIT就会在读取指令后面加入这段屏障代码。// 每次从堆中读取引用时，实际执行的是类似这样的函数。
新一代垃圾收集器：ZGC深度剖析，到底什么时候用？
秃了也弱了
12-08 4465
支持TB量级的堆。我们生产环境的硬盘还没有上TB呢，这应该可以满足未来十年内，所有JAVA应用的需求了吧。最大GC停顿时间不超10ms。目前一般线上环境运行良好的JAVA应用Minor GC停顿时间在10ms左右，Major GC一般都需要100ms以上（G1可以调节停顿时间，但是如果调的过低的话，反而会适得其反），之所以能做到这一点是因为它的停顿时间主要跟Root扫描有关，而Root数量和堆大小是没有任何关系的。奠定未来GC特性的基础。最糟糕的情况下吞吐量会降低15%。
JVM垃圾回收——ZGC垃圾收集器
weixin_39555954的博客
04-02 5068
ZGC(Z Garbage Collector)是一款在jdk11中加入的具有实验性质的低延迟的垃圾收集器，在jdk15中去掉实验的标识，成为具有商用的垃圾收集器。垃圾收集停顿时间控制在10毫秒以内（在jdk16之后停顿时间已经控制到1毫秒以内）的一款低停顿的垃圾收集器。如果非要给ZGC下一个定义的话，ZGC收集器是一款基于Region内存布局的，不设分代（不分老年代、新生代）的，使用了等技术来实现的基于标记-整理算法实现的，以低延迟为首要目标的一款的垃圾收集器。
详解ZGC垃圾收集器
sermonlizhi的博客
05-20 5626
从G1垃圾收集器开始，后面的垃圾收集器都不再将堆按照新生代和老年代作为整体进行回收，都采用了局部收集的设计思想。 可能是由于G1作为第一代局部收集的垃圾收集器，所以它继续保留了新生代和老年代的概念，笔者认为从局部收集和分区的内存布局来看，按代收集理论已经没有什么特别存在的必要了。 一、ZGC的设计思路 1.1 ZGC的内存布局 新一代的垃圾收集器ZGC(Z Garbage Collector)就完全抛弃了按代收集理论，它与G1一样将内存划分成各个小的区域的，但与G1有所不同的是，ZGC的各个内存区域称为页面
ZGC深度剖析
qq_21575929的博客
04-25 4134
1.ZGC简介 ZGC是一款jdk11版本支持下的垃圾回收器，支持TB级别的内存，12306抢票软件一般都是TB级别的内存，STW时间不超过1ms，ZGC的出现是为了抢占外部市场，比如安卓，大数据等。 1.1 ZGC内存布局 ZGC没有分代的概念。一般分为小页面(小于256k的对象分配)，中页面(小于4M的对象分配)，大页面(大于4M的对象分配)。垃圾回收器回收内存一般先回收小页面对象，中页面和大页面一般不回收。 ZGC支持NUMA模型，UMA是在内存和 ...
JVM工作原理与实战(四十)：ZGC原理
Rye的博客
02-29 4208
JVM作为Java程序的运行环境，其负责解释和执行字节码，管理内存，确保安全，支持多线程和提供性能监控工具，以及确保程序的跨平台运行。本文主要介绍了ZGC、ZGC核心技术、ZGC的内存划分、ZGC的执行流程、分代ZGC的设计等内容。
关于垃圾收集器G1与ZGC
weixin_45925485的博客
10-28 4787
G1（Garbage-First）是一款面向服务器的垃圾收集器，主要针对配备多个处理器及大容量内存的机器，以极高概率满足GC停顿时间要求的同时，还具备高吞吐量性能的特征。G1将Java堆划分为多个大小相等的独立区域（Region），JVM最多可有2048个Region。 一般Region大小等于堆大小除以2048，如对大小为4096M，则Region大小为2M。-XX:G1HeapRegionSize：手动指定Region大小，推荐不指定，使用默认计算方式。G1保留年轻代和老年代的概念，但不再使用物理隔阂，
垃圾回收之ZGC
qq_40776617的博客
03-30 1782
ZGC是一种可伸缩、低延迟、高吞吐量的垃圾回收器，是JDK 11版本中引入的新特性。本文主要介绍ZGC及相关学习笔记。
Java 垃圾收集器详解：CMS, G1, ZGC
四楼没电梯的专栏
09-19 1940
选择合适的垃圾收集器需要综合考虑应用程序的特点和性能需求。如果需要最小化应用程序的停顿时间，可以选择 CMS 或者 ZGC；如果需要平衡吞吐量和停顿时间，则 G1 是一个不错的选择。对于大堆的应用，ZGC 和 Shenandoah 提供了极低的停顿时间，而 Parallel 和 ParNew 更适合需要高吞吐量的应用。未来随着 Java 技术的发展，新的垃圾收集器将会不断出现，以满足更多样化的需求。
JVM篇——G1、ZGC以及Shenandoah垃圾回收器详细介绍和底层算法展开分析，一篇文档，拿下常见经典的垃圾回收器！！！！！！
我热爱学习，也乐于分享。无论是科技前沿的洞见，还是生活中的小技巧，我都会在这里与你分享。我相信，知识就是力量，而分享则能让这份力量得到更好的传递。
01-23 3690
一、认识G1G1（Garbage-First）是一款面向服务端应用的垃圾收集器，主要针对配备多核CPU及大容量内存的机器。G1垃圾收集器的目标是满足GC停顿时间的同时，还兼具高吞吐量的性能特征。它主要特点如下：并行与并发：G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力。此时用户线程可能会短暂停顿（STW）。G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况。
ZGC 垃圾回收过程
若明天不见
11-26 1410
ZGC（Z Garbage Collector）是Java平台上的一种垃圾收集器，它是由Oracle开发的，旨在解决大堆的低延迟垃圾收集问题。ZGC是一种并发的分代垃圾收集器，它主要针对具有大内存需求和低停顿时间要求的应用程序。
垃圾回收算法、垃圾回收器CMS、G1、ZGC详解
earlybird_xiong的博客
10-10 3121
当前虚拟机的垃圾收集都采用分代收集算法，根据对象存活周期的不同将内存分为几块。一般将Java堆分为新生代、老年代，这样就可根据各代特点选择合适的垃圾收集器。新生代中，每次收集都会有大量对象（99%）死去，所以选择复制算法，只需少量对象的复制成本就可完成每次对象的垃圾回收。老年代的存活几率是比较高的，所以选择“标记-清除”或“标记-整理”算法进行垃圾收集。注意，“标记-清除”和“标记-整理”算法比复制算法慢10倍以上。
2-1-9、ZGC详解
技术，就是不断的深入～
10-29 1768
停顿时间不超过10ms（JDK16已经达到不超过1ms）停顿时间不会随着堆的大小，或者活跃对象的大小而增加支持8MB~4TB级别的堆，JDK15后已经可以支持16TB如果使用ZGC来做Java项目，像对STW敏感的证券系统，游戏的系统都可以去用Java来做（以前都是C或者C++的市场），所以ZGC的出现就是为了抢占其他语言的市场（卷！）
一文带你彻底弄懂ZGC
yxg520s的博客
10-22 1320
这是一种内存优化技术，通过减小对象引用的大小来减少内存占用和提高性能。在启用压缩指针的情况下，对象引用不再直接存储对象的实际内存地址，而是存储一个相对于某个基地址的偏移量。这允许使用更小的数据类型来存储引用，从而减小其大小。加载屏障是在读取对象引用时自动添加的。在ZGC中，每次应用线程尝试通过染色指针访问对象时，加载屏障都会介入。加载屏障的目的是确保即使在垃圾收集过程中对象被移动，应用线程也能够无缝地访问对象。
【Java虚拟机】简单易懂的ZGC原理分析
weixin_43889578的博客
04-14 2561
然后进入到下一轮垃圾收集时，就会使用M1标志位去标记存活的对象，那么在本轮垃圾收集中存活的对象的M1标志位就会被置为1，那么M1标志位没有被置为1的，就可以认为是垃圾对象，可以被清理，这里就包括了上一轮中存活的M0标志位被置为1的对象。有好处，自然也是有代价的。可以看到，有了染色指针和转发表，ZGC就可以在标记结束之后，就马上进行存活对象的转移了，并且用户线程是不需要停顿的，不需要停止用户线程等待存活对象转移完毕并且修正指针指向的值，也就没有了这部分STW的时间消耗，性能就大大提升了。
ZGC原理整理
luck_lsj的博客
04-28 1830
ZGC原理整理
六、ZGC深度剖析
空杯
12-11 1660
停顿时间不超过10ms（JDK16已经达到不超过1ms）停顿时间不会随着堆的大小，或者活跃对象的大小而增加；也就是说，几十G堆的停顿时间是10ms以下，几百G甚至上T堆的停顿时间也是10ms以下支持8MB~4TB级别的堆，JDK15后已经可以支持16TB最糟糕的情况下吞吐量会降低15%。这都不是事，停顿时间足够优秀。至于吞吐量，通过扩容分分钟解决。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值