Linux线程池

前言

线程池是一种管理线程的机制，它可以在需要时自动创建和销毁线程，以及分配和回收线程资源。线程池的主要优点是减少了频繁创建和销毁线程所带来的开销，提高了系统的稳定性和可扩展性。此外，线程池还可以有效地控制线程的数量，避免过多线程导致的资源竞争和系统过载

一、何为线程池

1.1 池化技术

所谓的 线程池 就是 提前创建一批线程，当任务来临时，线程直接从任务队列中获取任务执行，可以提高整体效率；同时一批线程会被合理维护，避免调度时造成额外开销

像这种把未来会高频使用到，并且创建较为麻烦的资源提前申请好的技术称为 池化技术，池化技术 可以极大地提高性能，最典型的就是 线程池，常用于各种涉及网络连接相关的服务中，比如 MySQL 连接池、HTTP 连接池、Redis 连接池 等

除了线程池外还有内存池，比如 STL 中的容器在进行空间申请时，都是直接从 空间配置器 allocator 中获取的，并非直接使用系统调用来申请空间

池化技术 的本质：空间换时间

池化技术 就好比你把钱从银行提前取出一部分放在支付宝中，可以随时使用，十分方便和高效，总不至于需要用钱时还得跑到银行排队取钱

1.2 线程池的优点

线程池 的优点在于 高效、方便

线程在使用前就已经创建好了，使用时直接将任务交给线程完成
线程会被合理调度，确保任务与线程间能做到负载均衡

线程池 中的线程数量不是越多越好，因为线程增多会导致调度变复杂，具体创建多少线程取决于具体业务场景，比如 处理器内核、剩余内存、网络中的 socket 数量等

线程池 还可以配合 「生产者消费者模型」 一起使用，做到 解耦与提高效率

可以把 任务队列 换成 「生产者消费者模型」

1.3 线程池的应用

线程池 有以下几种应用场景：

存在大量且短小的任务请求，比如 Web 服务器中的网页请求，使用 线程池 就非常合适，因为网页点击量众多，并且大多都没有长时间连接访问
对性能要求苛刻，力求快速响应需求，比如游戏服务器，要求对玩家的操作做出快速响应
突发大量请求，但不至于使服务器产生过多的线程，短时间内，在服务器创建大量线程会使得内存达到极限，造成出错，可以使用 线程池 规避问题

二、线程池模拟

实现最基本的线程池功能，直接使用系统提供的接口

不加任何优化设计，只实现 线程池 最基础的功能，便于理解 线程池

创建 ThreadPool_v1.hpp 头文件

将 线程池 实现为一个类，提供接口供外部调用

首先要明白 线程池 的两大核心：一批线程 与 任务队列，客户端发出请求，新增任务，线程获取任务，执行任务，因此 ThreadPool_v1.hpp 的大体框架如下

一批线程，通过容器管理
任务队列，存储就绪的任务
互斥锁
条件变量

互斥锁 的作用是 保证多个线程并访问任务队列时的线程安全，而 条件变量 可以在 任务队列 为空时，让一批线程进入等待状态，也就是线程同步

注：为了方便实现，直接使用系统调用接口及容器，比如 pthread_t、vector、queue 等

#pragma once#include <vector>
#include <string>
#include <queue>
#include <memory>
#include <unistd.h>
#include <pthread.h>namespace Yohifo
{
#define THREAD_NUM 10template<class T>class ThreadPool{public:ThreadPool(int num = THREAD_NUM):_threads(num), _num(num){// 初始化互斥锁和条件变量pthread_mutex_init(&_mtx, nullptr);pthread_cond_init(&_cond, nullptr);}~ThreadPool(){// 互斥锁、条件变量pthread_mutex_destroy(&_mtx);pthread_cond_destroy(&_cond);}void init(){// 其他信息初始化（当前不需要）}void start(){// 启动线程池// ...}// 提供给线程的回调函数static void *threadRoutine(void *args){// 业务处理// ...}private:std::vector<pthread_t> _threads;int _num; // 线程数量std::queue<T> _tasks; // 利用 STL 自动扩容的特性，无需担心容量pthread_mutex_t _mtx;pthread_cond_t _cond;};
}

注意：

需要提前给 vector 扩容，避免后面使用时发生越界访问
提供给线程的回调函数需要设置为静态，否则线程调不动（参数不匹配）

