引言：为什么需要应用级跟踪传统的资源分析（CPU、内存、磁盘I/O）能解决许多性能问题，但无法提供请求级别的上下文。例如，磁盘I/O很高，但究竟是哪个查询导致的？BPF跟踪可以在应用层提供关键上下文，将内核事件与请求关联起来。通过静态（USDT）和动态（uprobe）探针，我们能够深入应用的代码、库调用、系统调用，直至设备驱动程序，从而完整观察请求路径。应用基础：线程管理、锁与休眠线程管理模型在多CPU系统上，应用利用线程并行执行，共享进程地址空间。常见线程管理模型包括：服务线程池：固定或动态大小的线程池，每个线程一次服务一个客户端连接/请求，阻塞时睡眠。MySQL数据库服务器采用此模型。CPU线程池：每个CPU一个线程，用于批处理任务（如视频编码）。事件工作者线程：单线程或多线程处理事件队列，每个线程并发处理多个客户端，无阻塞时睡眠。Node.js是典型例子。分阶段事件驱动架构（SEDA）：将请求分解为多个阶段，每阶段可由一个或多个线程池处理。锁与锁竞争锁是同步原语，保护共享内存的并发访问。Linux常用libpthread库提供的三种锁：互斥锁（mutex）：同一时刻只允许一个线程访问。