最直接可控的方式是在加锁前后用std::chrono::high_resolution_clock::now()打高精度时间戳，测得等待耗时与临界区持有耗时，并建议结合线程ID和锁地址日志归因。
用 std::chrono 手动打点测锁持有时间
最直接可控的方式，是在每次加锁前后插入高精度时间戳。适用于调试阶段定位某一把锁是否长期被占用，或验证锁粒度是否合理。
注意：std::mutex::lock() 是阻塞调用，测的是「从尝试加锁到成功持有」的总耗时（含等待时间），不是纯临界区执行时间。若只想测临界区本身，得把打点放在 lock() 之后、unlock() 之前。
- 用
std::chrono::high_resolution_clock::now()，避免steady_clock在某些平台精度不足 - 别用
system_clock，它可能受系统时间调整影响，导致负值或跳变 - 日志建议包含线程 ID（
std::this_thread::get_id()）和锁地址（fmt::ptr(&mtx)或fmt::format("{:p}", (void*)&mtx)），方便归因
auto start = std::chrono::high_resolution_clock::now(); mtx.lock(); auto lock_end = std::chrono::high_resolution_clock::now(); // ... critical section ... mtx.unlock(); auto unlock_end = std::chrono::high_resolution_clock::now(); auto wait_us = std::chrono::duration_cast<std::chrono::microseconds>(lock_end - start).count(); auto hold_us = std::chrono::duration_cast<std::chrono::microseconds>(unlock_end - lock_end).count();
用 std::scoped_lock + RAII 封装自动计时
手动调用 lock()/unlock() 容易漏打点或顺序错乱，尤其在有异常路径时。用 RAII 包一层，能保证时间统计逻辑不随控制流变化而失效。
关键点在于：构造函数里完成加锁和起始计时，析构函数里记录结束时间并输出（或写入 perf buffer）。但要注意——不要在析构里做复杂 I/O，否则可能拖慢线程甚至引发死锁。
立即学习“C++免费学习笔记（深入）”；
- 封装类的构造参数应接受可变参的互斥量引用，兼容
std::scoped_lock原生语义 - 计时结果建议存为成员变量，供外部按需读取（比如只在 hold_time > 10000 微秒时才 log）
- 避免在计时器析构中直接调用
std::cout或spdlog::info，优先写环形缓冲区或交由专用日志线程消费
Linux 下用 perf record -e sched:sched_mutex_lock,sched:sched_mutex_unlock
内核已提供对 futex 和 mutex 的 tracepoint 支持，无需改代码就能抓到锁的 acquire/release 事件。适合线上环境快速筛查热点锁。
但注意：这些 tracepoint 默认未启用，且只覆盖 glibc 的 pthread_mutex_t（即 C 风格互斥量），对 std::mutex 是否生效取决于 libstdc++ 实现是否基于 pthread —— GCC 通常如此，Clang + libc++ 则不一定。
- 先确认 tracepoint 可用：
sudo perf list | grep mutex - 采集命令示例：
sudo perf record -e 'sched:sched_mutex_lock,sched:sched_mutex_unlock' -g ./myapp - 分析时用
perf script看原始事件流，或用perf report -F comm,symbol,dso --no-children查看锁操作热点函数 - 无法区分同一把锁在不同位置的持有行为，需结合符号信息与源码行号交叉定位
为什么 std::timed_mutex::try_lock_for() 不适合测持有时间
它只能告诉你「这次有没有抢到锁」，不能告诉你「抢到后用了多久」。而且它的超时机制是针对获取过程的，和临界区执行无关。
更隐蔽的问题是：一旦你在线程里频繁调用 try_lock_for() 来“探测”锁状态，反而会干扰真实竞争模式，甚至让原本低概率的锁争用变成高频抖动。
- 不要用它替代真实加锁逻辑来做性能分析
- 它返回
false只代表「没拿到」，不代表「别人持有了很久」——可能对方刚释放，也可能根本没人争用 - 若真想监控锁争用率，应统计
try_lock()失败次数 / 总尝试次数，而非依赖try_lock_for()的超时值
实际部署时最容易被忽略的一点：时间戳采集本身有开销，高频打点会让原本轻量的锁操作显著变慢。生产环境若需长期观测，建议用采样方式（如每 100 次加锁记录一次）或切换到 eBPF 工具（如 bpftrace hook futex syscall），而不是无差别埋点。
