何时优先使用std::scoped_lock而非std::shared_lock？其是否为多锁版std::unique_lock？

一、何时优先使用std::scoped_lock而非std::shared_lock？ #

首先明确两者的核心定位：

• std::scoped_lock是独占型锁（排他锁），一旦某个线程持有它，其他线程既无法获取该锁的独占权限，也无法获取共享权限（比如std::shared_lock）。
• std::shared_lock是共享型锁，多个线程可同时持有它，仅适用于对共享资源的只读访问。

优先选择std::scoped_lock的场景包括：

• 对共享资源执行写操作或修改操作：比如更新全局变量、写入数据库、修改容器内容等，必须确保操作期间没有其他线程（读或写）访问资源，此时独占锁是唯一可靠选择。
• 需要同时锁定多个互斥量：std::scoped_lock支持同时传入多个互斥量，会自动按照安全顺序锁定，从根源避免死锁问题，比手动用std::lock配合其他锁更简洁安全。
• 追求最严格的锁安全保障：std::scoped_lock的生命周期完全绑定作用域，构造时自动加锁，析构时自动解锁，没有手动操作锁的空间，能最大程度避免漏解锁、重复解锁这类低级错误。

二、std::scoped_lock是否只是可持有多个互斥量的std::unique_lock变体？ #

不是，两者存在本质区别，不能简单划等号：

• 所有权灵活性不同：std::scoped_lock不可移动、不可复制，锁的所有权完全绑定到当前作用域，无法转移给其他对象；而std::unique_lock支持移动操作，可将锁的所有权转移到其他线程或对象中。
• 功能复杂度不同：std::unique_lock支持延迟锁定（构造时不立即加锁）、手动解锁/重新加锁、尝试锁定等高级操作，适合需要灵活控制锁生命周期的场景；而std::scoped_lock只做一件事：构造时锁定（单或多互斥量），析构时解锁，功能极简但安全性更高。
• 性能与设计定位不同：std::scoped_lock的设计目标是轻量、安全的作用域独占锁，因无需额外状态管理（比如是否持有锁的标记），性能可能略优于std::unique_lock；而std::unique_lock是通用的独占锁工具，以少量性能损耗换来了操作灵活性。

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