资源竞争引发的线程安全问题 有如下的代码：#include<thread> #include<iostream> int globalVariable = 0; void task(){ for (int i = 0; i < 1000000; ++i) { ++globalVariable; } } int main(){ std::thread th1(task); std::thread th2(task); th1.join(); th2.join(); std::cout<<globalVariable; } 我们开了两个线程，一共执行了两次 task ，按理来讲 globalVariable 变量应该被加到 2000000 。事实上，你可跑以上代码进行验证，肯定是达不到 2000000 的！ 这又是怎么一回事呢？资源竞争的产生： 在多线程中，由于类似于并行的逻辑存在，我们可以想象一下，到 th1 调用 task 函数，且正在为 globalVariable 变量做加法操作的时候，可能此时 th2 也正在为它做加法操作，线程中也是存在对应的工作内存，不是直接更改原内存的值，而是经过 读取->执行->写入 的过程。故此时如果两个线程同时进行读取并写入，那么实际上 globalVariable 只加了1，而不是2。 故由于资源竞争的存在，导致结果小于正确的结果！如何解决资源竞争问题？ 正如标题所示，如何解决资源竞争问题呢？ 我们经过前面的分析，可知，资源竞争问题是因为并行逻辑的存在，扰乱了原本需要的有序逻辑。怎么理解呢，当多个线程同时处理同一个变量时是不安全的，我们只要让同时只有一个线程去处理这个变量即可。 上面所说的正是多线程的 原子性，执行一个操作的时候不会被其他的线程打断，或者说只能有一个线程在执行这个操作。而之前的代码中 ++globalVarible 这句正需要这样的原子性操作！ 而C++里面也有两类方法去实现这样的效果。法一：加互斥锁mutex（性能较低） 代码如下：#include<thread> #include<iostream> int globalVariable = 0; std::mutex mtx; void task(){ for (int i = 0; i < 1000000; ++i) { mtx.lock(); //上锁 ++globalVariable; mtx.unlock();//解锁 } } int main(){ std::thread th1(task); std::thread th2(task); th1.join(); th2.join(); std::cout<<globalVariable; } 这下终于可以正确的得到 2000000 这个结果了。 我们来讲讲互斥量解锁和上锁的原理： lock()：形象的描述就是，当调用这个方法的时候，会去互斥量里面拿取这把锁，如果这个锁已经被其他线程持有，则阻塞，直到其他线程把这把锁释放，每个互斥量都是一把相同的锁。 unlock()：字面意思，把我现在持有的锁给释放掉，这样就可以让其他因为没有拿到锁的线程停止阻塞，开始争抢这把锁，谁抢到了谁就能得到下一个CPU的时间片。 最终的结果就是哪个线程先拿下这把锁，那么其他线程再运行到这块代码的位置就会被阻塞，这就使得被上锁的区域是具有原子性的！这样就保证了线程的安全。法二：转用原子变量（效率更高） C++中可用模板类，把类型转为原子类型，原子变量的实现方式实际上和上锁的过程是类似，但可能由于不同编译器的实现方式，可能会调用计算机的硬件去优化这个加锁解锁的过程，所以效率会更高。 如下代码：(这时就不需要加解锁了，变量本身就是线程安全的)#include<thread> #include<iostream> std::atomic<int> globalVariable = 0; void task(){ for (int i = 0; i < 1000000; ++i) { ++globalVariable; } } int main(){ std::thread th1(task); std::thread th2(task); th1.join(); th2.join(); std::cout<<globalVariable; } 三个常用的互斥量装饰器std::lock_guard (C++11) 这是一个最简单的互斥量装饰器，就是简单的利用C++构造函数和析构函数的RAII特性，在构造的时候上锁和析构的时候解锁，并不会维持传入的互斥器状态。 故前面的代码我们可以改作：#include<thread> #include<iostream> int globalVariable =…