std::mutex无法被BPF直接跟踪，因其lock/unlock是内联函数，编译后符号不导出且常被优化掉；kprobe只能挂钩已导出符号，而std::mutex成员函数在ELF中几乎不存在可识别符号。
直接用 bpftrace 或 bpftool 跟踪 C++ 多线程程序的互斥锁，基本不可行——因为标准库（libstdc++ 或 libc++）的 std::mutex 实现不导出稳定符号，且底层可能复用 pthread_mutex_t 但不保证调用路径可见。真正能抓到锁行为的，只有系统级的 pthread 接口或内核锁事件。
为什么 std::mutex 无法被 BPF 直接跟踪
std::mutex::lock() 和 std::mutex::unlock() 是内联函数，编译后通常直接展开为对 pthread_mutex_lock / pthread_mutex_unlock 的调用（取决于 libstdc++ 版本和编译选项），但链接时可能被优化掉符号，或者走静态链接路径。BPF 的 kprobe 只能挂钩已导出的、带调试信息或符号表的函数入口，而 std::mutex 成员函数在用户态 ELF 中几乎从不以可识别符号形式存在。
常见错误现象：bpftrace -e 'kprobe:std::mutex::lock { printf("hit\n"); }' 完全无输出；nm -C ./a.out | grep mutex 找不到对应符号。
可行的前提是：你的程序显式调用 pthread_mutex_lock 等 C 接口，或你启用了 -g 编译并确认 libpthread.so 符号可用（多数发行版默认提供）。
立即学习“C++免费学习笔记（深入）”；
用 kprobe 跟踪 pthread_mutex_lock/unlock
这是目前最可靠、开销可控的方式。前提是目标进程动态链接了 libpthread（几乎所有 Linux C++ 多线程程序都满足）。
关键点：
- 必须使用
libpthread.so的符号，不是libc.so——pthread_mutex_lock在 glibc 中属于libpthread模块 - 需确认符号是否导出：
objdump -T /usr/lib/x86_64-linux-gnu/libpthread.so.0 | grep mutex_lock - 实际触发点是内核中
__futex_abstimed_wait_cancelable或do_futex，但太底层、噪声大；优先选用户态入口
示例（记录锁 ID 和线程 TID）：
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
bpftrace -e '
kprobe:pthread_mutex_lock {
$mutex = ((struct pthread_mutex_t*)arg0);
printf("LOCK tid=%d mutex=%p\n", pid, $mutex);
}
kretprobe:pthread_mutex_lock /retval != 0/ {
printf("LOCK FAIL tid=%d err=%d\n", pid, retval);
}
kprobe:pthread_mutex_unlock {
printf("UNLOCK tid=%d mutex=%p\n", pid, ((struct pthread_mutex_t*)arg0));
}'
注意：arg0 是第一个参数，在 x86_64 上即 pthread_mutex_t*；结构体布局依赖 glibc 版本，不建议直接读字段，仅作标识用。
用 uprobe 跟踪自定义封装的锁类
如果你的代码里有类似 MyMutex::Lock() 这样的封装，并且该函数未内联（加了 __attribute__((noinline)) 或编译时禁用 -O2），就可以用 uprobe。
操作步骤：
- 编译时保留调试信息：
g++ -g -O0 -o app app.cpp - 确认符号存在：
nm -C ./app | grep MyMutex::Lock - 获取函数地址：
readelf -s ./app | grep MyMutex::Lock - 挂载 uprobe：
sudo bpftool prog load ./trace.o /sys/fs/bpf/mytrace && sudo bpftool prog attach pinned /sys/fs/bpf/mytrace uprobe ./app:0x123456
风险点：C++ 名字修饰（mangling）会导致符号名不稳定；std::mutex 自身封装层（如 std::__1::mutex::lock）在 libc++ 下符号名与 libstdc++ 完全不同，且通常被内联。
避免误判：区分锁争用与正常加锁
BPF 能看到每次 pthread_mutex_lock 调用，但无法直接判断是否发生阻塞。真正反映争用的是 futex 系统调用的返回值或等待时间。
更准的做法是结合：
-
tracepoint:syscalls:sys_enter_futex，过滤op == 0 (FUTEX_WAIT)且val == expected - 匹配同一
pid和内存地址（uaddr字段），确认该地址正被用作 mutex 内部 futex 字段 - 统计单位时间内
FUTEX_WAIT次数突增，比单纯看 lock/unlock 更能定位热点锁
容易忽略的一点：同一个 pthread_mutex_t 对象在不同线程中加锁，其地址相同，但 BPF 中 pid 不同——必须用 pid + 地址联合标识一次锁操作，否则会把多个线程的锁混为一谈。
