Golang啥时候会触发GC

Posted 2023-03-31

参考技术A Golang采用了三色标记法来进行垃圾回收，那么在什么场景下会触发这个回收动作呢？

源码主要位于文件 src/runtime/mgc.go go version 1.16

触发条件从大方面说，可分为 手动触发 和 系统触发 两种方式。手动触发一般很少用，主要由开发者通过调用 runtime.GC() 函数来实现，而对于系统自动触发是 运行时 根据一些条件判断来进行的，这也正是本文要介绍的内容。

不管哪种触发方式，底层回收机制是一样的，所以我们先看一下手动触发，根据它来找系统触发的条件。

可以看到开始执行GC的是 gcStart() 函数，它有一个 gcTrigger 参数，是一个触发条件结构体，它的结构体也很简单。

其实在Golang 内部所有的GC都是通过 gcStart() 函数，然后指定一个 gcTrigger 的参数来开始的，而手动触发指定的条件值为 gcTriggerCycle 。 gcStart 是一个很复杂的函数，有兴趣的可以看一下源码实现。

对于 kind 的值有三种，分别为 gcTriggerHeap 、 gcTriggerTime 和 gcTriggerCycle 。

运行时会通过 gcTrigger.test() 函数来决定是否需要触发GC，只要满足上面基中一个即可。

到此我们基本明白了这三种触发GC的条件，那么对于系统自动触发这种，Golang 从一个程序的开始到运行，它又是如何一步一步监控到这个条件的呢？

其实 runtime 在程序启动时，会在一个初始化函数 init() 里启用一个 forcegchelper() 函数，这个函数位于 proc.go 文件。

为了减少系统资源占用，在 forcegchelper 函数里会通过 goparkunlock() 函数主动让自己陷入休眠，以后由 sysmon() 监控线程根据条件来恢复这个gc goroutine。

可以看到 sysmon() 会在一个 for 语句里一直判断这个 gcTriggerTime 这个条件是否满足，如果满足的话，会将 forcegc.g 这个 goroutine 添加到全局队列里进行调度(这里 forcegc 是一个全局变量)。

调度器在调度循环 runtime.schedule 中还可以通过垃圾收集控制器的 runtime.gcControllerState.findRunnabledGCWorker 获取并执行用于后台标记的任务。

java基础—常用的GC策略，什么时候会触发YGC，什么时候触发FGC？

一、内存回收策略和常见概念

常见内存回收策略可以从以下几个维度来理解：

1 串行&并行 
串行：单线程执行内存回收工作。十分简单，无需考虑同步等问题，但耗时较长，不适合多cpu。
并行：多线程并发进行回收工作。适合多CPU，效率高。
2 并发& stop the world 
stop the world：jvm里的应用线程会挂起，只有垃圾回收线程在工作进行垃圾清理工作。简单，无需考虑回收不干净等问题。
并发：在垃圾回收的同时，应用也在跑。保证应用的响应时间。会存在回收不干净需要二次回收的情况。
3 压缩&非压缩&copy 
压缩：在进行垃圾回收后，会通过滑动，把存活对象滑动到连续的空间里，清理碎片，保证剩余的空间是连续的。
非压缩：保留碎片，不进行压缩。

copy：将存活对象移到新空间，老空间全部释放。（需要较大的内存。）

 

一个垃圾回收算法，可以从上面几个维度来考虑和设计，而最终产生拥有不同特性适合不同场景的垃圾回收器。

 

 

二、JVM的YGC&FGC

 

YGC ：对新生代堆进行GC。频率比较高，因为大部分对象的存活寿命较短，在新生代里被回收。性能耗费较小。

FGC ：全堆范围的GC。默认堆空间使用到达80%(可调整)的时候会触发FGC。以我们生产环境为例，一般比较少会触发FGC，有时10天或一周左右会有一次。

 

三、什么时候会触发YGC,什么时候触发FGC?

 

YGC的时机:

edn空间不足

FGC的时机：

1.old空间不足；

2.perm空间不足；

3.显示调用System.gc() ，包括RMI等的定时触发;

4.YGC时的悲观策略；

5.dump live的内存信息时(jmap –dump:live)。

对YGC的 触发时机，相当的显而易见，就是eden空间不足， 这时候就肯定会触发ygc

对于FGC的触发时机， old空间不足， 和perm的空间不足， 调用system.gc()这几个都比较显而易见，就是在这种情况下， 一般都会触发GC。

最复杂的是所谓的悲观策略，它触发的机制是在首先会计算之前晋升的平均大小，也就是从新生代，通过ygc变成新生代的平均大小，然后如果旧生代剩余的空间小于晋升大小，那么就会触发一次FullGC。sdk考虑的策略是， 从平均和长远的情况来看，下次晋升空间不够的可能性非常大， 与其等到那时候在fullGC 不如悲观的认为下次肯定会触发FullGC， 直接先执行一次FullGC。而且从实际使用过程中来看， 也达到了比较稳定的效果。