锁竞争分析
锁竞争分析采集内核锁事件并汇总竞争次数与等待耗时。当并发度提升或业务量增长后，瓶颈常常从算力转向锁：处理器不忙但吞吐上不去，等待都消耗在进入临界区之前。这个工具的作用是把「有竞争」变成「竞争在哪把锁上」，同时给出等待的量级。
基本信息
| 适用平台 | Linux（内核自带性能工具） |
|---|---|
| 采集方式 | 记录内核锁事件后汇总 |
| 报告指标 | 竞争事件数、等待总时长、单次最长等待、获取次数 |
| 前提条件 | 内核启用相关锁事件支持 |
| 覆盖范围 | 内核锁；应用侧锁需要其它手段配合 |
典型使用场景
- 并发线程数提升后吞吐不再增长，怀疑转向锁竞争。
- 尾延迟尖刺需要区分是锁等待还是 IO 阻塞。
- 判断问题出在文件系统、网络栈还是驱动内部。
- 与离开处理器的时间归因交叉验证，确认等待类型。
- 变更前后对比，量化锁优化的收益。
记录与汇总
记录与汇总
perf lock record -p 12345 -- sleep 5 # 记录指定进程的锁事件
perf lock record -- sleep 5 # 记录整机锁事件
perf lock report | head -30 # 汇总：先看竞争次数与等待时长
perf lock report -k wait_max # 按单次最长等待排序
perf lock info # 查看可用的锁事件来源
zcat /proc/config.gz | grep -i LOCK_EVENTS # 确认内核是否启用锁事件支持报告列解读
| 列 | 含义 | 判读要点 |
|---|---|---|
| 竞争事件数 | 发生竞争的锁事件次数 | 集中度高的锁优先处理 |
| 等待总时长与单次上限 | 累计与最坏等待 | 单次长等待更影响尾延迟 |
| 获取次数 | 进入临界区的次数 | 结合业务并发度看热点 |
| 锁的名称 | 内核中的锁对象 | 指向具体子系统 |
没有输出不代表没有竞争：可能是内核未启用锁事件支持，也可能竞争发生在用户态锁上，后者需要用阻塞时间归因的方式来观察。
记录窗口内的负载变化会让结论失真：窗口里并发度忽高忽低时，等待时长无法归因，建议在稳定负载下采集并记录当时的并发配置。