std::timed_mutex支持超时加锁但非std::mutex子类，需显式调用try_lock_for/try_lock_until，配合std::unique_lock和std::defer_lock可安全自动管理锁。
std::timed_mutex 能直接用，但要注意构造和锁的时机
标准库提供了 std::timed_mutex，它支持带超时的加锁操作，比手动轮询 std::mutex + std::this_thread::sleep_for 更可靠。但它不是 std::mutex 的子类，不能直接替换——如果你原来用的是 std::mutex，得改类型声明，且所有加锁点要换成带超时的接口。
常见错误是误以为 std::timed_mutex 自带“自动重试”或“锁等待超时后自动释放”，其实它只控制单次 try_lock_for 或 try_lock_until 的阻塞上限，失败后互斥量仍处于未锁定状态，不会影响后续调用。
- 必须显式调用
try_lock_for或try_lock_until；lock()仍是阻塞式的，不带超时 - 超时单位要用
std::chrono类型，比如std::chrono::milliseconds(100)，传整数会编译失败 - 构造
std::timed_mutex和普通std::mutex一样，无参即可，不支持递归或带初始状态
try_lock_for 返回 false 不代表死锁，只是没抢到锁
返回 false 只说明在指定时间内未能获取锁，可能是竞争激烈、持有者执行太久，也可能是对方已崩溃（但锁未释放——这时属于系统级问题，C++ 标准库无法检测）。不要把它当作“资源不可用”的等价判断，尤其在关键路径上，需结合业务逻辑决定是否重试、降级或报错。
典型使用场景：RPC 请求处理中避免因下游锁争用导致整个请求线程卡死；或者定时任务中防止某次迭代被长锁阻塞，影响调度精度。
立即学习“C++免费学习笔记（深入）”；
- 不要在循环里无间隔重试
try_lock_for，容易打满 CPU；建议加std::this_thread::yield()或短休眠 - 超时时间不宜设得太短（如 1ms），系统调度开销可能让它几乎总失败；也不宜过长（如 5s），失去“防卡死”意义
- 若需多次尝试，推荐用指数退避，而不是固定间隔
std::unique_lock + try_lock_for 是最灵活的组合
单独用 std::timed_mutex::try_lock_for 只能做简单判断，一旦成功，你得自己记着调 unlock()。更安全的做法是配合 std::unique_lock<std::timed_mutex>，它支持延迟构造、移动、条件等待，还能自动析构解锁。
示例：
std::timed_mutex mtx;
std::unique_lock<std::timed_mutex> lock(mtx, std::defer_lock);
if (lock.try_lock_for(std::chrono::milliseconds(200))) {
// 持有锁，作用域结束自动释放
do_work();
} else {
// 超时，lock 仍为未持有状态，无需 unlock()
handle_timeout();
}
-
std::defer_lock是关键，避免构造时就阻塞 -
std::unique_lock的try_lock_for成功后，lock.owns_lock()返回true，可用来判断 - 不能用
std::shared_lock配合std::timed_mutex——后者不支持共享语义
跨线程异常或提前 return 容易漏掉锁释放
这是最隐蔽的问题：即使用了 std::unique_lock，如果在加锁后、业务代码里抛了异常，而你又没把锁对象放在作用域开头，就可能跳过析构。更糟的是，有人手动管理锁，写 mtx.lock(); ... mtx.unlock();，中间任何 return 或异常都会导致死锁。
所以实际编码中，锁对象声明位置很重要——必须确保它生命周期覆盖全部临界区，且不能被提前移动或重置。
- 永远把
std::unique_lock声明放在函数/作用域顶部，紧挨着 if 判断之后 - 避免在锁持有期间调用不可控的第三方函数，尤其是可能抛异常或 longjmp 的
- 若必须在锁内做复杂操作，考虑把临界区拆细，或用 RAII 封装更小粒度的保护逻辑