初始化线程池 init() — 位于 ThreadPool 类

当前场景只需要初始化 互斥锁 和 条件变量，在 构造函数 中完成就行了，所以这里的 init() 函数不需要补充

ThreadPool完成结构如下

Pool.cc结构如下

可以看出，结果如下：

三、单例模式

3.1 什么是单例模式

代码构建类，类实例化出对象，这个实例化出的对象也可以称为实例，比如常见的 STL 容器，在使用时，都是先根据库中的类，形成一个实例以供使用；正常情况下，一个类可以实例化出很多很多个对象，但对于某些场景来说，是不适合创建出多个对象的

比如本文中提到的 线程池，当程序运行后，仅需一个 线程池对象 来进行高效任务计算，因为多个 线程池对象 无疑会大大增加调度成本，因此需要对 线程池类 进行特殊设计，使其只能创建一个对象，换句话说就是不能让别人再创建对象

正如 一山不容二虎 一样，线程池 对象在一个程序中是不推荐出现多个的

在一个程序中只允许实例化出一个对象，可以通过 单例模式 来实现，单例模式 是非常 经典、常用、常考 的设计模式

什么是设计模式？
设计模式就是计算机大佬们在长时间项目实战中总结出来的解决方案，是帮助菜鸡编写高质量代码的利器，常见的设计模式有单例模式、建造者模式、工厂模式、代理模式等

3.2 单例模式的特点

单例模式 最大的特点就是 只允许存在一个对象（实例），这就好比现在的 一夫一妻制 一样，要是在古代，单例模式 肯定不被推崇

在很多服务器开发场景中, 经常需要让服务器加载很多的数据 (上百 GB) 到内存中，此时往往要用一个单例的类来管理这些数据；在我们今天的场景中，也需要一个 单例线程池 来协同生产者与消费者

3.3 单例模式的模拟

单例模式 有两种实现方向：饿汉与懒汉，它们避免类被再次创建出对象的手段是一样的：构造函数私有化、删除拷贝构造

只要外部无法访问 构造函数，那么也就无法构建对象了，比如下面这个类 Signal

单例类 Signal

