08C++11多线程编程之unique_lock类模板
前述：
如果看懂了该篇文章，你对unique_lock可以说随便使用。并且可以只看第5点的总结即可。
1 unique_lock概念
当不加参数时，和lock_guard一样能自动上锁解锁，参数2比lock_guard更加灵活，效率比lock_guard低点，内存也占用大点。看个人喜欢用哪个。
并且和lock_guard都是独占型锁，一把锁只能绑定一个unique_lock，不能多个。类似unique_ptr独占型智能指针。
注：由于不加参数时unique_lock是和lock_guard一样，所以这里就不给出unique_lock无参数2的代码例子。
2 unique_lock的第二个参数
1）std::adopt_lock：表示在创建unique_lock之前已经上锁了。若没上锁，则程序报错崩溃。lock_guard也有唯一的参2->std::adopt_lock，用法完全相同。
这里需要严重的强调一点：adopt_lock不能手动解锁，否则崩溃，与lock_guard的参2->adopt_lock完全一样。与try_to_lock和defer_lock能提前解锁完全不一样。
#include<iostream>
#include<thread>
#include<string>
#include<vector>
#include<list>
#include<mutex>
using namespace std;
//准备用成员函数作为线程函数的方法写线程，成为消息处理类
class A {
public:
//把收到的消息入到一个队列的线程
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行，插入一个元素" << i << endl;
std::lock(my_mutex1, my_mutex2);//一次锁多个,顺序可以忽略
unique_lock<mutex> uLock1(my_mutex1, std::adopt_lock);//参数2表示锁已经上锁
unique_lock<mutex> uLock2(my_mutex2, std::adopt_lock);
msgRecvQueue.push_back(i);
//my_mutex1.unlock();//不能再手动解锁，否则崩溃,与lock_guard的参2adopt_lock完全一样
//my_mutex2.unlock();
}
}
//将共享的代码放到一个函数处理,方便上锁解锁
bool outMsgLULProc(int &command) {
std::lock(my_mutex2, my_mutex1);//一次锁多个,顺序可以忽略
unique_lock<mutex> uLock1(my_mutex1, std::adopt_lock);//参数2表示锁已经上锁
unique_lock<mutex> uLock2(my_mutex2, std::adopt_lock);
if (!msgRecvQueue.empty()) {
int command = msgRecvQueue.front();
msgRecvQueue.pop_front();
//my_mutex1.unlock();//不能再手动解锁，否则崩溃,与lock_guard的参2adopt_lock完全一样
//my_mutex2.unlock();
return true;
}
//my_mutex2.unlock();
//my_mutex1.unlock();
return false;
}
//把数据从消息队列取出的线程
void outMsgRecvQueue() {
int command = 0;
for (int i = 0; i < 10000; i++) {
bool result = outMsgLULProc(command);
if (result == true) {
cout << "outMsgRecvQueue()执行，取出一个元素" << endl;
//处理数据
//这里有可能也有需要共享的代码段
}
else {
//消息队列为空
cout << "outMsgRecvQueue()执行，但目前消息队列中为空！" << endl;
}
}
cout << "end!" << endl;
}
private:
std::list<int> msgRecvQueue;//容器（消息队列），代表玩家发送过来的命令。
std::mutex my_mutex1;
std::mutex my_mutex2;
};
int main()
{
A myobja;
std::thread myOutMsgObj(&A::outMsgRecvQueue, &myobja);//第二个参数，地址，才能保证线程里用的是同一个对象
std::thread myInMsgObj(&A::inMsgRecvQueue, &myobja);
myOutMsgObj.join();
myInMsgObj.join();
cout << "主线程执行！" << endl;
return 0;
}
该程序结果是稳定运行的，但是我多次运行发现这个类有bug，就是说当outMsg执行10000次后，可能list还会有元素，但是只是测试就不需要管它了。
下图是std::adopt_lock提前解锁崩溃的图：
我们知道，当一个线程拿到一把锁之后，另一个线程只能阻塞等待该锁的释放。如果拥有该锁的线程执行时间长，另一个线程等待的时间也长，那么我们能不能让它不等待呢？当然可以，这时候try_to_lock就出现了。
2）std::try_to_lock
std::try_to_lock：表示在创建unique_lock之前不能上锁，否则程序报错崩溃。并且会尝试去上锁，若上锁失败也会立即返回，不会阻塞等待。当std::try_to_lock拿到锁后，也可以提前释放锁，但是没拿到锁不能提前释放，会崩溃。
#include<iostream>
#include<thread>
#include<string>
#include<vector>
#include<list>
#include<mutex>
using namespace std;
//准备用成员函数作为线程函数的方法写线程，成为消息处理类
class A{
public:
//把收到的消息入到一个队列的线程
void inMsgRecvQueue(){
for (int i = 0; i < 10000; i++){
cout << "inMsgRecvQueue()执行，插入一个元素" << i << endl;
//my_mutex1.lock();//不能先上锁，否则程序崩溃
unique_lock<mutex> uLock1(my_mutex1, std::try_to_lock);
if (uLock1.owns_lock()) {
//拿到了锁
msgRecvQueue.push_back(i);
//uLock1.unlock();//ok,拿到锁可以提前释放，然后可以处理其它非共享代码
//处理其他非共享代码
}
else {
//没拿到锁
cout << "inMsgRecvQueue()执行，但没拿到锁头，只能干点别的事" << i << endl;
//uLock1.unlock();//error，没拿到锁不能释放
}
}
}
//将共享的代码放到一个函数处理,方便上锁解锁
bool outMsgLULProc(int &command){
unique_lock<mutex> uLock1(my_mutex1, std::try_to_lock);
if (uLock1.owns_lock()) {
if (!msgRecvQueue.empty()) {
int command = msgRecvQueue.front();
msgRecvQueue.pop_front();
//uLock1.unlock();//ok,拿到锁可以提前释放，然后可以处理其它非共享代码
return true;
}
}
else {
//没拿到锁
cout << "outMsgLULProc()执行，但没拿到锁头，只能干点别的事" << endl;
}
return false;
}
//把数据从消息队列取出的线程
void outMsgRecvQueue(){
int command = 0;
for (int i = 0; i < 10000; i++){
bool result = outMsgLULProc(command);
if (result == true){
cout << "outMsgRecvQueue()执行，取出一个元素" << endl;
//处理数据
//这里有可能也有需要共享的代码段
}
else{
//消息队列为空
cout << "outMsgRecvQueue()执行，但目前消息队列中为空！" << endl;
}
}
cout << "end!" << endl;
}
private:
std::list<int> msgRecvQueue;//容器（消息队列），代表玩家发送过来的命令。
std::mutex my_mutex1;
std::mutex my_mutex2;
};
int main()
{
A myobja;
std::thread myOutMsgObj(&A::outMsgRecvQueue, &myobja);//第二个参数，地址，才能保证线程里用的是同一个对象
std::thread myInMsgObj(&A::inMsgRecvQueue, &myobja);
myOutMsgObj.join();
myInMsgObj.join();
cout << "主线程执行！" << endl;
return 0;
}
可以看到结果，当一个程序拿到锁后，另一个程序也可以不阻塞，可以去干其它事情。
3）std::defer_lock
std::defer_lock：表示在创建unique_lock之前不能上锁，否则程序报错崩溃。
同样在拿到锁之后，可以提前释放锁，然后处理非共享代码，提高程序效率。这种也是本人推荐也用得最多的一种。
#include<iostream>
#include<thread>
#include<string>
#include<vector>
#include<list>
#include<mutex>
using namespace std;
//准备用成员函数作为线程函数的方法写线程，成为消息处理类
class A{
public:
//把收到的消息入到一个队列的线程
void inMsgRecvQueue(){
for (int i = 0; i < 10000; i++){
cout << "inMsgRecvQueue()执行，插入一个元素" << i << endl;
//my_mutex1.lock();//不能先上锁，否则程序崩溃
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
uLock1.lock();//需要自己上锁
msgRecvQueue.push_back(i);
//uLock1.unlock();//ok,拿到锁可以提前释放,然后可以处理其它非共享代码
}
}
//将共享的代码放到一个函数处理,方便上锁解锁
bool outMsgLULProc(int &command){
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
uLock1.lock();//需要自己上锁
if (!msgRecvQueue.empty()) {
int command = msgRecvQueue.front();
msgRecvQueue.pop_front();
return true;
}
//uLock1.unlock();//ok,拿到锁可以提前释放,然后可以处理其它非共享代码
return false;
}
//把数据从消息队列取出的线程
void outMsgRecvQueue(){
int command = 0;
for (int i = 0; i < 10000; i++){
bool result = outMsgLULProc(command);
if (result == true){
cout << "outMsgRecvQueue()执行，取出一个元素" << endl;
//处理数据
//这里有可能也有需要共享的代码段
}
else{
//消息队列为空
cout << "outMsgRecvQueue()执行，但目前消息队列中为空！" << endl;
}
}
cout << "end!" << endl;
}
private:
std::list<int> msgRecvQueue;//容器（消息队列），代表玩家发送过来的命令。
std::mutex my_mutex1;
std::mutex my_mutex2;
};
int main()
{
A myobja;
std::thread myOutMsgObj(&A::outMsgRecvQueue, &myobja);//第二个参数，地址，才能保证线程里用的是同一个对象
std::thread myInMsgObj(&A::inMsgRecvQueue, &myobja);
myOutMsgObj.join();
myInMsgObj.join();
cout << "主线程执行！" << endl;
return 0;
}
3 unique_lock的成员函数
实际上再讲unique_lock的参2的std::try_to_lock、std::defer_lock时已经用到了unique_lock的两个成员函数uLock1.owns_lock()与uLock1.lock()了。
1）lock()，加锁。例子看上面的std::defer_lock即可。
2）unlock(),解锁。例子同样可以看上面的std::defer_lock或者std::try_to_lock即可。
为什么unique_lock可以自动解锁还是提供手动解锁的方式呢，这是因为我们处理完某段共享代码后，可能会出现非共享代码，这时我们解锁后能提高效率。然后再出现共享代码的话我们再次上锁即可。
#include<iostream>
#include<thread>
#include<string>
#include<vector>
#include<list>
#include<mutex>
using namespace std;
//准备用成员函数作为线程函数的方法写线程，成为消息处理类
class A {
public:
//把收到的消息入到一个队列的线程
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行，插入一个元素" << i << endl;
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
//处理共享代码
uLock1.lock();
msgRecvQueue.push_back(i);
uLock1.unlock();
//处理完上面的共享代码后，可能出现非共享代码
//非共享代码
//共享代码
uLock1.lock();
uLock1.unlock();//这句可以不要,让其自动解锁,注意不要写成my_mutex1.unlock()
}
}
//将共享的代码放到一个函数处理,方便上锁解锁
bool outMsgLULProc(int &command) {
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
uLock1.lock();
if (!msgRecvQueue.empty()) {
int command = msgRecvQueue.front();
msgRecvQueue.pop_front();
//uLock1.unlock()//这句可以不要,让其自动解锁
return true;
}
//uLock1.unlock();//这句可以不要,让其自动解锁
return false;
}
//把数据从消息队列取出的线程
void outMsgRecvQueue() {
int command = 0;
for (int i = 0; i < 10000; i++) {
bool result = outMsgLULProc(command);
if (result == true) {
cout << "outMsgRecvQueue()执行，取出一个元素" << endl;
//处理数据
//这里有可能也有需要共享的代码段
}
else {
//消息队列为空
cout << "outMsgRecvQueue()执行，但目前消息队列中为空！" << endl;
}
}
cout << "end!" << endl;
}
private:
std::list<int> msgRecvQueue;//容器（消息队列），代表玩家发送过来的命令。
std::mutex my_mutex1;
std::mutex my_mutex2;
};
int main()
{
A myobja;
std::thread myOutMsgObj(&A::outMsgRecvQueue, &myobja);//第二个参数，地址，才能保证线程里用的是同一个对象
std::thread myInMsgObj(&A::inMsgRecvQueue, &myobja);
myOutMsgObj.join();
myInMsgObj.join();
cout << "主线程执行！" << endl;
return 0;
}
3）try_lock()
作用：成功上锁返回true，没拿到锁返回false。
该成员函数可以说与constexpr常量宏类型std::try_to_lock(实际为结构体)用法是一样的，同样可以不阻塞和提前解锁。所以我们可以看到，只要使用std::defer常量宏，就基本能使用C++11锁的所有功能了。
#include<iostream>
#include<thread>
#include<string>
#include<vector>
#include<list>
#include<mutex>
using namespace std;
//准备用成员函数作为线程函数的方法写线程，成为消息处理类
class A {
public:
//把收到的消息入到一个队列的线程
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行，插入一个元素" << i << endl;
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
if (uLock1.try_lock()) {
msgRecvQueue.push_back(i);
uLock1.unlock();//ok,上锁成功可以提前解锁
}
else {
cout << "没上锁成功，干点别的事情" << endl;
//uLock1.unlock();//error，没上锁不能解锁
}
}
}
//将共享的代码放到一个函数处理,方便上锁解锁
bool outMsgLULProc(int &command) {
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
uLock1.lock();
if (!msgRecvQueue.empty()) {
int command = msgRecvQueue.front();
msgRecvQueue.pop_front();
//uLock1.unlock()//这句可以不要,让其自动解锁
return true;
}
//uLock1.unlock();//这句可以不要,让其自动解锁
return false;
}
//把数据从消息队列取出的线程
void outMsgRecvQueue() {
int command = 0;
for (int i = 0; i < 10000; i++) {
bool result = outMsgLULProc(command);
if (result == true) {
cout << "outMsgRecvQueue()执行，取出一个元素" << endl;
//处理数据
//这里有可能也有需要共享的代码段
}
else {
//消息队列为空
cout << "outMsgRecvQueue()执行，但目前消息队列中为空！" << endl;
}
}
cout << "end!" << endl;
}
private:
std::list<int> msgRecvQueue;//容器（消息队列），代表玩家发送过来的命令。
std::mutex my_mutex1;
std::mutex my_mutex2;
};
int main(){
A myobja;
std::thread myOutMsgObj(&A::outMsgRecvQueue, &myobja);//第二个参数，地址，才能保证线程里用的是同一个对象
std::thread myInMsgObj(&A::inMsgRecvQueue, &myobja);
myOutMsgObj.join();
myInMsgObj.join();
cout << "主线程执行！" << endl;
return 0;
}
结果：可以看到，都是能稳定运行的，和std::try_to_lock常量宏一样，不会阻塞并且都是能提前解锁的，或者说，只要是std::defer常量宏，都能够提前解锁。
4）release()成员函数
release()的作用：
- 1）返回它所管理的mutex对象指针，并释放所有权；也就是说，这个unique_lock和mutex不再有关系。严格区分unlock()与release()的区别，不要混淆。
- 2）如果原来mutex对像处于加锁状态，你有责任接管过来并负责解锁。也就是说，类似移动语义将该对象交给你，原来什么状态的就处于什么状态。
代码案例讲解release成员函数。为了方便，我们将try_lock()成员函数的代码例子中，只修改inMsg。
//注：以下代码都是正确的。
/*
1 接管的是上锁状态的锁
*/
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行，插入一个元素" << i << endl;
unique_lock<mutex> uLock1(my_mutex1);//已经上锁
mutex *tmpMyx = uLock1.release();//接管已上锁的mutex，移动语义，可自行断点查看地址
msgRecvQueue.push_back(i);
tmpMyx->unlock();//需要自行解锁，否则程序出现崩溃
}
}
//或者可以写成这样
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行，插入一个元素" << i << endl;
my_mutex1.lock();
unique_lock<mutex> uLock1(my_mutex1, std::adopt_lock);//已经上锁
mutex *tmpMyx = uLock1.release();//接管已上锁的mutex，移动语义，可自行断点查看地址
msgRecvQueue.push_back(i);
tmpMyx->unlock();//需要自行解锁，否则程序出现崩溃
}
}
/*
2 接管的是未上锁状态的锁
*/
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行，插入一个元素" << i << endl;
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
mutex *tmpMyx = uLock1.release();//接管未上锁的mutex，自行上锁
tmpMyx->lock();
msgRecvQueue.push_back(i);
tmpMyx->unlock();//需要自行解锁，否则程序出现崩溃
}
}
仍需注意一点：调用release必须手动上锁解锁，否则容易出现崩溃。
下图是上锁后忘记解锁的崩溃图。
下图是release接管未上锁的锁后，上锁后也没解锁的崩溃图。
4 unique_lock所有权的传递
因为unique_lock和lock_guard、unique_ptr都一样，为独占型，要想传递，必须使用移动语义或者返回匿名对象等操作(一般只有这两种就足够了)传递所有权。
std::unique_lock<std::mutex> uLock1(my_mutex);//uLock1拥有my_mutex的所有权；uLock1可以把自己对my_mutex的所有权转移给其他的unique_lock对象；所以unique_lock对象这个mutex的所有权是可以转移，但是不能复制。
//例如
std::unique_lock<std::mutex> uLock2(uLock1);//此句是非法的，复制所有权是非法的
//正确写法：
//1)利用移动语义
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行，插入一个元素" << i << endl;
unique_lock<mutex> uLock1(my_mutex1);
unique_lock<mutex> uLock2(std::move(uLock1));//移动语义，现在uLock1指向空，uLock2指向了my_mutex
msgRecvQueue.push_back(i);
//uLock2.unlock();//ok,当unique_lock不加参2也可以提前解锁
}
}
//2)利用返回的匿名对象
std::unique_lock<std::mutex> rtn_unique_lock() {
std::unique_lock<std::mutex> tmp(my_mutex1);
return tmp;//注意并非返回tmp，而是返回tmp的复制品，也叫匿名对象
}
//把收到的消息入到一个队列的线程
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行，插入一个元素" << i << endl;
//unique_lock<mutex> uLock1(my_mutex1);
//unique_lock<mutex> uLock2(std::move(uLock1));
unique_lock<mutex> uLock2(rtn_unique_lock());//这样就将tmp中的所有权返回给uLock2，即返回tmp的unique_lock类型的匿名对象，并调用unique_lock的移动构造函数给uLock2赋值
//unique_lock<mutex> uLock2 = rtn_unique_lock();//或者这样也是和上一句一样
msgRecvQueue.push_back(i);
//uLock2.unlock();//ok,当unique_lock不加参2也可以提前解锁
}
}
可以看到结果，代码都是稳定执行的。
5 总结unique_lock所有内容
- 1）当unique_lock不加任何参数时，与lock_guard不加参数一模一样，并且可以提前手动释放锁。
- 2）unique_lock第二个参数std::adopt_lock，表示在创建unique_lock之前已经上锁了。若没上锁，则程序报错崩溃。lock_guard也有唯一的参2->std::adopt_lock，用法完全相同。并且只有该常量宏是不能手动提前解锁，否则崩溃，与lock_guard的参2->adopt_lock完全一样。与try_to_lock和defer_lock能提前解锁完全不一样。
- 3）unique_lock第二个参数std::try_to_lock，表示在创建unique_lock之前不能上锁，否则程序报错崩溃。并且会尝试去上锁，若上锁失败也会立即返回，不会阻塞等待。当std::try_to_lock拿到锁后，也可以提前释放锁，但是没拿到锁不能提前释放，会崩溃。
- 4）unique_lock第二个参数std::defer_lock，表示在创建unique_lock之前不能上锁，否则程序报错崩溃。同样在拿到锁之后，可以提前释放锁，然后处理非共享代码，提高程序效率。这种也是本人推荐也用得最多的一种。它几乎可以使用C++11所有的锁功能。
- 5）unique_lock的成员函数：lock()，加锁。
- 6）unique_lock的成员函数：unlock()，解锁。为什么unique_lock可以自动解锁还是提供手动解锁的方式呢，这是因为我们处理完某段共享代码后，可能会出现非共享代码，这时我们解锁后能提高效率。然后再出现共享代码的话我们再次上锁即可。
- 7）unique_lock的成员函数：try_lock()，作用：成功上锁返回true，没拿到锁返回false。该成员函数可以说与constexpr常量宏类型std::try_to_lock(实际为结构体)用法是一样的，同样可以不阻塞和提前解锁。所以我们可以看到，只要使用std::defer常量宏，就基本能使用C++11锁的所有功能了。
- 8）unique_lock的成员函数：release()，作用：1）返回它所管理的mutex对象指针，并释放所有权；也就是说，这个unique_lock和mutex不再有关系。严格区分unlock()与release()的区别，不要混淆。2）如果原来mutex对像处于加锁状态，你有责任接管过来并负责解锁。也就是说，类似移动语义将该对象交给你，原来什么状态的就处于什么状态。仍需注意一点：调用release必须手动上锁解锁，凡是没上锁或者忘记解锁，都会出现代码不稳定甚至出现崩溃(大部分情况)。
- 9）unique_lock所有权的传递：1）利用移动语义。2）利用匿名对象将函数内的局部对象所有权调用移动语义传出外部。并且都可以提前释放锁。再强调一点：只有std::adopt_lock宏是无法提前释放锁的。
- 10）个人建议：开发时我们只需要用unique_lock的std::defer_lock宏即可，或者直接使用lock_guard，已经完全足够我们使用各个方面。
587
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
