🍊一、信号量

1.1之前代码的不足之处

1.2什么是信号量

🍊二、信号量接口

🍊三、信号量版本的生产消费模型

①单生产单消费

②多生产多消费

🍊四、线程池

🍊五、线程安全的单例模式

🍊六、其他常见的各种锁

①STL,智能指针和线程安全

②其他常见的各种锁

🍊一、信号量

1.1之前代码的不足之处

一个线程在操作临界资源的时候，临界资源必须是满足条件的。可是，公共资源是否满足生产或者消费条件，我们无法直接得知(在没有访问前，无法得知)。如果事前得知满足条件，就不需要加锁让线程可以直接访问。而现在我们的代码是先加锁，再检测，再操作，再解锁。是否可以在加锁之前就检测条件呢？这样可以事前分配，提高效率！这也就是POSIX信号量的作用！

1.2什么是信号量

在谈及进程间通信时提及过信号量，没错，通俗来说，信号量就是计数器。

它就是对临界资源进行事前预订这样一个机制。只要申请到，用有信号量，未来就一定能够拥有临界资源的一部分。这也就是申请信号量的本质：对临界资源中特定小块资源的预订机制。

申请成功的一定知道能够使用，而失败的只能等待。这样由之前的先加锁再检测的代码可以优化为不检测资源，只需要检测信号量就可以了。

🍊二、信号量接口

引入环形队列&&cp问题

如果是使用环形队列来当作生产消费的缓冲区。那么我们就要考虑生产和消费在什么情况下可能访问同一个位置：

1、空的时候

2、满的时候

其他情况下生产者和消费者根本访问的就是不同的区域！

环形队列有两种方式模拟：

🍊环形队列采用数组模拟，用模运算来模拟环状特性。

🍊环形结构起始状态和结束状态都是一样的，不好判断为空或者为满，所以可以通过加计数器或标记位来判断满或者空。另外也可以预留一个空的位置，作为满的状态。

我们代码采用的是第一种方式。

为了完成环形队列cp问题，我们要做的核心工作是什么？

1、消费者不能超过生产者(因为是先生产后消费)

2、生产者不能超过消费者一圈

3、考虑生产者什么时候和消费者站在一起

对于生产者而言看中的是队列中的剩余空间--空间资源定义一个信号量；而对于消费者而言看中的是放入队列中的数据--数据资源定义一个信号量。

环形队列为空的时候，生产者可以申请成功，而消费者无法申请成功。当为满的时候，消费者可以申请成功，而生产者无法申请成功。

在这里，生产和消费的位置我们一定要想清楚，其实就是队列中的下标，而且当为空或者满的时候二者下标相同。

代码是生产慢于消费的，演示也是如此，非常典型的同步过程。

如果消费慢于生产，看到的现象是生产者先生产满队列，消费者一消费，生产者就生产，消费一个生产一个。

消费的是历史数据。

🍊三、信号量版本的生产消费模型

①单生产单消费

让生产消费比较复杂的类。

目前只是支持了单生产和单消费的互斥和同步。

②多生产多消费

申请到了空间信号量，意味着一定能进行正常的生产。那么我们是先加锁再申请信号量还是先申请信号量再加锁呢？

之前的代码：

效率更高的是先分配信号量，再加锁。在持有锁期间，可以提前先把信号量指派给不同的线程。先申请加锁再申请信号量效率非常低，意味着后续线程只能在锁的位置等。

总的代码逻辑就是申请自己关心的资源，释放对方关心的资源。

🍊四、线程池

线程池的概念：

线程池是一种线程使用模式。线程过多会带来调度开销，进而影响缓存局部性和整体性能。而线程池维护着多个线程，等待着监督管理者分配可并发执行的任务。这避免了在处理短时间任务时创建与销毁线程的代价。线程池不仅能够保证内核的充分利用，还能防止过分调度。可用线程数量应该取决于可用的并发处理器，处理器内核、内存、网络sockets等的数量。

线程池的应用场景：

