JVM垃圾收集器

参考文献:周志明《深入理解Java虚拟机》第二版

垃圾收集器就是 GC 具体的实现,不同厂商,不同版本,针对虚拟机不同的分区都有不一样垃圾收集器

图. 基于JDK 1.7 update 14的 HotSpot虚拟机包含的收集器
这里写图片描述

Serial 收集器

这个收集器是一个单线程收集器,在它进行收集工作时,必须暂停其他所有的工作线程,直到收集结束,这种工作方式又被称为“Stop the World”
它采用 复制算法
因为单线程,所以会造成停顿,但也使得它简单而高效
适用于新生代 Minor GC
是运行在 Client 模式下的虚拟机的一个最佳选择

Serial Old 收集器

它是 Serial 收集器的老年代版本,也是一个 单线程 收集器
应用 标记-整理算法
应用于老年代 Full GC
主要用于 Client 模式下

图. Serial / Serial Old收集器运行示意图
Serial / Serial Old收集器运行示意图

ParNew 收集器

它是 Serial 收集器的 多线程

注意区分:
并行(Parallel):指多条垃圾收集线程并行工作,但此时用户线程仍然处于等待状态
并发(Concurrent):指用户线程与垃圾收集线程同时执行(但不一定是并行的,可能会交替执行),用户程序在继续执行,而垃圾收集程序运行在另一个CPU上

采用 复制算法
应用于新生代 Minor GC
适用于 Server 模式

图. ParNew / Serial Old 收集器运行示意图
这里写图片描述

Parallel Scavenge 收集器

它是一个 多线程 收集器
采用 复制算法
应用于新生代 Minor GC
特点:可控制吞吐量

吞吐量(Throughput):CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值
吞吐量 = 运行代码时间 / (运行代码时间 + GC 时间)

提供设置参数:
-XX:MaxGCPauseMillis 控制最大 GC 停顿时间
-XX:GCTimeRatio 直接设置吞吐量大学
-XX:+UseAdaptiveSizePolic 动态自适应调整

它无法与 CMS 收集器配合工作,因为 CMS 收集器关注尽可能缩短 GC 时用户线程的停顿时间,与 Parallel Scavenge 的可控吞吐量不合

Parallel Old 收集器

它是 Parallel Scavenge 收集器的老年代版本
是一个 多线程 收集器
采用 标记-整理算法
应用于老年代 Full GC
经常与 Parallel Scavenge 配合,以充分达到“吞吐量优先”的作用

图. Parallel Scavenge / Parallel Old 收集器运行示意图
这里写图片描述

CMS 收集器

CMS(Concurrent Mark Sweep)收集器是一种以以获取最短回收停顿时间为目标的收集器
应用 标记-清除算法
它是一种 单线程与多线程结合使用 的收集器
收集步骤:

  1. 初始标记(CMS initial mark):在这个阶段中,程序中所有的工作线程都将会因为 STW 机制而出现短暂的暂停,这个阶段的主要任务仅仅是标记出 GC Roots 能直接关联到的对象,一旦标记完成就恢复运行,因此速度很快。
  2. 并发标记(CMS concurrent mark):从 GC Roots 的直接关联对象开始遍历整个对象图的过程,这个阶段耗时长但不需要停顿用户线程。
  3. 重新标记(CMS remark):这个阶段主要是为了修正并发标记期间,因为用户线程继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段也是 STW 但是速度很快。
  4. 并发清除(CMS concurrent sweep)

初始标记、重新标记仍然要“Stop the world”
CMS 收集器最大的优点就是 大大减少了停顿时间
但是,它也有三个明显的缺点:

CMS 收集器对 CPU 资源敏感:它的并发清理虽然不会造成停顿,但是会占用 CPU 资源,导致用户程序变慢吞吐量低
CMS 收集器无法处理浮动垃圾(Floating Garbage):因为清理过程是并发的,所以在清理过程中用户也会产生垃圾,这些垃圾叫做浮动垃圾,CMS无法清理,只能等到下一次清理
③ CMS 应用“标记-清除算法”(为了快速),所以会造成空间碎片

图. CMS收集器运行示意图
这里写图片描述

G1 收集器

