Linux C多任务编程（线程篇4）

        上一篇中我们在解决哲学家就餐问题时就出现了死锁的问题，关于死锁是我们在学习多线程时必须掌握的一个知识点，那么接下来我们就看看关于死锁得到的问题。

目录

一、死锁

1.死锁的概念

2.死锁产生的过程

3. 利用工具排查死锁问题

4.避免死锁问题的发生

5.总结 

二、锁

1.常见的几种锁

2.互斥锁与自旋锁

3.读写锁

4.乐观锁与悲观锁

5.问题  

6.总结

一、死锁

1.死锁的概念

        在多线程编程中，我们为了防止多线程竞争共享资源而导致的数据紊乱，都会在操作共享资源之前加上互斥锁，只有成功获得到锁的线程，才能操作共享资源，获取不到锁的线程就只能等待，直到锁被释放，才能再去获得锁。

        那么，当俩个线程为了保护两个不同的共享资源而使用了俩个互斥锁，麻了这个两个互斥锁应用不当时，就可能会造成俩个线程都在等待对方释放锁，在没有外力的作用下，这些线程就会一直相互等待，没有办法继续运行，这种情况就是发生了死锁。

        死锁发生的四个条件：

        1.互斥条件

        2.持有并等待条件

        3.不可剥夺条件

        4.环路等待条件

        互斥条件：多个线程不能同时使用同一个资源

        比如下图，如果线程A已持有的资源，不能同时被线程B持有，如果线程B请求获取线程A已经占用的资源，那线程B只能等待，指导线程A释放了资源。

         持有并等待条件：当线程A已持有了资源1，又想申请资源2.而资源2已经被线程C持有了。所以线程A就会处于等待状态，但是线程A在等待资源2的同时并不会释放自己已经持有的资源1。

         不可剥夺条件：当线程已经持有了资源，在自己使用完之前不能被其它线程获取，线程B如果也想使用此资源，则只能在线程A使用完并释放后才能获取。

        环路等待条件：在死锁发生的时候，两个线程获取资源的顺序构成了环形链。比如，线程 A 已经持有资源 2，而想请求资源 1， 线程 B 已经获取了资源 1，而想请求资源 2，这就形成资源请求等待的环形图。

2.死锁产生的过程

        首先我们先创建2个线程，分别为线程A和线程B，然后又俩个互斥锁，分别是mutex_A和mutex_B

pthread_mutex_t mutex_A = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t mutex_B = PTHREAD_MUTEX_INITIALIZER;

int main()
{
    pthread_t tidA, tidB;

    //创建俩个线程
    pthread_create(&tidA, NULL, threadA_proc, NULL);
    pthread_create(&tidB, NULL, threadB_proc, NULL);

    pthread_join(tidA, NULL);
    pthread_join(tidB, NULL);

    printf("exit\n");

    return 0;
}

         接下来，我们看下线程A函数做了什么

//线程函数A
void *threadA_proc(void *data)
{
    printf("thread A waiting get ResourceA \n");
    pthread_mutex_lock(&mutex_A);
    printf("thread A got ResourceA \n");

    sleep(1);
    
    printf("thread A waiting get ResourceB \n");
    pthread_mutex_lock(&mutex_B);
    printf("thread A got ResourceB \n");

    pthread_mutex_unlock(&mutex_B);
    pthread_mutex_unlock(&nutex_A);
    return (void *)0;
}

       来，捋一下A函数的过程思路：先获取互斥锁A，然后睡眠1秒。再获取互斥锁B，然后释放互斥锁B。最后释放互斥锁A。我们再看看线程B函数的过程。

//线程函数B
void *threadB_proc(void *data)
{
    printf("thread B waiting get ResourceB \n");
    pthread_mutex_lock(&mutex_B);
    printf("thread B got ResourceB \n");

    sleep(1);

    printf("thread B waiting get ResourceA \n");
    pthread_mutex_lock(&mutex_A);
    printf("thread B got ResourceA \n");

    pthread_mutex_unlock(&mutex_A);
    pthread_mutex_unlock(&mutex_B);
    return (void *)0;
}

         来，再捋一下B函数都干了嘛，先获取互斥锁B，然后睡眠1秒。再获取互斥锁B，然后释放互斥锁B。最后释放互斥锁B。最后看看运行结果图吧

         可以看到线程B在等待互斥锁A的释放，线程A在等待互斥锁B的释放，双方都在等待对方资源的释放，很明显，产生了死锁的问题。 

