不能直接 trace go gc 函数，因为 runtime.gcstart 等符号不导出、地址随机、无稳定 abi，kprobe 无法可靠挂载；可行方案是监控 mmap/madvise 系统调用并结合 /debug/pprof/gc 或 runtime.readmemstats 辅助对齐 gc 时间线。
Go 程序的 GC 行为无法通过 eBPF 直接 hook runtime.gcTrigger 或类似函数——这些是 Go 运行时内部符号，不暴露在内核符号表中，且地址随机、无稳定 ABI。你不能用 kprobe 挂到 runtime.gcStart 上并指望它在所有 Go 版本/构建下稳定工作。
为什么不能直接 trace Go GC 函数
eBPF 的 kprobe/tracepoint 机制依赖内核可导出的符号或预定义事件。Go 运行时的 GC 相关函数（如 gcStart、gcMarkDone、stopTheWorld）属于用户态动态链接库（libgo 或静态链接进二进制），既不在 /proc/kallsyms 中，也不受 CONFIG_KPROBE_EVENTS 支持。尝试对它们 attach kprobe 会返回 no such device 或静默失败。
- Go 1.20+ 默认启用
-buildmode=pie，函数地址 ASLR 化，kprobe offset 计算不可靠 - 即使强制用
-ldflags="-extldflags=-no-pie"构建，runtime.*符号仍被 Go linker strip 掉，objdump -t查不到有效符号 - libbpf-go 加载时若指定不存在的 kprobe 点，
LoadProgram会返回invalid argument，而非报错提示“符号未找到”
真正可行的监控入口：系统调用与内存分配行为
GC 触发本质是堆增长触发阈值，而堆增长反映在系统调用层面：Go runtime 最终通过 mmap、brk（已弃用）、madvise（归还内存）与内核交互。这些是稳定、可观测的内核事件。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 监控
sys_enter_mmap+sys_exit_mmap：识别每次 heap 扩容动作，结合prot参数是否含PROT_WRITE | PROT_EXEC（Go 堆页通常只设PROT_READ | PROT_WRITE） - 监听
sys_enter_madvise中advice == MADV_DONTNEED：这是 Go runtime 归还闲置 span 给操作系统的信号，对应 GC 后的“scavenge”阶段 - 避免抓
sys_enter_brk：现代 Go 已完全弃用sbrk，该事件在 Go 程序中几乎不会出现 - 注意过滤：同一进程可能有大量 mmap（如加载 so、mmap 文件），需用
pid+len+prot组合判断是否为堆扩张（典型 len ≥ 2MB，prot = 3）
从用户态辅助获取 GC 时间线
Go 提供了稳定的运行时指标接口，应与 eBPF 数据交叉验证，而非替代：
- 读取
/debug/pprof/gc（需开启net/http/pprof）可获得最近 N 次 GC 的精确时间戳、暂停时长、堆大小变化；但它是采样式，非实时流 - 通过
runtime.ReadMemStats获取NumGC、PauseNs、HeapAlloc，每秒轮询并写入 perf event map，再由 eBPF 程序关联 mmap/madvise 事件时间戳 - 关键字段对齐：
runtime.MemStats.PauseNs是纳秒级数组，末尾为最新 GC 暂停，需用atomic.LoadUint64(&m.PauseNs[(m.NumGC-1)%len(m.PauseNs)])安全读取 - 不要在 eBPF 程序里解析 Go 运行时结构体（如
mheap_）：字段偏移随 Go 版本剧烈变动，btfgen不支持 Go runtime BTF 生成
一个实际能跑通的 perf event 关联方案
目标：当发生一次 madvise(MADV_DONTNEED) 时，标记它是否紧邻一次 GC 结束（误差
- eBPF 端：用
struct { pid_t pid; u64 ts; u64 addr; u64 len; }格式向 perf event map 写入madvise事件，ts来自bpf_ktime_get_ns() - Go 用户态：启动 goroutine 每 5ms 调用
runtime.ReadMemStats，提取NumGC和最新PauseNs时间戳（需换算为单调时钟），写入另一个 ring buffer 或共享内存 - 用户态聚合器（独立进程）：同时消费 perf event map 和 GC 时间戳流，按
pid分组，计算madvise.ts - gc_end_ts差值，输出“scavenge 延迟”指标 - 陷阱：不要用
gettimeofday()对齐时间戳——eBPF 用ktime，用户态必须用clock_gettime(CLOCK_MONOTONIC, ...)，否则跨 CPU 时钟漂移可达毫秒级
最易被忽略的是时间源一致性：哪怕 eBPF 程序逻辑完美，只要用户态用 time.Now() 去对齐 bpf_ktime_get_ns()，整个关联就失效。这不是精度问题，是根本不可比。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
