外观
GC、逃逸分析与内存
- 状态：未准备
- 适用方向：Go 全栈 / Go 后端
- 最近复习：待填写
- 下次复习：待安排
一句话回答
逃逸分析决定对象如何安全存活，GC 回收不可达堆对象；优化先区分分配速率、存活量与引用保留，再看 CPU 和延迟代价。
原理解释
Go GC 可从并发标记清扫、写屏障和短暂停顿理解，并不代表全程无 STW。栈、全局变量等根可达的对象不会因为“已经不打算用”就自动回收。
逃逸由编译器分析生命周期等因素，返回局部地址、闭包捕获和接口使用都应结合编译结果判断，不能一概断言。go build -gcflags='-m=2' ./... 查看提示，输出随工具链与内联而变。
GOGC 调节堆增长目标，常见取舍是更多内存换更低 GC 频率；GOMEMLIMIT 是运行时管理内存的软限制，不是进程 RSS 硬上限。设置过紧可能频繁 GC 并拖慢服务。
heap profile 区分 inuse_space（仍存活）与 alloc_space（累计分配）；两者增长对应的问题不同。RSS 还包括线程栈、运行时、cgo/外部映射等，不等于活跃 Go 堆。
场景与边界
全局 map 无界增长、切片保留大数组、goroutine 卡住持有大对象，都可能造成逻辑泄漏。sync.Pool 可以减少特定临时分配，但不保证保留对象，也不能不清理敏感数据就复用。
项目中的应用
结合 EinoTalk 长连接和 SimulSpeak 媒体处理，观察断连后的连接表、队列、缓冲区与 goroutine 是否回落，收益待测。
常见追问
- GC 语言还会泄漏吗？ 会，仍可达但不再需要的引用和未退出任务会保留资源。
- 手动 GC 能解决吗？ 不能释放仍可达对象，频繁调用还有成本。
- 优化先减所有分配？ 先找热点；减少小分配可能牺牲可读性而无明显收益。