libbpfgo加载多个eBPF程序需为每个独立.o文件创建单独BPFObject，共享map须显式获取复用，名称冲突须加版本后缀，生命周期用errgroup管理并反序卸载。

如何用 libbpfgo 同时加载多个 eBPF 程序

libbpfgo 是当前 Go 生态中最稳定、最贴近内核 libbpf 行为的绑定库，管理多个程序的核心在于避免 struct bpf_object 冲突和 map 重名。它不支持单个 *libbpfgo.BPFObject 多次调用 Load() 加载不同 ELF，必须为每个独立程序创建单独对象。

• 每个 eBPF 程序（哪怕只差一个函数名）都应编译为独立的 .o 文件，并各自调用 libbpfgo.NewModule()
• 若多个程序共享 map（如 perf ring buffer 或 hash map），需显式设置 bpf_map_def.type = BPF_MAP_TYPE_PERF_EVENT_ARRAY 并在 Go 侧用 module.GetMap("map_name") 获取后复用，不能靠名字自动关联
• 加载顺序有影响：依赖其他程序 map 的程序（如 tracepoint + uprobe 协同），必须先加载被依赖方，否则 libbpf_load_program(): Invalid argument

如何防止多个 eBPF 程序的 map 名称冲突

eBPF map 名称在内核中是全局作用域，同名即覆盖——不是报错，而是后加载的静默替换前者的 map 实例，极易引发数据错乱或 panic。

• 务必在 C 侧用 #define MAP_NAME(x) x##_v1 类宏或构建时注入版本标识（如 -DMAP_NAME_SUFFIX=_netflow_v2）
• Go 侧不要硬编码 map 名，改用 module.MapNames() 动态枚举 + strings.HasSuffix(name, "_v2") 做校验
• 对 perf event array 类型 map，即使名称不同，若共用同一 CPU 核心的 perf event fd，仍会触发 EBUSY 错误；此时需确保每个程序调用 map.Pin("/sys/fs/bpf/my_prog/perf_event") 到唯一路径

如何统一管理多个程序的生命周期与错误传播

多个 BPFObject 并行运行时，一个程序崩溃（如 attach 失败、map 更新越界）不应导致整个进程退出，但必须能定位到具体是哪个模块出问题。

Alibabacloud Sdk Client Initialization For Golang

初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。

下载

• 用 sync.WaitGroup + errgroup.Group 启动每个程序的 Run() 循环，每个 goroutine 捕获自己的 error 并写入带模块 ID 的 channel
• 避免共用同一个 libbpfgo.PerfEventArray 实例：每个程序应调用 map.OpenPerfEventArray() 获得独立句柄，否则 Read() 会混读多个程序事件
• 卸载时按反向顺序调用 module.Close()，否则可能触发 EBUSY: device or resource busy（尤其当某程序还在 poll perf map 时）

为什么不用 gobpf 或 bcc-go 管理多程序

gobpf 底层基于旧版 libbpf（

立即学习“go语言免费学习笔记（深入）”；

• libbpfgo 支持 BPF_F_REPLACE 标志，允许热更新单个 program 而不影响其他已加载程序
• 其 Module.DumpMaps() 可导出所有 map 当前 key/value 快照，便于调试多个程序间 map 数据是否意外共享
• 真正麻烦的是 map value 结构体对齐：C 侧 struct { __u32 pid; char comm[16]; } 在 Go 中必须用 unsafe.Offsetof 校验字段偏移，否则多个程序读同一 map 会解析错位

实际跑通的关键，往往卡在 map 名字没加后缀、perf event fd 没隔离、或者 close 顺序反了——这些地方没有报错提示，只有数据不对或 kernel log 里一闪而过的 invalid map fd。