std::try_lock不是单个互斥量的非阻塞加锁解法，而是专用于同时获取多个支持try_lock()的互斥量；对单个std::mutex应调用其成员函数try_lock()，并配合std::unique_lock+defer_lock确保RAII安全。
std::try_lock 为什么不是“非阻塞加锁”的通用解法
std::try_lock 的名字容易让人误以为它是给单个互斥量用的“非阻塞加锁函数”，但它实际只用于**同时尝试获取多个互斥量**，且要求所有互斥量都支持 try_lock() 成员函数（如 std::mutex、std::timed_mutex）。它不会对单个 std::mutex 做非阻塞操作——std::mutex::try_lock() 才是你要的。
std::mutex::try_lock() 才是真正的非阻塞加锁
对单个互斥量做非阻塞加锁，必须调用其成员函数 try_lock()，而非全局 std::try_lock()。它立即返回 true（成功获得锁）或 false（锁已被占用），绝不会挂起线程。
常见错误写法：
std::mutex mtx; std::try_lock(mtx); // ❌ 编译失败：std::try_lock 不接受单个 mutex
正确写法：
立即学习“C++免费学习笔记（深入）”；
std::mutex mtx;
if (mtx.try_lock()) {
// ✅ 拿到锁，临界区
do_something();
mtx.unlock(); // 别忘了手动释放
} else {
// ❌ 未拿到锁，可降级处理、重试或跳过
handle_no_lock();
}
try_lock() 的典型使用场景和陷阱
它适用于那些“有锁就干，没锁就算了”的轻量级竞争场景，比如缓存更新、日志采样、状态快照等。但要注意：
-
try_lock()后必须配对调用unlock()—— 它不支持 RAII 自动管理，不能和std::lock_guard混用 - 如果在
try_lock()返回true后抛出异常，而你又没用std::unique_lock+defer_lock等方式管理，就会漏掉unlock()，导致死锁 -
std::recursive_mutex也支持try_lock()，但要注意重入计数；std::shared_mutex则需用try_lock_shared()或try_lock()区分读写 - 某些平台（如 Windows 上的 pthread 封装）可能让
try_lock()有轻微开销，频繁轮询仍需谨慎
想安全地用 try_lock()？优先考虑 std::unique_lock + defer_lock
为避免手动 unlock() 遗漏，更推荐用 std::unique_lock 的延迟构造模式：
std::mutex mtx;
std::unique_lock<std::mutex> lock(mtx, std::defer_lock);
if (lock.try_lock()) {
// ✅ RAII 保证：作用域结束自动 unlock()
do_something();
} else {
// 无需 unlock()，lock 仍是未持有状态
}
这样既享受非阻塞语义，又规避了资源泄漏风险。注意：std::lock_guard 不支持 try_lock，它只有构造即加锁、析构即释放这一种行为。
真正难的不是调用哪个函数，而是判断“这次拿不到锁时，业务逻辑是否还能有意义地继续”——这个决策比语法本身重得多。
