linux线程完结
文章目录
前言一、线程池的实现二、了解性知识 1.其他常见的各种锁2.读者写者问题总结
前言
什么是线程池呢？
线程池一种线程使用模式。线程过多会带来调度开销，进而影响缓存局部性和整体性能。而线程池维护着多个线程，等待着监督管理者分配可并发执行的任务。这避免了在处理短时间任务时创建与销毁线程的代价。线程池不仅能够保证内核的充分利用，还能防止过分调度。可用线程数量应该取决于可用的并发处理器、处理器内核、内存、网络sockets 等的数量。 线程池的应用场景： 1. 需要大量的线程来完成任务，且完成任务的时间比较短。 WEB 服务器完成网页请求这样的务，使用线程池技术是非常合适的。因为单个任务小，而任务数量巨大，你可以想象一个热门网站的点击次数。 但对于长时间的任务，比如一个Telnet连接请求，线程池的优点就不明显了。因为 Telnet 会话时间比线程的创建时间大多了。 2. 对性能要求苛刻的应用，比如要求服务器迅速响应客户请求。 3. 接受突发性的大量请求，但不至于使服务器因此产生大量线程的应用。突发性大量客户请求，在没有线程池情况下，将产生大量线程，虽然理论上大部分操作系统线程数目最大值不是问题，短时间内产生大量线程可能使内存到达极限，出现错误.
一、线程池的实现
线程池的使用会用到我们之前自己设计的lockguard，我会将代码放在最后。
下面我们创建一个线程池文件和main.cc文件，然后先写一个线程池的框架：
const int gnum = 5;template <class T>class ThreadPool{public: ThreadPool(const int &num = gnum) : _num(num) { } ~ThreadPool() { }private: int _num; vector<pthread_t *> _threads; queue<T> _task_queue; pthread_mutex_t _mutex; pthread_cond_t _cond;};我们的线程池是用vector进行管理的，里面存放每一个线程对象的地址。然后我们还需要一个队列，这个队列存放的是线程要执行的任务，我们的目的是让多个线程去竞争任务。既然是多线程那么必须要有一把锁来防止线程安全问题，而线程每次去任务队列拿任务，如果有任务就拿没有任务就阻塞在队列中，所以我们还需要一个条件变量。接下来我们解释构造函数，我们在构造函数中需要确定线程池中要创建多少个线程，所以需要定义一个全局变量gnum来当缺省参数。
ThreadPool(const int &num = gnum) : _num(num) { pthread_mutex_init(&_mutex,nullptr); pthread_cond_init(&_cond,nullptr); for (int i = 0;i<_num;i++) { _threads.push_back(new pthread_t); } } static void* handerTask(void* args) { } ~ThreadPool() { pthread_mutex_destroy(&_mutex); pthread_cond_destroy(&_cond); for (auto& t: _threads) { delete t; } }我们在构造函数初始化的时候先将锁和条件变量初始化了，然后挨个给vector中的线程指针开一个线程的空间，并且让它们去执行handerTask方法。在析构函数中我们需要将锁和条件变量释放掉，然后挨个将vector中每个线程指针指向的资源释放。
static void* handerTask(void* args) { while (true) { sleep(1); cout<<"thread "<<pthread_self()<<"run....."<<std::endl; } return nullptr; }然后我们写一个线程启动方法让线程启动（也就是创建线程）。
void start() { for (const auto& t: _threads) { pthread_create(t,nullptr,handerTask,nullptr); cout<<pthread_self()<<"start...."<<endl; } }有了线程启动后我们就可以先写main函数测试一下我们的代码有没有问题：
#include "ThreadPool.hpp"#include <memory>int main(){ std::unique_ptr<ThreadPool<int>> tp(new ThreadPool<int>()); tp->start(); while (1) { sleep(1); } return 0;}在这里我们用了智能指针来管理线程池，然后将线程池启动，下面我们运行起来：
可以看到我们前面写的代码是没有问题的，下面我们继续编写线程池执行任务的代码：
我们的任务队列要面对多个线程来抢任务的情景，所以任务队列必须要加锁。
static void* handerTask(void* args) { while (true) { pthread_mutex_lock(&_mutex); while (_task_queue.empty()) { pthread_cond_wait(&_cond,&_mutex); } //获取任务队列中的任务 T t = _task_queue.front(); //处理任务 t(); pthread_mutex_unlock(&_mutex); } return nullptr; }加锁后我们还有判断任务队列是否为空，如果为空则需要去条件变量中等待。如果不为空我们就可以获取条件变量中的任务，然后利用仿函数去处理任务。
既然有了任务队列那么我们肯定是要向任务队列中添加任务的，所以我们再写一个Push接口：
void Push(const T& in) { pthread_mutex_lock(&_mutex); _task_queue.push(in); pthread_cond_signal(&_cond); pthread_mutex_unlock(&_mutex); }对于添加任务我们首先要做的还是先加锁，然后将任务添加进去，一旦添加了任务我们就可以唤醒阻塞在条件变量中的线程。
实际上当我们写完代码才发现handerTask这个接口是有问题的，因为我们定义的是静态成员函数，在静态成员函数内部是不可以使用普通成员变量的，这个时候我们就需要封装一批接口来供这个方法使用：
void lockQueue() { pthread_mutex_lock(&_mutex); } void unlockQueue() { pthread_mutex_unlock(&_mutex); } void condwaitQueue() { pthread_cond_wait(&_cond,&_mutex); } bool IsQueueEmpty() { return _task_queue.empty(); } T popQueue() { T t = _task_queue.front(); _task_queue.pop(); return t; }下面我们用这些接口对handerTask进行修改：
static void* handerTask(void* args) { ThreadPool<T>* threadpool = static_cast<ThreadPool<T>*>(args); while (true) { threadpool->lockQueue(); while (threadpool->IsQueueEmpty()) { threadpool->condwaitQueue(); } //获取任务队列中的任务 T t = threadpool->popQueue(); //处理任务 //t(); threadpool->unlockQueue(); t(); } return nullptr; }这样我们就完成了handerTask方法的设计，但是我们处理任务的代码是有问题的，我们设计的是多线程的模型，让多个线程共同去抢任务执行，如果我们将处理任务的方法放到锁中，那么这个处理任务的过程就变成了串行的，就不符合我们的预期了，所以我们处理任务的过程一定是在解锁后，接下来我们把前一篇文章用到的Task任务导入：
int main(){ std::unique_ptr<ThreadPool<Task>> tp(new ThreadPool<Task>()); tp->start(); int x ,y; char op; while (1) { cout<<"请输入数据1#: "; cin>>x; cout<<"请输入数据2#: "; cin>>y; cout<<"请输入你要进行的运算#: "; cin>>op; Task t(x,y,op); tp->Push(t); sleep(1); } return 0;}当然为了让运行的结果更容易观察，我们在hander方法中让线程处理完成任务后打印一下结果：
static void* handerTask(void* args) { ThreadPool<T>* threadpool = static_cast<ThreadPool<T>*>(args); while (true) { threadpool->lockQueue(); while (threadpool->IsQueueEmpty()) { threadpool->condwaitQueue(); } //获取任务队列中的任务 T t = threadpool->popQueue(); //处理任务 // t(); 注意处理任务不能放在加锁过程中，否则就变成串行的了 threadpool->unlockQueue(); t(); cout<<t.formatArg()<<"? "<<"的运算的结果为："<<t.formatRes()<<endl; } return nullptr; }下面我们看看运行后的效果：
可以看到是没有问题的。
下面我们将线程池中所有加锁的东西都用我们自己写的lockguard做一下整合：
我们先写一个接口用来拿到锁：
然后我们就可以修改一下hander方法：
static void* handerTask(void* args) { ThreadPool<T>* threadpool = static_cast<ThreadPool<T>*>(args); while (true) { T t; { LockGuard(threadpool->getMutex()); while (threadpool->IsQueueEmpty()) { threadpool->condwaitQueue(); } // 获取任务队列中的任务 t = threadpool->popQueue(); } t(); cout<<t.formatArg()<<"? "<<"的运算的结果为："<<t.formatRes()<<endl; } return nullptr; }当然我们也可以不要用匿名对象，直接定义一下，不然生命周期会有问题：
void Push(const T& in) { LockGuard lock(&_mutex); _task_queue.push(in); pthread_cond_signal(&_cond); }修改后我们重新运行一下：
可以看到是没有问题的。
下面我们将这个线程池改为单例模式：
首先将构造函数设置为私有，然后将拷贝构造和赋值删除。
下面我们定义一个静态的线程池指针：
下面我们再设计一个启动单例模式的方法：
注意我们的启动方法一般都是静态的，因为我们要求这个方法只属于这个类。
然后main函数中原来的指针就变成了用类名直接调用静态方法：
int main(){ ThreadPool<Task>::getInstance()->start(); int x ,y; char op; while (1) { cout<<"请输入数据1#: "; cin>>x; cout<<"请输入数据2#: "; cin>>y; cout<<"请输入你要进行的运算#: "; cin>>op; Task t(x,y,op); ThreadPool<Task>::getInstance()->Push(t); sleep(1); } return 0;}
然后我们运行起来也是正常的，当然我们获取单列对象的方法一个线程是没有问题的，但是当多线程并发访问就会有问题，就有可能存在多次new对象的情况，所以我们在创建单例模式的时候加一把锁：
我们这里加的锁是C++库中的，为什么不用之前的那个锁呢？因为我们的获取单例对象的函数是静态的，并且这个函数不需要传this参数，不像我们之前hander方法需要传this参数正好可以用我们之前定义的Linux中的锁。
static ThreadPool<T>* getInstance() { if (_tp == nullptr) { _mtx.lock(); if (_tp == nullptr) { _tp = new ThreadPool<T>(); } _mtx.unlock(); } return _tp; }加锁后我们的静态成员函数的代码如上，至于为什么要判断两次，这是因为我们只有第一次获取单例对象的时候才需要加锁，如果已经有对象了我们还要加锁解锁那么就会浪费资源，所以我们判断两次保证只有第一次进来创建单例对象的时候才加锁。这样就完成了一个简单的单例模式的设定。
STL中的指针是否是线程安全的？
不是 . 原因是, STL 的设计初衷是将性能挖掘到极致 , 而一旦涉及到加锁保证线程安全 , 会对性能造成巨大的影响 . 而且对于不同的容器, 加锁方式的不同 , 性能可能也不同 ( 例如 hash 表的锁表和锁桶 ). 因此 STL 默认不是线程安全 . 如果需要在多线程环境下使用 , 往往需要调用者自行保证线程安全。 智能指针是否是线程安全的 ? 对于 unique_ptr, 由于只是在当前代码块范围内生效 , 因此不涉及线程安全问题 . 对于 shared_ptr, 多个对象需要共用一个引用计数变量 , 所以会存在线程安全问题 . 但是标准库实现的时候考虑到了这个问题, 基于原子操作 (CAS) 的方式保证 shared_ptr 能够高效 , 原子的操作引用计数 .其他常见的各种锁
悲观锁：在每次取数据时，总是担心数据会被其他线程修改，所以会在取数据前先加锁（读锁，写锁，行 锁等），当其他线程想要访问数据时，被阻塞挂起。 乐观锁：每次取数据时候，总是乐观的认为数据不会被其他线程修改，因此不上锁。但是在更新数据前， 会判断其他数据在更新前有没有对数据进行修改。主要采用两种方式：版本号机制和CAS操作。 CAS操作：当需要更新数据时，判断当前内存值和之前取得的值是否相等。如果相等则用新值更新。若不相 等则失败，失败则重试，一般是一个自旋的过程，即不断重试。 自旋锁，公平锁，非公平锁等（自旋锁就是每隔一段时间轮询式的看自己是否是否需要加锁解锁）读者写者问题
读写锁 在编写多线程的时候，有一种情况是十分常见的。那就是，有些公共数据修改的机会比较少。相比较改写，它们读的机会反而高的多。通常而言，在读的过程中，往往伴随着查找的操作，中间耗时很长。给这种代码段加锁，会极大地降低我们程序的效率。那么有没有一种方法，可以专门处理这种多读少写的情况呢？ 有，那就是读写锁。 读写锁接口 设置读写优先：int pthread_rwlockattr_setkind_np(pthread_rwlockattr_t *attr, int pref);/*pref 共有 3 种选择PTHREAD_RWLOCK_PREFER_READER_NP (默认设置) 读者优先，可能会导致写者饥饿情况PTHREAD_RWLOCK_PREFER_WRITER_NP 写者优先，目前有 BUG，导致表现行为和PTHREAD_RWLOCK_PREFER_READER_NP 一致PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP 写者优先，但写者不能递归加锁*/初始化：
int pthread_rwlock_init(pthread_rwlock_t *restrict rwlock,const pthread_rwlockattr_t*restrict attr);销毁：
int pthread_rwlock_destroy(pthread_rwlock_t *rwlock);加锁和解锁：
int pthread_rwlock_rdlock(pthread_rwlock_t *rwlock);int pthread_rwlock_wrlock(pthread_rwlock_t *rwlock);int pthread_rwlock_unlock(pthread_rwlock_t *rwlock);总结
本篇文章中重点在于如何实现线程池，其他都是一些了解性的概念，对于其他种类的锁，只要学习了互斥锁其实很多接口都是和互斥锁类似的，到时候二次学习即可。