LTTng-UST启用前提为用户态追踪正常工作，需确保已安装lttng-ust、应用程序链接-liblttng-ust、运行时可加载liblttng-ust.so.1，且线程创建在lttng_ust_init之后；C++多线程事件需手动埋点（如tracef或lttng_ust_tracepoint），推荐用gettid()标识线程并在关键同步点打点，启用时应结合--filter限定进程范围，解析时需用babeltrace --format=ctf-text或JSON并人工对照tid与sched_switch事件分析竞争与调度行为。
确认LTTng-UST是否已启用并加载
LTTng跟踪C++多线程事件的前提是用户态追踪（UST）正常工作，否则lttng enable-event --userspace会报错或无声失败。常见现象是执行lttng list --userspace返回空，或lttng start后babeltrace看不到任何用户事件。
必须确保：
- 已安装lttng-ust和liblttng-ust-dev（Ubuntu/Debian）或lttng-ust（RHEL/CentOS）
- 应用程序链接了-llttng-ust（不是仅编译时有头文件）
- 运行时动态库可被找到：检查ldd ./myapp | grep lttng是否输出liblttng-ust.so.1
- 若使用std::thread，需确认线程创建发生在lttng_ust_init()之后（通常由liblttng-ust自动触发，但静态链接或特殊加载顺序可能绕过）
在C++代码中插入线程感知的tracepoint
原生std::thread本身不触发事件；要捕获线程生命周期或关键同步点，需手动埋点。LTTng-UST提供宏tracef()和lttng_ust_tracepoint()，但对多线程场景要注意上下文隔离。
推荐做法：
- 在每个线程入口函数开头加tracef("thread_start tid=%d", gettid())（gettid()需#include <sys/syscall.h>）
- 在std::mutex、std::condition_variable等关键同步操作前后打点，例如：tracef("mutex_lock begin name=work_queue")
- 避免在高频循环内调用tracef()，它有微秒级开销；改用lttng_ust_tracepoint()配合自定义tracepoint声明，可做编译期过滤
- 不要依赖pthread_self()作为唯一标识——它在std::thread下不可靠；优先用gettid()或线程局部变量（thread_local static int trace_id = next_id++）
启用用户态事件并设置线程过滤
默认lttng enable-event --userspace捕获所有进程的所有UST事件，数据量爆炸且难以聚焦。实际调试多线程问题时，应限制范围。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
有效命令组合：
- 创建会话时指定输出路径：lttng create mytrace --output=/tmp/lttng-trace
- 启用带过滤的用户态事件：lttng enable-event --userspace --filter 'procname == "myapp"' myevent（myevent需在代码中声明为tracepoint名称）
- 若只关心特定线程，可用--syscall-filter间接约束（如clone系统调用后立即打点），但更可靠的是在代码中用tracef()加tid字段，后续用babeltrace按字段过滤：babeltrace /tmp/lttng-trace | grep "tid=12345"
- 注意：--filter语法不支持tid直接过滤（UST层无该字段），必须靠应用层埋点输出
解析trace时识别线程切换与竞争模式
生成的CTF格式trace里，内核事件（如sched_switch）和用户事件时间戳对齐，但线程ID映射需人工对照。容易忽略的关键点：
立即学习“C++免费学习笔记（深入）”；
- babeltrace默认不显示tid字段，需用--format=ctf-text或导出为JSON：babeltrace --output-format=json /tmp/lttng-trace > trace.json
- 多线程竞争常表现为多个tracef("mutex_lock begin")紧挨着出现，但只有一个对应"mutex_lock end"——这说明锁争用，而非死锁
- 若看到同一tid反复出现"cond_wait begin"但无"cond_wait end"，结合sched_switch事件看该线程是否长期未被调度，可能是优先级反转或CPU绑定问题
- C++11线程池场景下，std::thread对象析构会触发join()或detach()，但LTTng无法自动捕获这些语义；必须在~thread()前手动加tracef("thread_join tid=%d")
