不能直接替换，因接口不兼容、默认启用死锁检测、无递归锁、缺少try_lock()重载，且RAII封装器需改用absl::MutexLock等专用类。
absl::Mutex 能直接替换 std::mutex 吗？
不能无脑替换，absl::Mutex 和 std::mutex 接口不兼容，且语义有关键差异：它默认支持死锁检测、递归锁行为不可用（除非显式启用）、不提供 try_lock() 的标准重载。直接把 std::mutex 换成 absl::Mutex 会导致编译失败，尤其在调用 lock_guard 或 unique_lock 时。
Abseil 不提供与 STL 同名的 RAII 封装器；必须改用 absl::MutexLock、absl::ReaderMutexLock 等专用类。
如何正确迁移 lock_guard / unique_lock 场景？
用 absl::MutexLock 替代 std::lock_guard<:mutex> 是最常见迁移路径，但要注意作用域和构造方式：
-
absl::MutexLock构造即加锁，析构自动解锁，行为类似lock_guard，但不支持延迟构造或移动 - 不能像
unique_lock那样先声明后lock()，也不支持try_lock_for()—— 若需超时，得用absl::Mutex::LockWhenWithTimeout() - 若原逻辑依赖
unique_lock::owns_lock()或条件变量配合，需同步改用absl::CondVar，且条件判断必须用absl::Condition包装
absl::Mutex mu;
int data = 0;
// ✅ 正确：等价于 lock_guard
void increment() {
absl::MutexLock lock(&mu);
++data;
}
// ❌ 错误：没有默认构造 + later lock
// absl::MutexLock lock; // 编译失败
// lock = absl::MutexLock(&mu); // 也不允许赋值
开启死锁检测和调试符号的关键配置
Abseil 的死锁检测不是默认开启的，需满足两个条件才生效：
- 构建时定义宏
ABSL_HAVE_ADDRESS_SANITIZER或ABSL_HAVE_THREAD_SANITIZER（仅限调试构建） - 运行时设置环境变量
ABSL_MUTEX_DETECTION=1，否则absl::Mutex退化为轻量级 spin+sleep 实现，无栈回溯能力 - 若未链接
libbacktrace或未启用 DWARF 符号，死锁报告里只有地址，看不到函数名
性能影响明显：开启死锁检测后，每次加锁/解锁会采集栈帧，吞吐下降约 2–5×（视调用深度而定），仅用于开发/测试阶段。
性能对比与适用边界
absl::Mutex 在高争用下比 std::mutex（尤其是 glibc 的 pthread_mutex_t 默认实现）更激进地使用自旋，减少线程切换开销，但代价是 CPU 占用更高。是否更快，取决于具体场景：
- 临界区极短（absl::Mutex 通常胜出
- 临界区含 IO 或可能阻塞 → 必须用
absl::Mutex::Await()或LockWhen()配合absl::Condition，避免自旋浪费 - 跨平台部署且无法控制构建选项 →
std::mutex更稳妥；Abseil 的优势在 Google 内部工具链深度集成下才完全释放
真正容易被忽略的是：Abseil 的 mutex 不支持与 std::condition_variable 混用，哪怕你只把它当普通互斥量用 —— 因为内部状态结构完全不同。一旦引入 absl::Mutex，整个同步逻辑就得迁移到 Abseil 的并发原语体系里。
