eBPF可捕获Go runtime的GC STW事件，需Go 1.20+带DWARF信息、Linux 5.8+支持uprobe；抓runtime.stopTheWorldWithSema比gcStart更准，能定位具体停顿时刻、时长及上下文，弥补pprof和Prometheus指标缺失的时间线因果链。
用 eBPF 抓取 Go runtime 的 GC 事件，不改代码也能看到 STW
Go 的 GC 停顿（尤其是 STW 阶段）无法靠 pprof 或 Prometheus 暴露的 go_gc_duration_seconds 直接定位到具体哪次停顿、持续多久、触发原因。eBPF 可以绕过应用层，在内核或用户态函数入口处挂钩子，实时捕获 runtime.gcStart、runtime.stopTheWorld 等关键符号调用。
前提是你用的是 Go 1.20+ 编译的二进制（带 DWARF 调试信息），且运行在支持 uprobe 的 Linux 内核（5.8+）上。OpenTelemetry eBPF Instrumentation（OBI）目前不覆盖 GC 事件，得自己写或用成熟工具如 bpftrace 或 parca-agent。
bpftrace -e 'uprobe:/path/to/your-binary:runtime.gcStart { printf("GC start at %d\n", nsecs); }'- 若符号被 strip 过，需先用
go build -gcflags="all=-l" -ldflags="-s -w"保留调试信息（生产环境慎用-l，但排查时必须） - 注意：Go 的 STW 实际由
runtime.stopTheWorldWithSema触发，抓这个比gcStart更贴近真实停顿起点
为什么不能只看 go_gc_duration_seconds？
这个 Prometheus 指标是 Go 自身通过 runtime.ReadMemStats 汇总上报的，它只记录每次 GC 的“总耗时”，且采样间隔通常为 10–30 秒——这意味着短于采样周期的 STW（比如 200μs 的 mark termination）会被吞掉，或和下一次合并统计。更关键的是，它完全丢失上下文：当时 Goroutine 数、堆大小突增来源、是否因 netpoll 唤醒延迟导致调度器卡住进而拉长 STW。
eBPF 能补上这层缺失：
立即学习“go语言免费学习笔记（深入）”；
- 在
runtime.mallocgc入口打点，关联分配地址与调用栈，快速识别大对象突发分配（比如未复用的[]byte） - 挂钩
runtime.schedule，观察 GC 后 Goroutine 是否批量堆积在 runq，判断是否调度器响应滞后 - 结合
tracepoint:sched:sched_switch，看 STW 前后是否有大量线程卡在D状态（不可中断睡眠），指向内核锁争用而非 GC 本身
实际排查中容易忽略的三个硬坑
很多团队跑通了 eBPF 脚本却得不到有效数据，问题往往不在脚本本身：
- Go 程序启动时加了
GODEBUG=madvdontneed=1，会导致内存页回收行为改变，eBPF 挂的uprobe在 mmap 区域可能失效——换用uretprobe或检查/proc/<pid>/maps确认符号所在段可执行 - 容器里运行时没挂载
/sys/kernel/debug，或者security.bpf被禁用（Kubernetes 默认限制），perf_event_open系统调用直接返回EPERM - 用
perf或ebpf_exporter采集时，默认只抓 kernel space，而 Go runtime 符号全在 user space，必须显式启用uprobes并指定二进制路径（不是容器内路径，是宿主机上的实际路径）
对比传统方式：pprof profile 和 eBPF trace 的分工边界
别指望 eBPF 替代 pprof。它们解决不同层次的问题：
-
pprof -http适合分析单次 GC 后的堆对象分布、逃逸分析结果、goroutine 阻塞点——这是“静态快照” - eBPF 适合回答“过去一小时里，第 7 次 STW 是谁触发的？前后 10ms 内有没有系统调用阻塞？有没有其他进程在同时刷脏页？”——这是“时间线因果链”
- 真正有效的排查是串联两者：用 eBPF 定位到某次异常 STW 时间戳 → 用
kill -SIGUSR2 <pid>触发该时刻的runtime/pprof/heapdump → 对比前后差异
最常被跳过的细节：Go 的 GC 触发阈值受 GOGC 和当前堆增长率共同影响，eBPF 只能告诉你“它发生了”，而 pprof 告诉你“为什么发生”。两者缺一不可。
