Serial GC:
Parallel GC (也称为吞吐量优先收集器):
Concurrent Mark Sweep (CMS) GC (已废弃,但在某些旧版本JDK中可用):
G1 (Garbage First) GC:
Z Garbage Collector (ZGC):
Shenandoah GC:
概念解释:
具体来说,如果一个应用运行了100秒,其中98秒是在执行业务逻辑,而2秒用于垃圾回收,那么这个应用的吞吐量就是98%。
Parallel GC(也称作吞吐量优先收集器)即在牺牲一定GC停顿时间的前提下,使得应用程序能够更快地完成更多的任务。例如,在一个大数据处理或者高负载的服务器应用中,我们可能更关心在一段时间内能处理多少请求,而不是单个请求的响应时间。
吞吐量百分比可通过参数设置,默认情况下,如果不进行特殊配置,JVM的吞吐量目标是99%,这意味着目标是将99%的时间用于应用程序的执行,而只留1%的时间用于垃圾回收。
这里特指垃圾回收引起的停顿时间,即Stop-The-World(STW)事件的持续时间。低延迟意味着在垃圾回收期间,应用程序暂停的时间很短,这对于需要即时响应的交互式应用(如在线交易系统、游戏等)来说至关重要,因为长暂停会直接影响用户体验。
在垃圾回收器的设计中,吞吐量和延迟往往是相互制约的。例如,为了提高吞吐量,垃圾回收器可能会采取更激进的策略,如更少的垃圾回收频率,但这可能导致每次垃圾回收时的停顿时间变长,从而增加延迟。反之,为了降低延迟,可能需要更频繁但更轻量级的垃圾回收,这又可能降低了整体的吞吐量。
G1 目标是,在确保垃圾回收停顿时间可预测和可控(低延迟)的同时,尽可能维持较高的应用程序执行效率(高吞吐量)。这意味着,G1在设计上既考虑了如何高效地回收内存,减少内存管理对应用运行的影响,也考虑到了如何让应用在面临垃圾回收时的响应更加及时和可预测。这种平衡对于现代复杂多变的应用场景尤其重要。
简单理解:如果吞吐量为98%,停顿时间2%(垃圾回收时间),怎么来停顿这2%的时间,可一次停顿,也可多次停顿,需要平衡。
jdk8: 默认使用Parallel GC
jdk9: 从Java 9开始及之后的版本,默认使用G1