OpenJDK源码赏析之七（JVM垃圾回收器概述）

星空_MAX

已于 2022-05-05 11:29:12 修改

阅读量2k

点赞数

文章标签： java 开发语言

于 2022-05-04 12:52:05 首次发布

本文链接：https://blog.csdn.net/qq_36653924/article/details/124567845

版权

Java的垃圾回收器（GC）带来了自动内存管理的便利，降低了程序员的工作负担，但也牺牲了部分性能。从SerialGC到G1，再到ZGC和ShenandoahGC，GC不断演进以优化延迟和性能。虽然在高响应需求的场景中C/C++仍占优势，但随着硬件性能提升，Java在服务器端的应用日益广泛。GC的发展历程反映了Java在平衡开发者效率与系统性能上的努力。

摘要由CSDN通过智能技术生成

使用JVM垃圾回收器的优劣

在传统的C/C++开发中，程序员需要亲手对内存中的空间开辟和进行释放，当内存忘记回收就容易内存溢出，就算记得回收，但是指向给内存的指针没有释放，程序也会崩溃或者异常，其他问题更是数不胜数，堪称究极折磨了

以企业的角度看，C/C++程序员需要大量时间培养也很难写出安全的代码，企业更希望降低成本，希望来的程序员能立马上手干活，所以开始大量使用Java，降低企业的开发成本

以程序员的角度来说Java能让程序员避免和一些“未知敌人”搏斗（比如说Java直接屏蔽了指针，程序员很难写出不安全的代码），从而更好的释放生产力写业务逻辑

Java的一个特性就是有GC(Garbage Collector)，Java这种语言的优势和劣势核心都体现在Garbage Collector中

在GC中，jvm负责内存的自动管理和回收，但是每隔一段时间就要扫描一遍内存表看看哪块内存需要回收，替程序员去做了这些问题，但是牺牲了性能，由于这一个特性，高响应和高性能需求的场景还是C/C++主导

比如说游戏客户端，想想在垃圾回收的时候画面需要卡顿一下，是挺难让人接受的

比如自动驾驶，汽车快撞墙了，这时候GC卡顿一下，可不完犊子了

但是事无定论，《我的世界》就是Java开发的，虽然后面出了用C++重构的“基岩版”，但是后者在性能方面优化强于前者，能在更差的设备上运行

从服务器角度来说，现在者两种语言都差不多了，因为随着设备性能的提高，拿对性能要求比较高的网络游戏服务器来说，花费在网络传输的延迟远大于逻辑处理的时间，性能瓶颈在网络上而不在那点处理时间上面

JVM垃圾回收器的历史

1999年随JDK1.3.1一起来的是串行方式的Serial GC,它是第一款GC。ParNew垃圾收集器是Serial收集器的多线程版本。
2002年2月26日,Parallel GC和Concurrent Mark Sweep GC跟随JDK1.4.2一起发布。
Parallel GC在JDK6之后称为HotSpot默认GC。
2012年,在JDK1.7u4版本中,G1可用。
2017年,JDK9中G1编程默认的垃圾收集器,以替代CMS。
2018年3月,JDK10中G1垃圾回收器的并行完整垃圾回收,实现并行性来改善最坏情况下的延迟。
2018年9月,JDK11发布。引入Epsilon垃圾回收器,又称为"No-Op(无操作)"回收器。同时,引入ZGC: 可伸缩的低延迟垃圾回收器(Experimental)。
2019年3月,JDK12发布。增强G1,自动返回未用堆内存给操作系统。同时,引入Shenandoah GC: 低停顿时间的GC(Experimental)。
2019年9月,JDK13发布。增强ZGC,自动返回未用堆内存给操作系统。
2020年3月,JDK14发布。删除CMS垃圾回收器。扩展ZGC在macOS和Windows上的应用。