线程同步和线程互斥的区别_线程同步和互斥的区别

C++多线程编程，线程互斥和同步通信，死锁问题分析解决 　　C++11的多线程类thread 　　C++11之前，C++库中没有提供和线程相关的类或者接口，因此在编写多线程程序时，Windows上需要调用CreateThread创建线程，Linux下需要调用clone或者pthread线程库的接口函数pthread_create来创建线程。但是这样是直接调用了系统相关的API函数，编写的代码，无法做到跨平台编译运行。 　　C++11之后提供了thread线程类，可以很方便的编写多线程程序（注意：编译器需要支持C++11之后的语法），代码示例如下： 　　代码运行打印如下： 　　可以看到，在C++语言层面编写多线程程序，用thread线程类非常简单，定义thread对象，只需要传入相应的线程函数和参数就可以了。 　　上面同样的代码在Linux平台下面用g++编译： 　　g++ 源文件名字.cpp -lpthread 　　【注意】：需要链接pthread线程动态库，所以C++的thread类在Linux环境下使用的就是pthread线程库的相关接口。 　　然后用strace命令跟踪程序的启动过程： 　　tony@tony-virtual-machine:~/code$ strace https://zhuanlan.zhihu.com/p/a.out 　　有如下打印输出：

　　说明C++ thread线程对象启动线程的调用过程就是 thread->pthread_create->clone，还是Linux pthread线程库使用的那一套，好处就是现在可以跨平台编译运行了，在Windows上当然调用的就是CreateThread系统API创建线程了。 　　线程互斥 　　在多线程环境中运行的代码段，需要考虑是否存在竞态条件，如果存在竞态条件，我们就说该代码段不是线程安全的，不能直接运行在多线程环境当中，对于这样的代码段，我们经常称之为临界区资源，对于临界区资源，多线程环境下需要保证它以原子操作执行，要保证临界区的原子操作，就需要用到线程间的互斥操作-锁机制，thread类库还提供了更轻量级的基于CAS操作的原子操作类。 　　下面用模拟3个窗口同时卖票的场景，用代码示例一下线程间的互斥操作。 　　thread线程类库的互斥锁mutex 　　下面这段代码，启动三个线程模拟三个窗口同时卖票，总票数是100张，由于整数的- -操作不是线程安全的操作，因为多线程环境中，需要通过加互斥锁做到线程安全，代码如下示例： 　　通过上面的代码可以看到，C++11的mutex和Linux平台下pthread线程库的pthread_mutex_t互斥锁使用几乎是一样的（实际上在Linux平台下mutex就是调用的pthread_mutex_t互斥锁相关的系统函数），mutex也支持trylock活锁机制，可以自己进行测试。 　　相关视频推荐 　　聊点通俗的，自旋锁，互斥锁，原子操作，CAS 　　多进程、多线程、线程使用场景分析 　　学习地址：c/c++ linux服务器开发/后台架构师 　　需要C/C++ Linux服务器架构师学习资料加qun（资料包括C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等），免费分享

