循环内局部std::unique_lock是否需要在末尾手动调用unlock()？

核心结论 #

你给出的两种写法在锁的获取、释放逻辑上完全等价，不存在行为差异。

原理说明 #

std::unique_lock 是C++标准库提供的RAII风格互斥锁包装类，它的析构函数会自动检查当前实例是否持有对应互斥锁的所有权：如果持有，会自动调用unlock()释放锁，不会出现重复释放的问题。
针对你给出的两个示例：

• 第一种写法在循环体末尾手动调用了lock.unlock()，执行完成后lock已经失去锁所有权，等到循环体结束lock被析构时，检测到没有锁持有，不会执行额外操作
• 第二种写法没有手动调用解锁，循环体结束时lock被析构，自动触发解锁操作
  两种写法的锁持有范围都恰好覆盖// do something 代码段，锁释放时机完全一致；即使// do something抛出异常，两种写法都会依赖unique_lock的析构逻辑自动释放锁，不会出现死锁。

是否需要在循环末尾手动调用unlock？ #

你给出的场景下完全没有必要，手动解锁属于冗余操作，反而可能引入额外风险：

• 后续维护代码时，如果在手动解锁的代码之后新增了需要锁保护的操作，很容易忘记重新加锁，导致线程安全问题
• 如果误对已经解锁的unique_lock重复调用unlock()，会抛出std::system_error异常，依赖析构自动解锁不会出现这个问题
• 手动解锁破坏了RAII的隐式安全保障，在复杂分支逻辑中混用手动解锁和自动析构，很容易出现逻辑混乱

仅在以下场景需要手动调用unlock #

当锁保护的逻辑执行完成后，当前循环体中还有大量不需要锁保护的耗时操作（比如IO操作、非共享数据的复杂计算），为了提升并发效率，才需要手动提前解锁，把互斥锁让给其他等待线程使用，示例如下：

std::mutex mutex;
for (/* 循环条件 */) {
    std::unique_lock<std::mutex> lock(mutex);
    // 仅修改共享数据的逻辑放在锁保护范围内
    shared_data.update();
    lock.unlock();
    // 耗时的非共享操作不需要持锁，提前解锁可以提升并发效率
    do_heavy_io_task();
    do_long_time_calculation();
}

内容的提问来源于stack exchange，提问作者Evandro Coan