#pragma once#include <iostream>namespace Yohifo
{class Signal{private:// 构造函数私有化Signal(){}// 删除拷贝构造Signal(const Signal&) = delete;};
}

当外界试图创建对象时

当然这只实现了一半，还有另一半是 创建一个单例对象，既然外部受权限约束无法创建对象，那么类内是肯定可以创建对象的，只需要创建一个指向该类对象的 静态指针 或者一个 静态对象，再初始化就好了；因为外部无法访问该指针，所以还需要提供一个静态函数 getInstance() 以获取单例对象句柄，至于具体怎么实现，需要分不同方向（饿汉 or 懒汉）

#pragma once#include <iostream>namespace Yohifo
{class Signal{private:// 构造函数私有化Signal(){}// 删除拷贝构造Signal(const Signal&) = delete;public:// 获取单例对象的句柄static Signal *getInstance(){return _sigptr;}void print(){std::cout << "Hello Signal!" << std::endl;}private:// 指向单例对象的静态指针static Signal *_sigptr;};
}

注意： 构造函数不能只声明，需要实现，即使什么都不写

为什么要删除拷贝构造？
如果不删除拷贝构造，那么外部可以借助拷贝构造函数，拷贝构造出一个与单例对象一致的 “对象”，此时就出现两个对象，这是不符合单例模式特点的

为什么要创建一个静态函数？
单例对象也需要被初始化，并且要能被外部使用
调用链逻辑：通过静态函数获取句柄（静态单例对象地址）-> 通过地址调用该对象的其他函数

3.3.1 饿汉模式

张三总是很饿，尽管饭菜还没准备好，他就已经早早的把碗洗好了，等到开饭时，直接开干

饿汉模式 也是如此，在程序加载到内存时，就已经早早的把 单例对象 创建好了（此时程序服务还没有完全启动），也就是在外部直接通过 new 实例化一个对象，具体实现如下

#pragma once#include <iostream>namespace Yohifo
{// 饿汉模式class Signal{private:// 构造函数私有化Signal(){}// 删除拷贝构造Signal(const Signal&) = delete;public:static Signal *getInstance(){return _sigptr;}void print(){std::cout << "Hello Signal!" << std::endl;}private:// 指向单例对象的静态指针static Signal *_sigptr;};Signal* Signal::_sigptr = new Signal();
}

注：在程序加载时，该对象会被创建

这里的 单例对象 本质就有点像 全局变量，在程序加载时就已经创建好了

外部可以直接通过 getInstance() 获取 单例对象 的操作句柄，来调用类中的其他函数

main.cc

#include <iostream>
#include "Signal.hpp"int main()
{Yohifo::Signal::getInstance()->print();return 0;
}

这就实现了一个简单的 饿汉版单例类，除了创建 static Signal* 静态单例对象指针 外，也可以直接定义一个 静态单例对象，生命周期随进程，不过要注意的是：getInstance() 需要返回的也是该静态单例对象的地址，不能返回值，因为拷贝构造被删除了；并且需要在类的外部初始化该静态单例对象

#pragma once#include <iostream>namespace Yohifo
{// 饿汉模式class Signal{private:// 构造函数私有化Signal(){}// 删除拷贝构造Signal(const Signal&) = delete;public:static Signal *getInstance(){return &_sig;}void print(){std::cout << "Hello Signal!" << std::endl;}private:// 静态单例对象static Signal _sig;};// 初始化Signal Signal::_sig;
}

饿汉模式 是一个相对简单的单例实现方向，只需要在类中声明，在类外初始化就行了，但它也会带来一定的弊端：延缓服务启动速度

完全启动服务是需要时间的，创建 单例对象 也是需要时间的，饿汉模式 在服务正式启动前会先创建对象，但凡这个单例类很大，服务启动时间势必会受到影响，大型项目启动，时间就是金钱

并且由于 饿汉模式 每次都会先创建 单例对象，再启动服务，如果后续使用 单例对象 还好说，但如果后续没有使用 单例对象，那么这个对象就是白创建了，在延缓服务启动的同时造成了一定的资源浪费

综上所述，饿汉模式 不是很推荐使用，除非图实现简单，并且服务规模较小；既然 饿汉模式 有缺点，就需要改进，于是就出现了 懒汉模式

3.3.2 懒汉模式

李四也是个很饿的人，他也有一个自己的碗，吃完饭后碗会脏，但他不像张三那样极端，李四比较懒，只有等他吃饭的时候，他才会去洗碗，李四这种做法让他感到无比轻松

在 懒汉模式 中，单例对象 并不会在程序加载时创建，而是在第一次调用时创建，第一次调用创建后，后续无需再创建，直接使用即可

#pragma once#include <iostream>namespace Yohifo
{// 懒汉模式class Signal{private:// 构造函数私有化Signal(){}// 删除拷贝构造Signal(const Signal&) = delete;public:static Signal *getInstance(){// 第一次调用才创建if(_sigptr == nullptr){_sigptr = new Signal();}return _sigptr;}void print(){std::cout << "Hello Signal!" << std::endl;}private:// 静态指针static Signal *_sigptr;};// 初始化静态指针Signal* Signal::_sigptr = nullptr;
}

注意： 此时的静态指针需要初始化为 nullptr，方便第一次判断

这样看来，懒汉模式 确实优秀，实现起来也不麻烦，为什么会说 饿汉模式 更简单呢？

这是因为当前只是单线程场景，程序暂时没啥问题，如果当前是多线程场景，问题就大了，如果一批线程同时调用 getInstance()，同时认定 _sigptr 为空，就会创建多个 单例对象，这是不合理的

就是说当前实现的 懒汉模式 存在严重的线程安全问题

如何证明？
简单改一下代码，每创建一个单例对象，就打印一条语句，将代码放入多线程环境中测试

获取单例对象句柄 getInstance() — 位于 Signal 类

static Signal *getInstance()
{// 第一次调用才创建if(_sigptr == nullptr){std::cout << "创建了一个单例对象" << std::endl;_sigptr = new Signal();}return _sigptr;
}

源文件 main.cc

其中使用了 lambda 表达式来作为线程的回调函数，重点在于查看现象

#include <iostream>
#include <pthread.h>
#include "Signal.hpp"int main()
{// 创建一批线程pthread_t arr[10];for(int i = 0; i < 10; i++){pthread_create(arr + i, nullptr, [](void*)->void*{// 获取句柄auto ptr = Yohifo::Signal::getInstance();ptr->print();return nullptr;}, nullptr);}for(int i = 0; i < 10; i++)pthread_join(arr[i], nullptr);return 0;
}

结果如下：

当前代码在多线程环境中，同时创建了多个 单例对象，因此是存在线程安全问题的

饿汉模式没有线程安全问题吗？
没有，因为饿汉模式下，单例对象一开始就被创建了，即便是多线程场景中，也不会创建多个对象，它们也做不到

3.3.3 懒汉模式（安全版）

有问题就解决，解决多线程并发访问的利器是 互斥锁，那就创建 互斥锁 保护单例对象的创建

#pragma once#include <iostream>
#include <mutex>namespace Yohifo
{// 懒汉模式class Signal{private:// 构造函数私有化Signal(){}// 删除拷贝构造Signal(const Signal&) = delete;public:static Signal *getInstance(){// 加锁保护pthread_mutex_lock(&_mtx);if(_sigptr == nullptr){std::cout << "创建了一个单例对象" << std::endl;_sigptr = new Signal();}pthread_mutex_unlock(&_mtx);return _sigptr;}void print(){std::cout << "Hello Signal!" << std::endl;}private:// 静态指针static Signal *_sigptr;static pthread_mutex_t _mtx;};// 初始化静态指针Signal* Signal::_sigptr = nullptr;// 初始化互斥锁pthread_mutex_t Signal::_mtx = PTHREAD_MUTEX_INITIALIZER;
}

注意： getInstance() 是静态函数，互斥锁也要定义为静态的，可以初始化为全局静态锁

结果是没有问题，单例对象 也只会创建一个

现在还面临最后一个问题：效率问题

当前代码确实能保证只会创建一个 单例对象，但即使后续不会创建 单例对象，也需要进行 加锁、判断、解锁 这个流程，要知道加锁也是有资源消耗的，所以这种写法不妥

解决方案是：DoubleCheck 双检查加锁

在加锁前再增加一层判断，如此一来，N 个线程，顶多只会进行 N 次 加锁与解锁，这是非常优雅的解决方案

获取静态对象句柄 getInstance() — 位于 Signal 类

static Signal *getInstance()
{// 双检查if(_sigptr == nullptr){// 加锁保护pthread_mutex_lock(&_mtx);if(_sigptr == nullptr){std::cout << "创建了一个单例对象" << std::endl;_sigptr = new Signal();}pthread_mutex_unlock(&_mtx);}return _sigptr;
}

单纯的 if 判断并不会消耗很多资源，但加锁行为会消耗资源，延缓程序运行速度，双检查加锁 可以有效避免这个问题

这是个精妙绝伦的代码设计，值得学习

所以 懒汉模式 麻烦吗？
相比于 饿汉模式，确实挺麻烦的，不仅要判断后创建 单例对象，还需要考虑线程安全问题

值得一提的是，懒汉模式 还有一种非常简单的写法：调用 getInstance() 时创建一个静态单例对象并返回，因为静态单例对象只会初始化一次，所以是可行的，并且在 C++11 之后，可以保证静态变量初始化时的线程安全问题，也就不需要 双检查加锁 了，实现起来非常简单

#pragma once#include <iostream>
#include <mutex>namespace Yohifo
{// 懒汉模式class Signal{private:// 构造函数私有化Signal(){}// 删除拷贝构造Signal(const Signal&) = delete;public:static Signal *getInstance(){// 静态单例对象，只会初始化一次，并且生命周期随进程static Signal _sig;return &_sig;}void print(){std::cout << "Hello Signal!" << std::endl;}};
}

所以如果当前的生产环境所支持的 C++ 版本为 C++11 及以后，在实现 懒汉模式 时可以选择这种简便的方式，是非常不错的；如果为了兼容性，也可以选择传统写法

注意： 静态变量创建时的线程安全问题，在 C++11 之前是不被保障的

关于 单例模式 的其他问题

new 出来的单例对象不需要销毁吗？
这个单例对象生成周期随进程，进程结束了，资源也就都被销毁了，如果想手动销毁，可以设计一个垃圾回收内部类 GC，主动去销毁单例对象

四、拓展

4.1 STL线程安全问题

STL 库中的容器是否是 线程安全 的？

答案是不是

因为 STL 设计的初衷就是打造出极致性能容器，而加锁、解锁操作势必会影响效率，因此 STL 中的容器并未考虑线程安全，在之前编写的 生产者消费者模型、线程池 中，使用了部分 STL 容器，如 vector、queue、string 等，这些都是需要我们自己去加锁、解锁，以确保多线程并发访问时的线程安全问题

从另一方面来说，STL 容器种类繁多，容器间实现方式各不相同，无法以统一的方式进行加锁、解锁操作，比如哈希表中就有锁表、锁桶两种方式

所以在多线程场景中使用 STL 库时，需要自己确保线程安全

4.2 智能指针线程安全问题

C++ 标准提供的智能指针有三种：unique_ptr、shared_ptr、weak_ptr

首先来说 unique_ptr，这是个功能单纯的智能指针，只具备基本的 RAII 风格，不支持拷贝，因此无法作为参数传递，也就不涉及线程安全问题

其次是 shared_ptr，得益于 引用计数，这个智能指针支持拷贝，可能被多线程并发访问，但标准库在设计时考虑到了这个问题，索性将 shared_ptr 对于引用计数的操作设计成了 原子操作 CAS，这就确保了它的 线程安全

至于 weak_ptr，这个就是 shared_ptr 的小弟，名为弱引用智能指针，具体实现与 shared_ptr 一脉相承，因此它也是线程安全的

4.3 其他常见锁

悲观锁：总是认为数据会被其他线程修改，于是在自己访问数据前，会先加锁，其他线程想访问时只能等待，之前使用的锁都属于悲观锁

乐观锁：并不认为其他线程会来修改数据，因此在访问数据前，并不会加锁，但是在更新数据前，会判断其他数据在更新前有没有被修改过，主要通过版本号机制和 CAS 操作实现

CAS 操作：当需要更新数据时，会先判断内存中的值与之前获取的值是否相等，如果相等就用新值覆盖旧值，失败就不断重试

自旋锁：申请锁失败时，线程不会被挂起，而且不断尝试申请锁

自旋本质上就是一个不断轮询的过程，即不断尝试申请锁，这种操作是十分消耗 CPU 时间的，因此推荐临界区中的操作时间较短时，使用 自旋锁 以提高效率；操作时间较长时，自旋锁 会严重占用 CPU 时间

自旋锁 的优点：可以减少线程切换的消耗

#include <pthread.h>pthread_spinlock_t lock; // 自旋锁类型int pthread_spin_init(pthread_spinlock_t *lock, int pshared); // 初始化自旋锁int pthread_spin_destroy(pthread_spinlock_t *lock); // 销毁自旋锁// 自旋锁加锁
int pthread_spin_lock(pthread_spinlock_t *lock); // 失败就不断重试（阻塞式）
int pthread_spin_trylock(pthread_spinlock_t *lock); // 失败就继续向后运行（非阻塞式）// 自旋锁解锁
int pthread_spin_unlock(pthread_spinlock_t *lock);

就这接口风格，跟 mutex 互斥锁 是一脉相承，可以轻易上手，将 线程池 中的 互斥锁 轻易改为 自旋锁

公平锁：一种用于同步多线程或多进程之间访问共享资源的机制，它通过使用互斥锁和相关的调度策略来确保资源的公平分配，以提高系统的性能和稳定性

非公平锁：通常使用信号量（Semaphore）或自旋锁（Spinlock）等机制。这些锁机制没有严格的按照请求的顺序来分配锁，而是以更高的性能为目标，允许一些线程或进程在较短时间内多次获取锁资源，从而减少了竞争开销

4.4 读者写者模式

除了 生产者消费者模型 外，还有一个 读者写者模型，用来解决 读者写者 问题，核心思想是 读者共享，写者互斥

这就好比博客发布了，允许很多人同时读，但如果作者想要进行修改，那么其他人自然也就无法查看了，这就是一个很典型的 读者写者 问题

现实中，读者数量大多数情况下都是多于写者的，所以势必会存在很多很多读者不断读取，导致写者根本申请不到信号量，写者陷入死锁状态

总结：以上就是关于 Linux多线程【线程池】的全部内容了，作为多线程篇章的收官之作，首先学习了池化技术，了解了线程池的特性，然后又模拟了基础线程池，此线程池可以轻松应用于其他场景中，最后还学习了多线程的一些周边知识，比如线程安全、锁概念、读者写者问题。总之多线程算是正式结束了，下一篇将会打开网络的大门，冲~