1、需要大量的线程来完成任务，且完成任务的时间比较短。WEB服务器完成网页请求这样的任务，使用线程池技术是非常合适的。因为单个任务小，而任务数量巨大，你可以想象一个热门网站的点击次数。但对于长时间的任务，比如一个Telnet连接请求，线程池的优点就不明显了。因为Telnet会话时间比线程的创建时间大多了。

2、对性能要求苛刻的应用，比如要求服务器迅速相应客户请求。

3、接受突发性的大量请求，但不至于使服务器因此产生大量线程的应用。突发性大量客户请求，在没有线程池情况下，将产生大量线程，虽然理论上大部分操作系统线程数目最大值不是问题，短时间内产生大量线程可能使内存到达极限，出现错误。

线程池实例

1、创建固定数量线程池，循环从任务队列中获取任务对象。

2、获取到任务对象后，执行任务对象中的任务接口。

线程池的简单实现：

🍊五、线程安全的单例模式

单例模式是一种"经典的，常用的，常考的"设计模式。

单例模式的特点：

某些类，只具有一个对象(实例)，就称之为单例。

在很多服务器开发场景中，经常需要让服务器加载很多的数据(上百G)到内存中。此时往往要用一个单例的类来管理这些数据。

非常经典的单例模式是饿汉实现方式和懒汉实现方式。

以洗碗的例子来比拟这两种模式：

吃完饭 , 立刻洗碗 , 这种就是饿汉方式 . 因为下一顿吃的时候可以立刻拿着碗就能吃饭 .

吃完饭 , 先把碗放下 , 然后下一顿饭用到这个碗了再洗碗 , 就是懒汉方式 .

懒汉方式最核心的思想是"延时加载"，从而能够优化服务器的启动速度。

简单来说饿汉就是提前开好了空间放在那里让我们去用，而懒汉就是口头上说开了空间，实际是等到我们使用的时候再开空间。

上面的代码只需修改两处就能改成懒汉单例模式：

🍊六、其他常见的各种锁

①STL,智能指针和线程安全

STL中的容器是否是线程安全的?

不是。原因是STL的设计初衷是将性能挖掘到极致，而一旦涉及到加锁保证线程安全，会对性能造成巨大的影响。而且对于不同的容器，加锁方式的不同，性能可能也不同。因此STL默认不是线程安全，如果需要在多线程环境下使用，往往需要调用者自行保证线程安全。

智能指针是否是线程安全的?

对于 unique_ptr,由于只是在当前代码块范围内生效，因此不涉及线程安全问题。

对于shared_ptr,多个对象需要共用一个引用计数变量，所以会存在线程安全问题，但是标准库实现的时候考虑到了这个问题，基于原子操作(CAS)的方式保证shared_ptr能够高效，原子的操作引用计数。

②其他常见的各种锁

悲观锁:在每次取数据时，总是担心数据会被其他线程修改，所以会在取数据前先加锁(读锁，写锁，行锁等)，当其他线程想要访问数据时，被阻塞挂起。

乐观锁:每次取数据时候，总是乐观的认为数据不会被其他线程修改，因此不上锁。但是在更新数据前，会判断其他数据在更新前有没有对数据进行修改。主要采用两种方式:版本号机制和CAS操作。

CAS操作:当需要更新数据时，判断当前内存值和之前取得的值是否相等。如果相等则用新值更新。若不等则失败，失败则重试，一般是一个自旋的过程，即不断重试。

读写锁:在编写多线程的时候，有一种情况是十分常见的。那就是，有些公共数据修改的机会比较少。相较于改写，它们读的机会反而高的多。通常而言，在读的过程中，往往伴随着查找的操作，中间耗时很长。给这种代码段加锁，会极大地降低我们程序的效率。有没有一种方法，可以专门处理这种多读少写的情况呢?有，那就是读写锁。

这里可以简单介绍一下自旋锁和读写锁。

自旋锁

当一个线程在询问临界资源时，有两种方式，一种是挂起等待其他线程访问完临界资源，另一种就是自旋(轮询)。采用哪种方式取决于需要等待的时长问题。比如这个线程充满大量的IO操作，等待时间较长，就挂起等待。而具体采用哪种方式是程序员自己定义的，都不确定的时候可以自行测试确定效果。

它的一些接口和互斥锁设计比较相似：