　　thread线程类库基于CAS的原子类 　　实际上，上面代码中因为tickets车票数量是整数，因此它的- -操作需要在多线程环境下添加互斥操作，但是mutex互斥锁毕竟比较重，对于系统消耗有些大，C++11的thread类库提供了针对简单类型的原子操作类，如std::atomic_int，atomic_long，atomic_bool等，它们值的增减都是基于CAS操作的，既保证了线程安全，效率还非常高。 　　下面代码示例开启10个线程，每个线程对整数增加1000次，保证线程安全的情况下，应该加到10000次，这种情况下，可以用atomic_int来实现，代码示例如下： 　　实际上，C++11类库的原子操作类，在Linux平台下调用的也是CAS（compare_and_set）相关的系统接口。 　　线程同步通信 　　多线程在运行过程中，各个线程都是随着OS的调度算法，占用CPU时间片来执行指令做事情，每个线程的运行完全没有顺序可言。但是在某些应用场景下，一个线程需要等待另外一个线程的运行结果，才能继续往下执行，这就需要涉及线程之间的同步通信机制。 　　线程间同步通信最典型的例子就是生产者-消费者模型，生产者线程生产出产品以后，会通知消费者线程去消费产品；如果消费者线程去消费产品，发现还没有产品生产出来，它需要通知生产者线程赶快生产产品，等生产者线程生产出产品以后，消费者线程才能继续往下执行。 　　C++11 线程库提供的条件变量condition_variable，就是Linux平台下的Condition Variable机制，用于解决线程间的同步通信问题，下面通过代码演示一个生产者-消费者线程模型，仔细分析代码： 　　代码运行结果如下，可以看到，生产者和消费者线程交替生产产品和消费产品，两个线程之间进行了完美的通信协调运行。 　　死锁问题案例分析解决 　　死锁的问题经常会考察到，面对哪些情况下会程序会发生死锁的问题，与其想着怎么把书上的理论背出来，不如从实践的角度举例说明，如何对死锁的问题进行分析定位，然后找到问题点进行修改。 　　当我们的程序运行时，出现假死的现象，有可能是程序死循环了，有可能是程序等待的I/O、网络事件没发生导致程序阻塞了，也有可能是程序死锁了，下面举例说明在Linux系统下如何分许我们程序的死锁问题。 　　示例： 　　当一个程序的多个线程多个互斥锁资源的时候，就有可能发生死锁问题，比如线程A先了锁1，线程B了锁2，进而线程A还需要锁2才能继续执行，但是由于锁2被线程B持有还没有释放，线程A为了等待锁2资源就阻塞了；线程B这时候需要锁1才能往下执行，但是由于锁1被线程A持有，导致A也进入阻塞。 　　线程A和线程B都在等待对方释放锁资源，但是它们又不肯释放原来的锁资源，导致线程A和B一直互相等待，进程死锁了。下面代码示例演示这个问题： 　　运行上面的程序，打印如下： 　　可以看到，线程A锁1、线程B锁2以后，进程就不往下继续执行了，一直等待在这里，如果这是我们碰到的一个问题场景，我们如何判断出这是由于线程间死锁引起的呢？ 　　先通过ps命令查看一下进程当前的运行状态和PID，如下： 　　从上面的命令可以看出，a.out进程的PID是1953，当前状态是Sl+，相当于是多线程程序，全部进入阻塞状态。 　　通过top命令再查看一下进程内每个线程具体的运行情况，如下： 　　从top命令的打印信息可以看出，所有线程都进入阻塞状态，CPU占用率都为0.0，可以排除是死循环的问题，因为死循环会造成CPU使用率居高不下，而且线程的状态也不会是S。那么接下来有可能是由于I/O网络事件没有发生使线程阻塞，或者是线程发生死锁问题了。 　　通过gdb远程调试正在运行的程序，打印进程每一个线程的调用堆栈信息，过程如下： 　　通过gdb attach pid远程调试上面的a.out进程，命令如下： 　　进入gdb调试命令行以后，打印所有线程的调用栈信息，信息如下： 　　(gdb) thread apply all bt 　　从上面的线程调用栈信息可以看到，当前进程有三个线程，分别是Thread1是main线程，Thread2是taskA线程，Thread3是taskB线程。 　　从调用栈信息可以看到，Thread3线程进入S阻塞状态的原因是因为它最后在#0 _llllock_wait () at，也就是它在等待一把锁(lock_wait)，而且堆栈信息打印的很清晰，#1 0x00007feb in __GI___pthread_mutex_lock (mutex=0x5646aabe7140 ) at …/nptl/pthread_mutex_lock.c:78，Thread3在而不到，因此进入阻塞状态了。这里结合代码分析，Thread3线程（也就是taskB）最后在这里阻塞了： 　　依然是从调用栈信息可以看到，Thread2线程进入S阻塞状态的原因是因为它最后在#0 _llllock_wait () at，也就是它在等待一把锁(lock_wait)，而且堆栈信息打印的很清晰，#1 0x00007feb in __GI___pthread_mutex_lock (mutex=0x5646aabe7180 ) at …/nptl/pthread_mutex_lock.c:78，Thread2在而不到，因此进入阻塞状态了。这里结合代码分析，Thread2线程（也就是taskA）最后在这里阻塞了： 　　void taskA() 　　{ 　　// 保证线程A先锁1 　　std::lock_guardstd::mutex lockA(mtx1); 　　std::cout << “线程A锁1” << std::endl; 　　// 线程A睡眠2s再锁2，保证锁2先被线程B，模拟死锁问题的发生 　　std::this_thread::sleep_for(std::chrono::seconds(2)); 　　// 线程A先锁2 　　std::lock_guardstd::mutex lockB(mtx2); ===》 这里阻塞了！如果不知道怎么定位到源代码行上，看下一小节！ 　　std::cout << “线程A锁2” << std::endl; 　　std::cout << “线程A释放所有锁资源，结束运行！” << std::endl; 　　} 　　既然定位到taskA和taskB线程阻塞的原因，都是因为锁不到，然后再结合源码进行分析定位，最终发现taskA之所以不到mtx2，是因为mtx2早被taskB线程了；同样taskB之所以不到mtx1，是因为mtx1早被taskA线程了，导致所有线程进入阻塞状态，等待锁资源的，但是又因为没有线程释放锁，最终导致死锁问题。（从各线程调用栈信息能看出来，这里面和I/O网络事件没什么关系） 　　怎么在源码上定位到问题代码 　　实际上，上面的代码运行一般是发布后的release版本，内部没有调试信息，我们如果想把死锁的原因定位到源码的某一行代码上，就需要一个debug版本（g++编译添加-g选项），操作如下： 　　1.编译命令 　　2. 运行代码 　　线程A锁1 　　线程B锁2 　　…(程序到这里不往下运行了) 　　3.gdb调试该进程 　　4.查看当前所有的线程 　　(gdb) info threads 　　可以看到有三个线程。 　　5.切换到线程2 　　(gdb) thread 2 　　6.查看线程2目前的调用栈信息，where或者bt命令都可以 　　(gdb) where 　　7.查看上面线程2的第5帧信息#5 0x0000b183 in taskA () at .cpp:23 　　(gdb) f 5 　　#5 0x0000b183 in taskA () at .cpp:23 　　23 std::lock_guard< std::mutex > lockB(mtx2); 　　可以看到，这里就直接定位到代码一直阻塞在了.cpp的第23行，对应的行代码是std::lock_guard< std::mutex > lockB(mtx2); 　　可以同样的步骤定位查看线程3的问题代码行。 　　死锁问题代码修改 　　既然发现了问题，那么就知道这个问题场景发生死锁，是由于多个线程多个锁资源的时候，顺序不一致导致的死锁问题，那么保证它们锁的顺序是一致的，问题就可以解决，代码修改如下： 　　程序运行正常，打印如下：线程A锁1 线程A锁2 线程A释放所有锁资源，结束运行！ 线程B锁1 线程B锁2 线程B释放所有锁资源，结束运行！ 　　【注意】：不做要书呆了，任何问题都要从实践的角度去考虑问题如何定位分析解决，理论结合实践！