C++11 thread，mutex，condition_variable，atomic，原子操作CAS，智能指针线程安全，单例模式最简单实现方式

1.thread

在c++11中，c++标准委员会开发出了thread库；接下来我们先来看看这个库的使用吧；

1.1 thread类接口介绍

1.1.1 thread类构造函数

我们thread库中的thread类的构造函数可以通过直接传递回调函数与函数的参数来构造线程：

int sub(int x, int y)
{std::cout << x - y << std::endl;return x - y;
}void add(int x, int y)
{std::cout << x + y << std::endl;
}
void test1()
{int x = 1, y = 2;std::thread t1(add, x, y);std::thread t2(sub, x, y);t1.join();t2.join();
}

现象：

相比较与linux底层的pthread_create，这里C++thread的使用更加方便，我们不需要固定线程函数的返回值，也不需要通过结构体来传递函数的多个参数，只需要通过函数的不定参数列表来传递多个不同的参数即可；

此外，线程函数删除了拷贝构造，防止了线程的拷贝，但是我们可以使用thread()空构造来创建空线程，之后再通过移动构造的方式让线程接收到线程函数：

void testfun2()
{std::cout << "我是线程函数" <<std::endl;
}void test2()
{std::vector<std::thread> v;for (int i = 0; i < 5; i++){v.push_back(std::thread());}for (auto& it : v){it = std::thread(testfun2);}for (auto& it : v){it.join();}
}

现象：

linux下的pthread-create，是通过存储pthread_t的tid，来达到存储线程的效果，而C++这里的线程想存储起来，可以通过上面创建空线程的方式存储，最后通过移动构造来创建出带有线程函数的线程；

1.1.2 thread的各种接口

其实thread类的接口并不多，底层都是封装了linux下的线程代码（windows环境下自然就是封装windows的），我们接下来直接通过使用来加深理解：

joinable ：

void testfun3()
{std::cout << "我是线程函数" << std::endl;
}
void test3()
{std::thread t1(testfun3);Sleep(10);//只是让现象更明显，忽略即可std::cout << t1.joinable() << std::endl;t1.join();std::cout << t1.joinable() << std::endl;
}

现象：

一个线程接收到线程函数时运行起来，没有被join时joinable返回值才为true；如果一个线程被join或者detach又或者只是利用thread()默认构造没有连接线程函数，joinable返回值返回为false；总之，joinable可以用来判断一个线程可不可以被join或者detach；

detach：

void testfun4()
{std::cout << "我是线程函数" << std::endl;
}
void test4()
{std::thread t1(testfun4);t1.detach();
}

在主线程不关心子进程的返回值时直接让子线程与主线程分离，主线程可以去做自己的事情，不需要阻塞的等待子线程；

get_id:

void testfun5()
{std::cout << "在线程函数中获取线程id："<<std::this_thread::get_id()<< std::endl;
}
void test5()
{std::thread t1(testfun5);std::cout <<"t1的线程id：" << t1.get_id() << std::endl;t1.join();
}

现象：

可以通过get_id获取C++自己维护的线程id，在线程外直接通过线程对象即可获取，在线程内需要通过this_thread作用域调用域中函数get_id才可以获取到线程id；

1.2 thread函数的参数

1.2.1 传递给thread的方法

thread函数的第一个参数一定是一个回调方法，这个方法可以是函数指针，仿函数lambda，还可以是function包装器，使用方式是各不相同的；

void testfun6()
{std::cout << "我是函数指针" << std::endl;
}
class fun6 {
public:void operator()(){std::cout << "我是仿函数" << std::endl;}
};
void test6()
{std::thread t1(testfun6);//函数指针std::thread t2([]()->void {std::cout << "我是lambda方法" << std::endl; });//lambdafun6 f;std::thread t3(f);//仿函数t1.join();t2.join();t3.join();
}

现象：

成功的传递了三种不同的方法（函数）；

1.2.1 传递的参数为引用时要带上ref()

void testfun7(int x,int y,int & z)
{z = x + y;
}
void test7()
{int x = 1, y = 2, z=0;std::thread t1(testfun7,x,y,z);//std::thread t1(testfun7,x,y,std::ref(z));Sleep(10);//为了防止主线程跑太快，创建线程还没有运行std::cout << z << std::endl;t1.join();
}