3. 利用工具排查死锁问题

        在Linux 下，我们可以使用 pstack + gdb 工具来定位死锁问题。

        pstack命令可以显示每个线程的栈跟踪信息（函数调用过程），它的使用方式也很简单，只需pstack<pid> 就可以了。

        那么，在定位死锁问题时，我们可以多次调用pstack命令查看线程的函数调用过程，多次吹逼结果，确定哪几个线程没有发生变化，且是因为在等待锁，那么大概率就是由于死锁问题导致的。

4.避免死锁问题的发生

        避免死锁问题只需要破坏产生死锁的四个必要条件之一就可以了。最常见的并且可行的就是使用资源有序分配法，来破坏环路等待条件。

        有序资源分配：线程A 和线程B获取资源的顺序要一样，当线程A时先尝试获取资源A，然后尝试获取资源B的时候，线程B同样也是先尝试获取资源A，然后尝试获取资源B。也就是说，线程A和线程B总是以相同的顺序申请自己想要的资源。

        我们使用资源有序分配法的方式来修改前面发生死锁的代码，我们可以不改动线程A的代码。首先我们要清楚线程A获取资源的顺序，它时先获取互斥锁A，然后获取互斥锁B。所以我们只需要间线程B改成以相同的顺序的获取资源，就可以打破死锁了。

 线程B 函数改进后的代码如下：

//线程 B 函数，同线程 A 一样，先获取互斥锁 A,然后获取互斥锁 B
void *threadB_proc(void *data)
{
    printf("thread B waiting get ResourceA \n");
    pthread_mutex_lock(&mutex_A);
    printf("thread B got ResourceA \n");

    sleep(1);

    printf("thread B waiting get ResourceB \n");
    pthread_mutex_lock(&mutex_B);
    printf("thread B got ResourceB \n");

    pthread_mutex_unlock(&mutex_B);
    pthread_mutex_unlock(&mutex_A);
    return (void *)0;
}

 执行结果如下，可以看到，没有发生死锁。

5.总结 

        简单来说，死锁的文艺的产生是由于两个或者以上线程并行执行的时候，争夺资源而互相等待造成的。死锁只有同时满足互斥、持有并等待、不可剥夺、环路等待这四个条件才会发生。所以要避免死锁问题，就是要破坏其中一个条件即可，我们最常用的方法就是使用资源有序分配法来破坏环路等待条件。

二、锁

1.常见的几种锁

        1.互斥锁

        2.自旋锁

        3.读写锁

        4.悲观锁

        5.乐观锁

        在多线程访问共享资源的时候，避免不了资源竞争而导致数据错乱的额外难题，所以我们通常为了解决这一问题，都会在访问共享资源之前加锁。接下来就上面提到的5钟锁来做一个总结。

