超时是资源竞争的表象，需排查线程持锁过久、锁顺序不一致、临界区阻塞、RAII失效及系统时钟抖动等问题；应结合ThreadSanitizer、perf和gdb定位根因。
超时本身不是错误，而是资源竞争暴露出来的症状；真正要查的是“为什么线程卡在锁上等不到资源”，而不是盯着 timeout 设置是否合理。
std::timed_mutex::try_lock_for 为什么总失败
当 try_lock_for 频繁返回 false，说明有线程长期持有锁没释放，或锁被嵌套/递归误用。常见原因包括：
- 临界区里调用了可能阻塞的函数（如
std::condition_variable::wait、文件 I/O、网络收发），导致锁持有时间远超预期 - 异常提前退出但没走 RAII 析构路径（比如手动
unlock()后抛异常，lock_guard没生效） - 多个
std::timed_mutex被不同线程以不一致顺序获取，部分线程已卡死，把其他线程也拖进等待队列 - 误把
std::mutex当成std::timed_mutex用——后者才支持try_lock_for，前者调用会编译失败
用 ThreadSanitizer 看清谁在抢哪块内存
单纯看超时日志看不出竞争源头。必须让 TSan 运行起来，它能直接指出哪两个线程在无保护地读写同一地址：
- 编译加
-fsanitize=thread -fno-omit-frame-pointer -g -O1，不要用-O2或更高，否则检测会失效 - 运行时一旦触发数据竞争，TSan 会在终端立刻打印类似
WARNING: ThreadSanitizer: data race on &counter (0x...)的信息，并带出两个线程的完整调用栈 - 注意：TSan 不检测死锁，只抓“同时读写未同步变量”；如果超时伴随崩溃，大概率是竞态已破坏了锁对象自身（比如
std::mutex被释放后又被 lock）
锁持有时间过长的真实线索藏在 perf 和 backtrace 里
Linux 下用 perf record -e sched:sched_switch 抓一段时间的调度事件，再用 perf script 查看线程切换热点。重点关注：
立即学习“C++免费学习笔记（深入）”；
- 某个线程在
pthread_mutex_lock或__lll_lock_wait上停留超过几毫秒——说明它在等锁，且等待队列不空 - 持有锁的线程是否长时间停在
read、write、nanosleep等系统调用里——这是临界区污染的铁证 - 用
gdb -p $PID连上去执行thread apply all bt，观察哪些线程卡在std::mutex::lock，哪些卡在业务逻辑里却没释放锁
最易被忽略的一点：std::timed_mutex 的超时单位是相对时间，受系统时钟调整（如 NTP 跳变）影响；若机器时间被大幅校正，try_lock_for 可能意外提前返回 false——这不是竞争，是时钟抖动，得换用 try_lock_until 配合 steady_clock。