当我们写出上面这样的代码时，我们想要让z成为我们希望的值；

但是我们编译代码是会出现这样的报错：

当出现这样的报错时，我们就会知道是我们的参数传递出现了问题，那么为什么出现了这样的错误呢？

其实这是和thread对参数传递的处理有关；在C++中thread是被封装成为了一个类的，而这个类的构造函数接收了我们传递的参数，而构造函数会通过参数的类型来推理出模板的类型，从而将参数转化为相应的类型（和我们前面的完美转发有些类型），如果我们想要传递的是一个参数的引用，我们就需要显式的声明这个参数是引用，使得这个参数保持引用的状态一直向下传递；

将z声明为ref(z)即可

	std::thread t1(testfun7,x,y,std::ref(z));

此时再运行：

在我们的linux线程部分，似乎从来没有出现过这样的问题，这其实是C++类模板的推理所出现的问题；而在linux下的线程是通过指针转递的，所以不会出现这样的推理的问题；

介绍完线程我们接下来介绍一下与线程息息相关的mutex

2.mutex

2.1 mutex对象

mutex头文件中的mutex类是一个无法被拷贝的类，并且他的构造函数是无参的构造函数

下面是它的接口：

这些接口的使用其实和linux下线程的使用是一摸一样的，不相同的只是需要通过mutex类来调用而已；（面向对象与面向过程的区别）；其中的native_handle这个接口是开放的一个底层的接口，可以通过其去设置pthread_mutex_t类型指针指向的内容，这样就可以设置锁的某些属性，这个接口我也没用过，这里只是作为介绍，也让我自己有所了解；

此外mutex的头文件中基本的锁对象还有有这些锁对象：

2.2 mutex头文件中的其他对象

2.2.1 recursive_mutex

这个锁对象一般是用在递归函数中，用来解决递归调用时使用普通锁出现的死锁问题，在递归中，我们一般需要使用recursive_mutex而不是普通的mutex锁；

2.2.2 timed_mutex

这个锁提供了一种尝试获取锁并在一定时间后自动放弃的机制。这对于需要防止死锁或者提高线程响应性的应用场景非常有用

接下来我们在来说一说对基本锁对象封装的锁：

2.2 对基本锁的封装

锁可以保证线程的安全，但在抛异常出现时，执行流的跳转会有致命的死锁出现，那么为了解决这样的问题，RAII风格的锁就出现了：

2.2.1 lock_guard

C++封装了这样的锁，可以让锁上锁后，在这个栈帧被析构时随着栈帧自动释放锁，lock_guard就是这样的封装；

lock_guard的封装很简单没有其他的接口；

2.2.2 unique_lock

unique_lock可以说是lock_guard的提升版，不仅可以手动释放锁，还增加了时间锁的功能：

上面是对锁的介绍，接下来我们介绍一下条件变量condition_variable；

3. condition_variable

这个头文件中有这两个基本类：

其中condition_variable：

condition_variable只能与std::unique_lock<std::mutex>结合使用，如果想配合其他类型的锁使用费可以使用condition_variable_any类；

下面我们使用 condition_variable类来实现，两个不同线程分别打印1到10的奇数与偶数：

