前几天运维同学在群里甩了张监控图，延迟从平时的50ms直接飙到500ms，而且是周期性的。我看了下，CPU正常，网络正常，数据库也没啥压力。最后发现是Go GC（垃圾回收器）在定期大扫除导致的性能问题。
这就像你开火锅店，生意好的时候服务员根本来不及收拾桌子，只能趁客人少的时候一口气全收拾完。收拾的时候新客人得在门口等着，体验就拉胯了。但Go的并发垃圾回收机制不这么干，它让服务员边接待客人边收拾桌子，客人几乎感觉不到餐厅在打扫卫生。这就是Go GC性能优化的核心秘密。
很多编程语言的垃圾回收都是这样：把所有客人请出去，也就是Stop The World，简称STW。然后服务员疯狂收拾，收拾完再开门营业。这期间客人只能在门口干等。Go的做法不一样，服务员边接待新客人边收拾空桌子。这就是并发标记（Concurrent Marking），GC线程和业务线程同时跑，谁也不耽误谁。
但这里有个问题，服务员一边收拾一边有新客人进来，怎么知道哪些桌子该收拾、哪些正在用？Go GC用了个办法叫三色标记算法。这是Go垃圾回收性能优化的关键技术。餐厅里的桌子贴三种颜色的标签：白色是空桌子可以收拾，灰色是客人刚离开还没检查是否有遗留物品，黑色是正在用的桌子别动。服务员从灰色桌子开始检查，有遗留物品说明还有人要用就标记成黑色，没有遗留物品就标记成白色准备收拾。最后所有白色桌子都被收拾掉（内存回收），黑色和灰色桌子继续服务客人。
还有个麻烦事，服务员正在检查某张灰色桌子，结果突然有客人坐下了。如果不记录，这桌子可能被误判成空桌给收拾掉，客人的东西就丢了。Go用写屏障（Write Barrier）解决这个问题，每当有人坐下（对象引用被修改）就在小本子上记一笔。GC扫描时看到小本子上的记录，就知道这桌子还在用不能收拾。虽然Go GC是并发的，但还是有两个短暂的停业时刻：开始前贴告示说准备打扫了别乱动（设置写屏障），结束后摘告示说打扫完了恢复正常（清除写屏障）。这两个时刻加起来通常只有几十微秒到几毫秒，客人基本感觉不到。
Go GC还会根据当前内存使用情况自动调整下次触发时机。服务生意火爆内存占用高GC就更频繁地打扫，生意冷清GC就放松点。这个行为由GOGC参数控制，默认值是100，意思就是当堆内存增长到上次GC后的2倍时触发下次GC。掌握GOGC调优技巧是Go性能优化的关键。
来点能跑的
启动Go程序时加上GODEBUG=gctrace=1就能看到GC的详细信息：
GODEBUG=gctrace=1 ./your-app
输出长这样：
gc 1 @0.017s 0%: 0.004+0.32+0.003 ms clock, 0.018+0.14/0.28/0.44+0.014 ms cpu, 4->4->3 MB, 5 MB goal, 4 P
别慌，只看几个关键数字就行。0.004+0.32+0.003 ms是总共暂停了0.34毫秒，包括前后两个STW和并发标记。4->4->3 MB是GC前4MB、GC中4MB、GC后3MB，也就是回收了1MB。5 MB goal是下次触发GC的目标是5MB。如果暂停时间飙到几十毫秒甚至上百毫秒，就得查查哪里出问题了。
默认GOGC=100对大多数场景够用，但有时候可能想调一调：
# 让GC更激进，更频繁但每次回收少
GOGC=50 ./your-app
# 让GC更懒，更少触发但每次回收多
GOGC=200 ./your-app
# 完全禁用自动GC，不推荐，除非你知道自己在干嘛
GOGC=off ./your-app
快速判断：内存够用、延迟是瓶颈，调高GOGC比如200减少GC频率；内存紧张、经常OOM，调低GOGC比如50让GC更积极回收。
想看详细的GC性能数据，用Go自带的pprof：
import (
"net/http"
_ "net/http/pprof"
)
func main() {
go func() {
http.ListenAndServe("localhost:6060", nil)
}()
// 你的业务代码
}
然后浏览器打开 http://localhost:6060/debug/pprof/heap，或者用命令行：
go tool pprof http://localhost:6060/debug/pprof/heap
进入交互模式后输入top，就能看到哪些函数占用内存最多。
生产环境会遇到的坑
火锅店桌子越来越多但客人没增加，服务员收拾不过来。这种情况GC频率越来越高但内存占用一直降不下来。可能是goroutine泄漏、全局变量持有大对象、或者slice底层数组没释放。用pprof找到内存占用大户，检查是否有不该长期存活的对象。
见过有个项目为了优化性能把GOGC=500，结果内存占用飙到几个GB最后OOM了。GOGC太大导致GC触发太晚内存积压太多。根据实际内存容量调整GOGC，别盲目调大。
Go对于大对象（超过32KB）会直接分配到堆上，不走正常的内存池。频繁分配大对象GC压力会很大，暂停时间也不稳定。可以复用大对象用sync.Pool、拆分大对象成小块、或者用mmap等方式绕过GC。
有时候服务在某个时间点准时卡顿。可能是定时任务触发分配了大量临时对象、缓存过期大量重建触发GC、或者日志切割数据同步等后台任务集中执行。可以错峰执行定时任务、分批处理数据别一次性加载太多、或者用runtime.GC()手动在低峰期触发GC。
Go GC是并发的，边营业边收拾，暂停时间极短通常几毫秒。GOGC别乱调，默认100够用，内存紧张调低延迟敏感调高。用工具而不是猜，gctrace看趋势pprof找问题，别凭感觉调参数。
给你个小抄：
# 查看GC详情
GODEBUG=gctrace=1 ./your-app
# 调整GC触发时机
GOGC=200 ./your-app
# 启动pprof
import _ "net/http/pprof"
http.ListenAndServe("localhost:6060", nil)
# 分析内存占用
go tool pprof http://localhost:6060/debug/pprof/heap
# 手动触发GC
runtime.GC()
你在生产环境遇到过最离谱的GC问题是什么？内存泄漏导致服务器半夜自杀重启，还是GOGC设置太大被运维骂了一顿？评论区说说你的踩坑故事。
常见问题FAQ
Q: Go GC的性能瓶颈在哪里？ A: 主要是STW时间和大对象分配。通过GOGC调优和sync.Pool可以显著改善。
Q: 三色标记算法会影响并发性能吗？ A: 不会。Go的并发垃圾回收机制设计就是为了最小化对业务线程的影响。
Q: GOGC参数应该设置多少？ A: 默认100适合大多数场景。内存充足可以调到200，内存紧张调到50。
Q: 如何监控Go GC性能？ A: 使用GODEBUG=gctrace=1查看GC详情，用pprof分析内存占用。
觉得有用？这篇文章帮你搞懂了Go GC的运作原理或者避开了某个坑，不妨点个赞让更多遇到GC问题的朋友看到，转发给同事特别是那些还在用GOGC=off的勇士，关注梦兽编程后面聊Go性能优化、零停机部署这些实战话题，评论区留言分享你的GC调优经验或疑问。
你的支持是我继续写下去的动力。