std::unique_lock 本身不支持可重入，因其包裹的 std::mutex 是非递归锁，同一线程重复加锁将导致未定义行为；需改用 std::recursive_mutex 才能安全重入，但应优先优化设计而非依赖重入。
std::unique_lock 本身不支持可重入
直接说结论：std::unique_lock 包裹的 std::mutex 是不可重入的，同一线程重复加锁会触发未定义行为（通常是程序崩溃或死锁）。这不是用法问题，是 C++ 标准规定的限制——std::mutex 对应的是 POSIX 的 PTHREAD_MUTEX_NORMAL，不记录持有者和递归深度。
常见错误现象：std::terminate 被调用、glibc 报 Resource deadlock avoided、或静默卡死。尤其在递归调用、回调嵌套、或“先检查再加锁”逻辑里容易踩中。
- 别试图对同一个
std::mutex多次调用lock()或构造多个std::unique_lock - 如果逻辑上需要重入，必须换锁类型：用
std::recursive_mutex配合std::unique_lock -
std::unique_lock<:recursive_mutex></:recursive_mutex>是合法且安全的，但性能略低（需维护计数器和线程 ID 比较）
如何用 std::unique_lock 控制锁粒度（避免过度锁定）
锁粒度控制的关键不是“能不能重入”，而是“锁住什么、何时释放、是否可延迟”。std::unique_lock 的价值在于它支持移动、延迟构造、条件变量配合和手动释放——这些才是精细控粒度的手段。
- 用
std::defer_lock构造，把加锁时机从作用域进入推迟到明确调用lock()时 - 在临界区结束前调用
unlock()主动释放，让后续非共享操作不被阻塞 - 配合
std::condition_variable::wait()时，std::unique_lock会自动临时解锁、唤醒后重新锁，这是std::lock_guard做不到的 - 避免跨函数传递已锁定的
std::unique_lock；更安全的做法是传引用 + 显式lock()/unlock()，或改用 RAII 封装新语义
示例：只在真正修改共享状态时持锁
立即学习“C++免费学习笔记（深入）”；
void process_item(std::vector<int>& data, int val) {
std::unique_lock<std::mutex> lk(mutex_, std::defer_lock);
// 先做不依赖共享数据的计算
auto transformed = expensive_transform(val);
// 到这里才需要同步
lk.lock();
data.push_back(transformed);
lk.unlock(); // 立即释放，不卡住后续调用
log_completion(transformed);
}
std::recursive_mutex + std::unique_lock 的典型误用场景
用了 std::recursive_mutex 并不意味着可以随意嵌套加锁——它只是让同一线程不会死锁，但逻辑错误和性能问题照旧存在。
- 递归锁掩盖了设计缺陷：比如本该拆分职责的函数强行复用，或没意识到“读-改-写”本应原子化而非靠重入撑住
- 在性能敏感路径（如高频循环、实时线程）中滥用
std::recursive_mutex，每次加锁都要查线程 ID 和计数，比普通 mutex 慢 2–3 倍 -
std::unique_lock移动后原对象变为未关联状态，若误判其是否已锁，可能造成漏锁或 double-unlock - 调试困难：重入锁让死锁检测工具（如 ThreadSanitizer）失效，且堆栈看不出锁的嵌套层级
替代方案：比可重入更值得优先考虑的设计
真正需要“可重入”的场景，90% 是因为共享状态组织不合理。比起换锁类型，先检查这几件事更有效：
- 能否把大块共享数据拆成多个独立子资源，各自配独立
std::mutex？降低争用，也自然消除重入需求 - 能否用无锁结构（如
std::atomic计数器、ring buffer）替代部分互斥访问？尤其适合生产者-消费者模式 - 是否混淆了“线程安全”和“对象安全”？某些类本就不该跨线程共享实例，强制共享反而催生重入补丁
- 回调函数里调用外部接口？考虑用异步消息队列解耦，而不是让回调反向拿锁
一个常被忽略的点：std::unique_lock 的析构函数是 noexcept，但它内部调用的 unlock() 如果抛异常（极罕见，除非自定义 mutex），会导致 std::terminate。所以不要在 unlock() 前做可能抛异常的操作——这个细节在重入逻辑里更容易暴露。