2.互斥锁与自旋锁

        最底层的两种就是互斥锁和自旋锁，有很多高级的锁都是基于它们实现的，你可以认为它们事各种锁的地基，所以我们必须清楚他俩之间的区别和应用。

        加锁的目的就是为了保证共享资源在任意时刻里，只有一个线程访问，这样就可以避免多线程导致共享数据紊乱的问题。

        当已经有一个线程加锁后，其它线程加锁则就会失败，互斥锁和自旋锁对于加锁失败后的处理方式是不一样的：

        互斥锁加锁失败后，线程会释放CPU，给其它线程。

        自旋锁加锁失败后，线程会忙等待，直到它拿到锁。

        互斥锁是一种独占锁，比如当线程A加锁成功后，此时互斥锁已经被线程A独占了，只要线程A没有释放手中的锁，线程B加锁就会失败，于是就会释放CPU让给其它线程，既然线程B释放掉了CPU，自然线程B加锁的代码就会被阻塞。

        而对于互斥锁加锁失败而阻塞的现象，是由于操作系统内核实现的。当加锁失败时，内核会将线程置为睡眠状态，等待锁被释放后，内核会在合适的时机唤醒线程，当这个线程成功获取到锁后，于是就可以继续执行。

         所以，互斥锁加锁失败时，会从用户态陷入到内核态，让内核帮我们切换线程，虽然简化了使用锁的难度，但是存在一定的性能开销成本。

        开销成本是什么呢？会有俩次线程上下文切换的成本：

        当线程加锁失败是，内核会把线程的状态从运行状态设置为睡眠状态，然后把CPU切换给其它线程运行；

        接着，当锁被释放时，之前睡眠状态的线程会变为就绪状态，然后内核会在合适的时间，把CPU切换给该线程运行。

        这个时候有人就会问了，那你一直在说线程的上下文切换，线程上下文到底切换的是什么？

        当俩个线程是属于同一个进程，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据。

        自旋锁是通过CPU提供的CAS函数(Compard And Swap)，在用户态完成加锁和解锁操作，不会主动产生线程上下文切换，所以相比互斥锁来说，会快一些，开销也小一些。

         一般加锁的过程，包含两个步骤：

                1.第一步，查看锁的状态，如果锁是空闲的，则执行第二步。

                2.第二步，将锁设置为当前线程持有；

        CAS函数就把这两个步骤合并成一条硬件级指令，形成原子指令，这样就保证了这俩个步骤是不可分割的，要么一次性执行完这俩个步骤，要么这俩个步骤都不执行。

        比如，设锁为变量lock，整数0表示锁是空闲状态，整数pid表示线程ID，那么CAS(lock, 0, pid)就表示自旋锁的加锁操作，CAS(lock, pid, 0)则表示解锁操作。

        使用自旋锁的时候，当发生多线程竞争锁的情况，加锁失败的线程会忙等待，直到它拿到锁。这里的忙等待可以用 while 循环等待实现，不过最好是使用CPU提供的PAUSE指令来实现忙等待，因为可以减少循环等待时的耗电量。

        自旋锁是比较简单的一种锁，一直自旋，利用CPU周期，直到锁可用。需要注意，在单核CPU上，需要抢占式的调度器(即不断通过时钟中断一个线程，运行其它线程)。否则，自旋锁在单核CPU上无法使用，因为一个自旋的线程永远不会放弃CPU。

        自旋锁开销少，在多核系统下一般不会主动产生线程切换，适合异步、协程等在用户态切换请求的编程方式，但如果被锁住的代码执行时间过长，自旋的线程会长时间占用CPU资源，所以自旋的时间和被锁住的代码执行的时间是成正比的关系，我们需要清楚的直到这一点。

        自旋锁与互斥锁使用层面比较相似，但实现层面上完全不同：当加锁失败时，互斥锁用线程切换来应对，自旋锁则用满等待来对应。

        应用场景：

         这里涉及到线程上下文切换的问题，如果你锁住的代码执行时间比较短，那可能上下文切换的时间都比你锁住的代码执行时间还要长。所以，如果被锁住的代码执行时间很短，就不应该用互斥锁，而应该选用自旋锁，否则使用互斥锁。

3.读写锁

        读写锁从字面意思我们也可以知道，它是由读锁和写锁两部分构成，如果只读取共享资源用读锁加锁，如果要修改共享资源则用写锁加锁。读写锁适用于能明确区分读操作和写操作的场景。

        读写锁的工作原理：

        当写锁没有被线程持有时，多个线程能够并发地持有读锁，这大大提高了共享资源地访问效率，因为读锁是用于读取共享资源的场景，所以多个线程同时持有读锁也不会破坏共享资源的数据。

        但是，一旦写锁被线程持有后，读线程的获取读锁的操作会被阻塞，而且其他写线程的获取写锁的操作也会被阻塞。

        所以，写锁是独占锁，因为任何时刻只能有一个线程持有写锁，类似互斥锁和自旋锁，而读锁是共享锁，因为读锁可以被多个线程同时持有。

        既然知道了读写锁的工作原理，不知道你们有没有一种感觉，读写锁在读多写少的场景，能发挥出优势。 

        读写锁可以根据实现的不同可以分为读优先锁和写优先锁。

        读优先锁期望的是，读锁能被更多的线程持有，以便提高读线程的并发性，它的工作方式是：当读线程A先持有了读锁，写线程B在获取写锁的时候，会被阻塞，并且在阻塞过程钟，后续来得读线程C仍然可以成功获取读锁，最后知道读线程A和C时释放读锁后，写线程B可以成功释放写锁。

         写优先锁是优先服务写线程，其工作方式是：当读线程A先持有了读锁，写线程B在获取写锁得时候，会被阻塞，并且在阻塞过程中，后续来的读线程C获取读锁时会失败，于是读线程C将被C将被阻塞在获取读锁的操作，这样只要读线程A释放读锁后，写线程B就可以成功获得写锁。

         读优先锁对于读线程并发性更好，但也不是没有问题，我们回想一下上一篇的读者写者问题，是不是感觉有些地方很相似呢。同样的如果一直有读线程获取读锁，那么写线程将永远获取不到写线程，这就造成了写线程饥饿的现象。

        写优先锁可以保证写线程不会饿死，但如果一直由写线程获取写锁，读线程也会被饿死。

        既然不管优先读还是优先写，都有可能造成另一方出现饿死的问题，那我们就不偏袒任何一方，来一个公平读写锁。

        公平读写锁比较简单的一种方式是：用队列把获取锁的线程排队面不广是写线程还是读线程都按照先进先出的原则加锁即可，这样读线程仍然可以并发，也不会出现饥饿现象。