两个线程分别打印奇偶数
std::mutex mtx;
std::condition_variable cond;
int count = 1;void printOdd()
{while (true){std::unique_lock<std::mutex>lck(mtx);if (count > 10){lck.unlock();break;}while (count % 2 == 0)cond.wait(lck);if(count<=10)std::cout<<std::this_thread::get_id()<<": " << count << std::endl;count++;//lck.unlock();cond.notify_one();}
}void printEven()
{while (true){std::unique_lock<std::mutex>lck(mtx);if (count > 10){if (count % 2 == 1)lck.unlock();break;}while (count % 2 == 1)cond.wait(lck);if (count <= 10)std::cout << std::this_thread::get_id() << ": " << count << std::endl;count++;//lck.unlock();cond.notify_one();}
}int main()
{std::thread t1(printOdd);std::thread t2(printEven);t1.join();t2.join();return 0;
}

现象：

condition_variable的使用与linux下cond条件变量的使用是一样的，只不过上层语言层对其进行了封装使得其具有了跨平台性；

4.atomic

4.1 atomic的基本使用

线程安全问题出现时，我们不仅可以使用锁来控制线程安全，还可以使用atomic原子操作库中的接口来保护线程安全；

我们用这样一个场景来举例：当我们有100个线程时，每个线程对count计数器加加一万次，如果线程安全，那么最后的结果应该是100*10000=1000000，一百万，我们用下面的代码验证；

int count = 0;void add()
{for (int i = 0; i < 10000; i++){count++;}
}void testAtomic()
{std::vector<std::thread> v;for (int i = 0; i < 100; i++){v.push_back(std::thread());}for (auto& it : v){it = std::thread(add);}for (auto& it : v){it.join();}std::cout << "count :" << count << std::endl;
}

测试结果：

此时，如果按照我们平常的操作，我们会使用锁来保证线程安全，但atomic库的出现，我们可以不使用锁，我们可以这样操作：

std::atomic<int> count = 0;

仅仅只需要将我们的count变量用atomic类来包装，就可以使得count的操作是原子的；

4.2 atomic的底层

那么为什么要有这样的原子库呢？我们的锁不是已经可以解决线程安全的问题了吗，为什么还要加一个这样的atomic库呢？我们就得看看atomic的底层CAS无锁编程了；

我们可以将对atomic变量的操作看成下面这样的操作：

上面的atomic变量++操作中与平常的++操作不相同的地方是使用CAS函数来判断count位置内存中的数据是否发生了改变，如果count位置的数据发生了改变就代表有其他线程在我们进行++操作时对count进行修改，所以我们刚刚进行的++操作是无效的需要重新进行；

在atomic库中CAS检查函数的原型是这个：

template< class T >
bool atomic_compare_exchange_weak( std::atomic* obj,T* expected, T desired );
template< class T >
bool atomic_compare_exchange_weak( volatile std::atomic* obj,T* expected, T desired );

而实际实现我们可以看成这样：

bool compare_and_swap (int *addr, int oldval, int newval)
{if ( *addr != oldval ) {return false;}*addr = newval;return true;
}

如果还需要更多的了解可以看陈皓大佬的博客网站coolshell：

无锁队列的实现 | 酷壳 - CoolShell

4.3 atomic的优点

我们看了上面的CAS操作我们可以发现这样的保证线程安全的原子操作没有是锁的，这意味着我们的线程不需要对锁资源进行竞争的获取，性能优越，开销小；避免了锁的上下文切换，适合高并发的场景；但是atomic变量对于复杂的线程场景可能会出现问题，我们还是得使用锁来进行复杂逻辑的编程；

5.智能指针引用计数线程安全

在今天之前我们只会使用加锁的方式来保护引用计数的线程安全，不过今天之后，我们就可以使用atomic库来保护线程安全；

class smartPtr{
public:smartPtr(T* ptr = nullptr):_ptr(ptr), _pcount(new std::atomic<int>(1)){}template<class D>smartPtr(T* ptr,D del):_ptr(ptr), _pcount(new std::atomic<int>(1)),_del(del){}......private:T* _ptr;//int* _pcount;std::atomic<int>* _pcount;};

我们只需要将_pcount引用计数更改为atomic类型的变量的指针即可，在构造时，将_pcount初始化为指向堆区的atomic变量的指针；这里的保护很简单，我们还需要注意智能指针本身是线程安全的，但是智能指针保护的资源并不是线程安全的；

6.单例模式最简单实现方式

//单例模式最简单实现方式（懒汉）
class singleClass {
public:static singleClass& getClass(){static singleClass s;return s;}//删除构造和拷贝构造singleClass(const singleClass&) = delete;singleClass& operator=(const singleClass&) = delete;
private:singleClass(){cout << "singleClass()" << endl;}
};int main()
{singleClass::getClass();singleClass::getClass();singleClass::getClass();singleClass::getClass();singleClass::getClass();return 0;
}

现象：