std::mutex不支持超时，必须使用std::timed_mutex；其try_lock_for接收duration类型参数，返回false表示未获锁但不区分超时或中断原因，需用std::unique_lock配合raii管理。
std::mutex 本身不支持超时，得换 std::timed_mutex
直接对 std::mutex 调用 try_lock_for 会编译失败——它根本没这个成员函数。真正支持超时等待的是 std::timed_mutex（或 std::recursive_timed_mutex）。这是类型层面的硬性限制，不是用法问题。
常见错误现象：error: 'class std::mutex' has no member named 'try_lock_for'
- 使用场景：需要避免线程无限阻塞在锁上，比如 IO 等待、RPC 调用、实时性敏感路径
-
std::timed_mutex和std::mutex内存布局不同，不能互相替换指针或引用 - 性能影响：
std::timed_mutex在部分平台（如 Linux glibc）底层依赖 futex 的超时路径，开销略高，但差异通常可忽略
try_lock_for 的时间单位和返回值含义要盯紧
try_lock_for 接收的是相对时长（如 std::chrono::milliseconds(100)），不是绝对时间点；返回 true 表示成功获取锁，false 表示超时或被中断——它**不区分超时和其他失败原因**。
容易踩的坑：把 std::chrono::system_clock::now() + 100ms 传给 try_lock_until 是对的，但传给 try_lock_for 就会编译报错（类型不匹配）。
立即学习“C++免费学习笔记（深入）”；
- 参数必须是
std::chrono::duration类型，不能是整数毫秒值（如100） - 返回
false时，锁一定没拿到，但无法知道是超时、被 signal 中断，还是系统调度异常 - 若需精确区分原因，得配合
std::this_thread::sleep_for+ 手动try_lock，但会丢失原子性保障
示例：
std::timed_mutex mtx;
if (mtx.try_lock_for(std::chrono::milliseconds(50))) {
// 拿到锁了
do_work();
mtx.unlock();
} else {
// 没拿到，可能是超时，也可能是其他原因
handle_timeout_or_failure();
}
RAII 管理超时锁要用 std::unique_lock，别手写 unlock
std::unique_lock 是唯一能配合 std::timed_mutex 实现自动释放的 RAII 容器；std::lock_guard 不支持超时构造，硬塞会编译失败。
常见错误现象：error: no matching constructor for initialization of 'std::lock_guard<:timed_mutex>'</:timed_mutex>
-
std::unique_lock构造时可传std::defer_lock，再调try_lock_for，更灵活 - 未成功加锁的
std::unique_lock对象，调unlock()是未定义行为——得先用owns_lock()判断 - 移动语义下，
std::unique_lock可转移所有权，但原对象自动变为不持有状态
示例：
<pre class="brush:php;toolbar:false;">std::timed_mutex mtx;
std::unique_lock<std::timed_mutex> lk(mtx, std::defer_lock);
if (lk.try_lock_for(std::chrono::seconds(1))) {
do_work();
// 自动 unlock()
} else {
// lk.owns_lock() == false，不用也不该调 unlock()
}
超时时间太短可能被系统调度抖动误判
在负载高或内核调度延迟大的环境里，设 1ms 超时很可能失败——不是逻辑卡住，而是线程还没轮到执行就被判定“超时”。这不是代码 bug，是实时性边界问题。
真实场景中见过 5ms 超时在 busy CPU 上失败率超 30%，而改成 10ms 后稳定。
- 建议最小超时设为 10ms 起，再根据实测调整
- 不要用超时机制替代锁设计优化：如果频繁超时，优先检查是否锁粒度太大、临界区过长
try_lock_for 的实际等待时长可能略长于指定值（系统精度限制），但不会显著偏离
这事没法靠加日志绕过去——超时本身就是对不确定性的妥协。真要强实时，得换无锁结构或专用同步原语。