4.乐观锁与悲观锁

        前面提到的互斥锁、自旋锁、读写锁都属于悲观锁。

        悲观锁做事比较悲观，它认为多线程同时修改共享资源的概率比较高，于是很容易出现冲突，所以访问共享资源前，先要上锁。

        乐观锁做事比较客观，它假定冲突的概率比较低，它的工作方式是：先修改完共享资源，再验证这段时间内没有发生冲突，如果没有其他线程在修改资源，那么操作完成，如果发现由其它线程已经修改过这个资源，就放弃本次操作。乐观锁全程并没有加锁，所以它也叫无锁编程。

        乐观锁虽然去除了加锁解锁的操作，但是一旦发生冲突，重试的成本非常高，所以只有在冲突概率非常低，且加锁成本非常高的场景时，才考虑使用乐观锁。

5.问题  

CAS 不是乐观锁吗，为什么基于 CAS 实现的自旋锁是悲观锁？

        乐观锁是先修改同步资源，再验证有没有发生冲突。

        悲观锁是修改共享数据前，都要先加锁，防止竞争。

        CAS 是乐观锁没错，但是 CAS 和自旋锁不同之处，自旋锁基于 CAS 加了while 或者睡眠 CPU 的操作而产生自旋的效果，加锁失败会忙等待直到拿到锁，自旋锁是要需要事先拿到锁才能修改数据的，所以算悲观锁。

6.总结

        我们在开发中最常见的就是互斥锁的了，互斥锁加锁失败时，费用线程切换来应付，当加锁失败的线程再次加锁成功后的这一过程，会有俩次线程上下文切换的成本，性能损耗比较大。

        如果我们明确知道被锁住的代码的执行时间很短，那我们应该选择开销比较小的自旋锁，因为自旋锁加锁失败时，并不会主动产生线程切换，而是一直忙等待，直到获取到锁，那么如果被锁住的代码执行时间很短，那这个忙等待的时间相对应也很短。

        如果能区分读操作和写操作的场景，那读写锁就更合适了，它允许多个读线程可以同时持有读锁，提高了读的并发性。根据偏袒读方还是写方，可以分为读优先锁和写优先锁，读优先锁并发性很强，但是写线程会被饿死，而写优先锁会优先服务写线程，读线程也可能会被饿死，那为了避免饥饿的问题，于是就有了公平读写锁，它是用队列把请求锁的线程排队，并保证先入先出的原则来对线程加锁，这样便保证了某种线程不会被饿死，通用性也更好点。

        互斥锁和自旋锁都是最基本的锁，读写锁可以根据场景来选择这两种锁其中的一个进行实现。

        另外，互斥锁、自旋锁、读写锁都属于悲观锁，悲观锁认为并发访问共享资源时，冲突概率可能非常高，所以在访问共享资源前，都需要先加锁。

        相反的，如果并发访问共享资源时，冲突概率非常低的话，就可以使用乐观锁，它的工作方式是，在访问共享资源时，不用先加锁，修改完共享资源后，再验证这段时间内有没有发生冲突，如果没有其他线程在修改资源，那么操作完成，如果发现有其他线程已经修改过这个资源，就放弃本次操作。

        但是，一旦冲突概率上升，就不适合使用乐观锁了，因为它解决冲突的重试成本非常高。

        总之，不管使用的哪种锁，我们的加锁的代码范围应该尽可能的小，也就是加锁的粒度要小，这样执行速度会比较快。再来，使用上了合适的锁，就会快上加快了。