go 的垃圾回收由运行时（runtime）内置的原生代码实现，不依赖虚拟机；它采用并行标记-清除算法，通过操作系统线程协作完成，而非 goroutine，且已大幅优化“停顿时间”，远优于传统 java 全量 gc。
Go 是一门编译型语言，源码直接编译为机器码，生成静态链接的原生二进制文件，没有 Java 那样的虚拟机（JVM）层。但这并不意味着 Go 缺乏运行时支持——恰恰相反，Go 自带一个高度集成、用 C 和汇编编写的 native runtime，它在程序启动时即驻留内存，负责调度 goroutine、管理内存布局、实现 channel、处理 panic，以及——最关键之一——执行垃圾回收（GC）。
垃圾回收的执行主体：OS 线程，不是 goroutine
GC 工作并非由某个 goroutine 承担，也不是用户可见的逻辑单元。自 Go 1.1 起，GC 进入并行（parallel）阶段；从 Go 1.5 开始全面转向并发（concurrent）标记-清除；Go 1.21 后进一步演进为增量式、低延迟的三色标记 + 混合写屏障（hybrid write barrier）。所有这些阶段均由 runtime 中的 C/汇编代码驱动，并通过 多个操作系统线程（OS threads）协同执行——例如，标记阶段可由多个 M（machine，即 OS 线程）并行扫描堆对象，清扫阶段也可并发清理。这与 JVM 中由 JVM 自身 native code（如 G1 或 ZGC 的 C++ 实现）调度线程执行 GC 的本质完全一致，只是 Go 的 runtime 更轻量、更紧密耦合于编译器。
// 示例：观察 GC 行为（需开启调试）
package main
import (
"fmt"
"runtime"
"time"
)
func main() {
// 强制触发 GC 并打印统计
runtime.GC()
var stats runtime.MemStats
runtime.ReadMemStats(&stats)
fmt.Printf("Last GC: %v, Next GC: %v MB\n",
time.Unix(int64(stats.LastGC/1e9), 0),
stats.NextGC/1024/1024)
}关于“Stop-the-World”（STW）
Go 的 GC 仍存在 STW，但极短：主要发生在标记开始前的根对象扫描（stack scan）和标记结束后的少量清理阶段。现代 Go（1.14+）已将 STW 控制在 百微秒级（< 100µs），对绝大多数服务无感。相比之下，经典 JVM 的 Serial 或 Parallel GC 在 Full GC 时可能 STW 数百毫秒甚至秒级；尽管 G1/ZGC/CMS 等也追求低延迟，但 Go 的设计目标更偏向“默认开箱即用的低延迟”，无需复杂调参。
Go GC 与 Java GC 的核心差异简析
| 维度 | Go GC | 典型 Java GC（如 G1） |
|---|---|---|
| 实现位置 | Go runtime 内置 native code（C/asm） | JVM 内置 native code（C++） |
| 并发模型 | 用户态 goroutine 与 GC 线程完全解耦；GC 使用 dedicated OS threads | JVM 管理 GC 线程池，与 Java 线程共享 OS 资源 |
| 触发时机 | 基于堆增长率（GOGC 默认 100，即堆增长 100% 触发） | 基于堆占用率、预测停顿时间、混合区域回收策略等 |
| 调优粒度 | 极简：仅 GOGC、GOMEMLIMIT（Go 1.19+）等少数环境变量 | 复杂：数十个 JVM 参数（-XX:+UseG1GC, -XX:MaxGCPauseMillis 等） |
| 延迟特征 | 可预测、稳定、默认极低 STW（µs 级） | 可配置但易受堆大小、对象图复杂度影响，波动较大 |
✅ 关键总结：Go 的 GC 不是“魔法”，而是由其 runtime 提供的一套高性能、低侵入、面向云原生场景深度优化的 native 垃圾回收系统。它不依赖 VM，却通过精巧的并发标记、写屏障、内存分配器（tcmalloc-like mheap/mcache）协同，实现了比多数 JVM 默认配置更平滑的延迟表现。开发者无需手动管理内存，也极少需要调优——这正是 Go “simplicity by design” 的体现。
