面试常问到Golang的GC，触发时机是个绕不过的坎。这个问题其实不难理解，不像某些材料说的那么悬乎。所谓的GC，垃圾回收机制，简单来讲，就是程序帮咱自动清理内存里的“垃圾”，不用咱们手动操心这事儿。但不代表咱们不需要知道它啥时候开始干活。
Golang选了三色标记法来做这事儿，听着玄乎，核心很简单：对象要么被引用，要么变成垃圾。问题来了，什么时候它才开始动手扫垃圾呢？别急，慢慢来。
GC什么时候会动手
Golang会在一定条件下触发GC。其中最常见的一种，堆内存分配时它会冒出来看看。Golang程序每回申请内存空间，底层代码都会先检查当前的内存情况。系统会确认一下，该不该趁这次内存分配，悄悄带上GC的事儿一块儿干了。时机往往就是你申请的内存接近系统觉得合理的“警戒线”的时候。
这里多说一句，"警戒线"可不是乱设的，它和前一次GC完了以后剩下的内存大小有关系。这么说吧，堆内存变大了，GC系统就警觉了，怕你浪费资源，一股脑申请大块大块内存，这就轮到GC出马清扫。其实呢，是个平衡资源的把戏。多了就扫，少了暂时不管。你可能会想，它这么盯梢，不累吗？嗯，这事儿底层操心，反正程序一占内存多，GC准上场。
你写程序有时也许碰到那种内存猛增的局面。比如说你一瞬间搞出成百上千个新对象，回头系统负荷飙升，那么这时候系统就很快把GC派出去了，防止场面失控。简而言之，玩命的分配就得有活干，它可不管你累不累。
再补充一个触发点，手工触发。咱程序员也不是吃素的，Golang其实也给你了自己手动出发GC的权力。不建议乱用，但是高手有时偶尔手动调调，也能达到效果。不过吧，注意分寸，懂得这个机制的乐趣就行了，干活还要尊重代码，轻易别跳出来干预系统自个儿的事儿。
还有些不易察觉到的情况
你不太容易感知的一种情况是后台周期性检查。GC不是老定在那儿的愣头青，代码有时候背后自个儿清闲的时候也会瞅两眼，不论当前程序分配了多少内存，只要觉得有空档期，也有可能的溜达出来练练手。频率如何，这和你程序实际使用资源、是否密集型任务有直接关系。可你也别盯着秒针算时间，毕竟这些时机也不会明显跳到你眼前来告诉你它干活了。
总结来看呢，GC这块说是说几点触发，实际上靠堆内存分配、负荷情况、开发者可能觉得不够也会从旁协作这类几方举动共同影响。每次结果可能看似不一样，但底层那双眼睛一刻不敢放松，推高内存就干预。平时写代码用心呗，合理把控对象生存周期。这段我知道语言略糙，都说到那了，嚼碎就能揣兜，不像读技术材料似的弄得太高深也不好呢。嘿嘿，开头我说不算难嘛，这看完你觉得感悟到没有？面试也能抵挡一下吧。不然咋能彰显自己对底层还关心到那细节层面呢。
