垃圾收集器G1和ZGC

G1垃圾收集器详解G1的基本结构将堆内存划分为多个大小相等的Region默认2MB。每个Region可动态扮演Eden、Survivor或Old区角色。支持巨型对象Humongous Region占用连续多个Region。G1的垃圾回收阶段初始标记Initial MarkSTW标记GC Roots直接关联的对象。并发标记Concurrent Mark并发执行标记存活对象。最终标记Final MarkSTW处理并发标记期间变化。筛选回收Live Data Counting and Evacuation回收部分Region基于最大停顿时间控制。复制算法与空间整合使用复制算法减少内存碎片。回收过程中将存活对象复制到新Region原Region清空后可供后续使用。回收优先级与收益比计算维护一个回收优先级列表选择回收效益最高的Region。根据存活对象数量估算回收时间确保不超过设定的最大停顿时间。G1的关键参数与调优建议开启G1的参数-XX:UseG1GCRegion大小设置-XX:G1HeapRegionSize必须为2的N次幂默认2MB。最大停顿时间目标-XX:MaxGCPauseMillis默认200ms可通过调整控制GC行为。新生代比例控制初始比例-XX:G1NewSizePercent默认5%最大比例-XX:G1MaxNewSizePercent默认60%混合回收阈值-XX:InitiatingHeapOccupancyPercent默认45%老年代占用达到此比例触发Mixed GC。回收收益比控制参数-XX:G1MixedGCCountTarget默认8次筛选回收-XX:G1MixedLiveThresholdPercent默认85%G1的应用场景与性能特点适合大内存、高吞吐量场景推荐在堆内存大于6~8GB时使用。在JDK9之后成为默认垃圾收集器。与CMS对比G1内部机制更复杂但能更好地控制最大停顿时间。CMS效率在小内存下可能更高但在大内存下易出现Full GC导致OOM。G1的劣势内部算法复杂带来一定开销。JDK8中优化尚不完善JDK9之后逐渐成熟。G1实战案例分析高并发系统中的G1应用如Kafka、RocketMQ等消息中间件每秒处理数十万条消息。堆内存推荐设置为32GB以上年轻代分配较大空间以容纳瞬时大量对象。G1通过控制最大停顿时间如100ms避免因GC造成业务响应延迟。G1的响应式设计优势边处理业务边回收垃圾降低单次STW时间。提升用户体验避免发送端超时等问题。ZGC核心概念与特性ZGC支持的版本与平台JDK11开始支持仅限Linux x64。JDK14起支持Windows平台。ZGC的目标特性支持TB级堆内存JDK11支持4TBJDK13支持16TB。最大GC停顿时间10ms。吞吐量下降不超过15%。面向未来GC功能的基础架构。ZGC的运作流程四大阶段并发标记Concurrent Mark初始标记并发扫描最终标记。预分配阶段Prepare for Relocate确定哪些Region需要回收。并发重分配Concurrent Relocate将存活对象复制到新Region。并发重映射Concurrent Remap更新所有引用指向新地址。所有阶段几乎都并发执行只有少量短暂停阶段Initial Mark和Final Mark。实现低延迟适用于大规模内存环境。ZGC关键技术颜色指针与读屏障颜色指针Color Pointers使用64位指针中的高位存储GC标记信息如白、灰、黑。寻址空间为低42位支持4TB内存JDK13扩展至44位支持16TB。读屏障Load/Read Barrier在并发重分配阶段应用程序线程读取老对象时自动触发更新引用。引用更新依赖转发表Forwarding Table记录的新旧地址映射。实现惰性更新提升整体效率。ZGC与G1的区别总结分代 vs 不分代G1保留逻辑上的分代概念。ZGC完全不分代统一管理整个堆内存。并发程度G1的筛选回收阶段仍需STW。ZGC所有阶段均并发执行STW时间极短。对象迁移与引用更新机制G1在GC过程中同步更新引用。ZGC采用读屏障异步更新提升并发能力。ZGC的适用与局限性当前主流公司尚未广泛采用多数企业仍在使用JDK8 CMS或G1。ZGC仍处于实验阶段Experimental稳定性待验证。面试考察重点主要涉及颜色指针、读屏障、并发回收机制等概念。不会深入源码实现理解其设计理念即可。垃圾收集器演进趋势从CMS到G1再到ZGCCMS为基础G1做改进ZGC进一步提升并发能力。未来方向自适应与智能化垃圾收集器越来越智能用户调优需求减少。底层实现复杂化但对外接口简化。