在 Go 1.3 之前，运行时采用了分段栈，在函数调用边界分割成链接块。这种设计在紧密循环中频繁跨越栈边界时造成了严重的“热分裂”性能瓶颈。Go 1.3 用连续栈替代了这一设计，在增长过程中将栈复制到更大、单一的连续区域。然而，早期实现的连续栈从未将内存释放回堆中，导致强烈需要深调用栈的 goroutine 在初始化或批处理期间出现永久的 RSS 增长。Go 1.5 引入了自动栈收缩机制，在垃圾回收周期中回收未使用的栈内存，完成了 goroutine 栈的内存管理生命周期。
没有收缩机制的情况下，暂时进入深递归的 goroutine（例如，处理深层嵌套的 JSON 文档或遍历复杂的依赖树）将无限期保留其峰值栈分配，即使在返回空闲事件循环之后。这导致长期运行的应用程序出现内存膨胀，尤其是那些使用工作池的应用程序，其中 goroutine 在高栈任务和空闲状态之间交替。挑战在于安全识别何时栈确实未充分利用，并在不破坏正在进行的计算、栈分配指针或违反 ABI 调用约定要求的情况下，将活动帧重新定位到更小的内存区域。
Go 运行时在 GC 标记阶段收缩栈，当扫描根集时。它检查每个 goroutine 的栈使用情况；如果所利用部分的高水位线低于当前分配栈大小的四分之一（25%），运行时将分配一个当前栈大小一半的新栈（但不会小于最小的 2KB）。然后，运行时在安全点异步停止目标 goroutine，将活栈帧复制到新较小的区域，使用编译器生成的指针映射更新所有引用栈地址的内部指针，并将旧栈内存释放回运行时的 mheap 分配器。
我们经营一个高吞吐量的日志处理服务，每个 goroutine 处理可能深度嵌套的 JSON 有效负载解析（在输入攻击中最多达到 10,000 层深）。处理后，这些 goroutine 返回到 sync.Pool 以等待新连接。我们观察到，与池中 goroutine 的数量成线性关系，该服务的 RSS 内存持续增长，即使在空闲期间也从未释放内存，最终导致场景在 4GB 限制的容器中触发 OOM 杀死，尽管实际工作集仅为 200MB。
我们考虑在处理请求数达到设定值后强制杀死池中的 goroutine 并生成新的替代品。这将确保栈内存释放，因为新 goroutine 从最小的 2KB 栈开始。然而，这种方法导致了不断创建和销毁 goroutine 的显著 CPU 开销，破坏了 TCP 连接池优化，并由于缓存冷启动导致了更高的延迟尾分布。
通过 debug.SetMaxStack 实施栈增长硬限制将防止在深递归事件期间的过度分配。虽然这防止了 OOM，但合规的但深度解析任务因 runtime: goroutine stack exceeds 1000000000-byte limit 而发生恐慌。这导致了客户数据丢失和违反我们可靠性 SLA 的服务错误，使其在生产环境中不可接受。
我们评估了每 30 秒定期调用 runtime.GC() 然后执行 debug.FreeOSMemory()，以强制栈扫描和收缩。这成功地减少了 RSS，但在每次调用时引入了 5-10ms 的全球暂停，这违反了我们 API 层的 p99 延迟要求 <2ms，并由于强制完整收集而增加了 15%的 CPU 利用率。
最终，我们依赖 Go 的本机栈收缩机制，确保我们运行 Go 1.20+ 并调优 GOGC 以触发更频繁的垃圾回收（将其设置为 50 而不是 100）。这增加了无须手动干预的栈收缩机会。我们还重新构建了解析器，以使用迭代方法和显式堆分配栈进行路径跟踪，将最大递归深度从 10,000 降低到 100。这种组合使得自然收缩频繁发生，从而保持内存限制。
该服务的 RSS 在负载下稳定在大约 800MB，远低于之前的 3.8GB 上限。 goroutine 栈配置文件显示，95% 的池中工作者在请求间保持最小的 2KB 栈大小，仅在活跃解析期间出现峰值。 OOM 杀死完全停止，p99 延迟保持在 1.5ms 以内，因为我们避免了手动 GC 暂停和 goroutine 消耗。
栈收缩是否在函数返回时立即发生，栈指针降低？
否，运行时并未实时监控栈指针的减少以触发即时去分配。收缩仅在垃圾回收标记阶段进行，当调度程序扫描所有 goroutine 栈时，运行时检查自上次 GC 以来栈使用的高水位线。如果这个高水位线低于当前物理分配的 25%，收缩逻辑才会执行。这种懒惰评估摊销了在世界已经暂停进行标记的期间跨所有 goroutine 复制栈的成本，不过实际复制需要停止个体 goroutine 的执行。
确切的收缩比例和最小大小是多少，运行时是否会将内存释放回操作系统？
当栈符合收缩条件时，运行时会分配一个新的栈，其大小为当前栈的一半。这种几何减少防止了 thrashing，其中来回波动略高于和低于阈值的 goroutine 会不断增长和收缩。新大小下界受平台的最小栈大小限制，通常在 64 位系统上为 2KB。旧栈的内存返回给运行时的 mheap，而非直接返还给操作系统。操作系统仅在清理器确定堆闲置并超过目标时或调用 debug.FreeOSMemory() 时回收此物理内存。
栈收缩时 goroutine 会被停止吗，指针如何更新？
是的，收缩需要在安全点停止目标 goroutine，类似于栈增长。运行时必须将活帧复制到新内存位置，并更新所有引用栈分配变量的指针。编译器生成指针映射，以识别每个帧中的哪些字是指针。在收缩过程中，运行时使用这些映射找到并调整内部指针，使其指向新的栈地址。这个操作不是并发的；在复制过程中，goroutine 不能执行，但其他 goroutine 可以继续运行。