G1(Garbage-First)收集器可以说是目前最先进的收集器了,它具有如下特点:

  • 并行与并发
  • 分代收集
  • 空间整合
  • 可预测停顿

G1 收集器的先进之处在于,它几乎完全区别于以往收集器的思想,它改变了 Java 堆的格局,它将整个 Java 堆分为多个大小相等的独立区域(Region),虽然还保留有新生代和老年代的概念,但新生代与老年代不再是物理隔离的了,它们都是一部分 Region (不需要连续)的集合
G1 收集器能够预测停顿时间,是因为它可以有计划地避免在整个 Java 堆中进行全区域的垃圾收集,它跟踪各个 Region 里面的垃圾堆积的价值大小,在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的 Region

收集步骤:

  1. 初始标记(Initial Marking)
  2. 并发标记(Concurrent Marking)
  3. 最终标记(Final Marking)
  4. 筛选回收(Live Data Counting and Evavcuation)

前几步与 CMS 收集器非常相似,最后的筛选回收,就是从优先列表中根据预测停顿时间选择回收

图. G1 收集器运行示意图
这里写图片描述

G1 从 Java7 中实验性加入,在 Java9 后成为默认回收器。

### JVM垃圾收集器的工作原理 JVM中的垃圾收集器负责自动管理和释放不再使用的内存资源。这一过程对于维护Java应用程序的性能至关重要[^1]。垃圾收集的主要目标是在不影响应用正常运行的前提下尽可能高效地回收无用对象所占有的空间。 #### 垃圾收集器类型及其特性 多种类型的垃圾收集器存在于现代版本的JVM中,每种都有各自的设计理念来适应特定应用场景下的需求: - **Serial GC**:适用于单核处理器的小规模应用环境,在年轻代采用复制算法,在老年代则使用标记-整理算法。 - **Parallel GC (也称为Throughput Collector)**:专为多CPU系统设计,旨在最大化吞吐量,即完成更多有用工作的比例相对于总执行时间而言。该收集器同样区分新生代与年老代,并分别运用不同的清理策略以达到最佳效果。 - **CMS (Concurrent Mark-Sweep) GC**:专注于降低暂停时间而非整体效率,适合于那些对响应速度敏感的服务端程序。它可以在后台逐步扫描存活对象并清除死亡对象而不必完全停止整个应用程序进程。 - **G1 (Garbage First) GC**:自JDK 7更新版引入以来成为默认选项之一,特别擅长处理具有大量活跃数据的大容量堆配置。G1将整个堆划分为多个固定大小的区域(region),并通过预测哪些地区最有可能包含可回收的空间来进行优先级排序。 - **ZGC 和 Shenandoah GC**:这两种新型低延迟垃圾收集器是从JDK 11开始加入的支持超大型堆(可达数TB级别)的同时具备亚毫秒级别的短暂停滞特性的工具[ZGC][^5]。它们都采用了先进的并发技术使得大部分垃圾回收活动能够在不停止用户线程的情况下发生。 ### 如何选择合适的垃圾收集器? 选择最适合项目需求的垃圾收集器取决于具体的应用场景以及期望达成的目标。如果追求最高的吞吐率,则可能倾向于使用`Parallel GC`; 若更看重快速反应时间和较低的停顿频率,那么像`CMS`, `G1`, 或者最新的`ZGC/Shenandoah`可能是更好的选择。值得注意的是,“最优”的方案并非永恒不变——随着业务逻辑的发展和技术进步,原先选定的最佳实践可能会变得不合适,因此定期审查当前设置总是明智之举[^2]。 ### 性能调优建议 为了使选中的垃圾收集器发挥最大效能,可以通过调整一系列参数来进行精细化控制。这包括但不限于设定初始/最大堆尺寸(-Xms/-Xmx), 新生代占比(-XX:NewRatio), 生存阈值(-XX:+UseAdaptiveSizePolicy,-XX:MaxTenuringThreshold)等。此外,启用详细的日志记录功能可以帮助诊断潜在瓶颈所在之处,从而指导后续改进措施的方向。最终目的是找到一个平衡点,在满足服务等级协议(SLA)关于响应时间和吞吐量的要求之间取得良好折衷。 ```bash java -Xms512m -Xmx4g -XX:+UseG1GC MyApplication ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值