手撕线程与进程

前言

我们写好的一行行代码，为了让其工作起来，我们还得把它送进城（进程）里，那既然进了城里，那肯定不能胡作非为了。

城里人有城里人的规矩，城中有个专门管辖你们的城管（操作系统），人家让你休息就休息，让你工作就工作，毕竟摊位（CPU）就一个，每个人都要占这个摊位来工作，城里要工作的人多着去了。

所以城管为了公平起见，它使用一种策略（调度）方式，给每个人一个固定的工作时间（时间片），时间到了就会通知你去休息而换另外一个人上场工作。

另外，在休息时候你也不能偷懒，要记住工作到哪了，不然下次到你工作了，你忘记工作到哪了，那还怎么继续？

有的人，可能还进入了县城（线程）工作，这里相对轻松一些，在休息的时候，要记住的东西相对较少，而且还能共享城里的资源。

进程

我们编写的代码只是一个存储在硬盘的静态文件，通过编译后就会生成二进制可执行文件，当我们运行这个可执行文件后，它会被装载到内存中，接着 CPU 会执行程序中的每一条指令，那么这个==运行中的程序，就被称为「进程」==

进程的状态

• NULL -> 创建状态：一个新进程被创建时的第一个状态；
• 创建状态 -> 就绪状态：当进程被创建完成并初始化后，一切就绪准备运行时，变为就绪状态，这个过程是很快的；
• 就绪态 -> 运行状态：处于就绪状态的进程被操作系统的进程调度器选中后，就分配给 CPU 正式运行该进程；
• 运行状态 -> 结束状态：当进程已经运行完成或出错时，会被操作系统作结束状态处理；
• 运行状态 -> 就绪状态：处于运行状态的进程在运行过程中，由于分配给它的运行时间片用完，操作系统会把该进程变为就绪态，接着从就绪态选中另外一个进程运行；
• 运行状态 -> 阻塞状态：当进程请求某个事件且必须等待时，例如请求 I/O 事件；
• 阻塞状态 -> 就绪状态：当进程要等待的事件完成时，它从阻塞状态变到就绪状态；

另外，还有一个状态叫挂起状态，它表示进程没有占有物理内存空间。这跟阻塞状态是不一样，阻塞状态是等待某个事件的返回。

由于虚拟内存管理原因，进程的所使用的空间可能并没有映射到物理内存，而是在硬盘上，这时进程就会出现挂起状态，另外调用 sleep 也会被挂起。

挂起状态可以分为两种：

• 阻塞挂起状态：进程在外存（硬盘）并等待某个事件的出现；
• 就绪挂起状态：进程在外存（硬盘），但只要进入内存，即刻立刻运行；

这两种挂起状态加上前面的五种状态，就变成了七种状态变迁（留给我的颜色不多了），见如下图：

线程

在早期的操作系统中都是以进程作为独立运行的基本单位，直到后面，计算机科学家们又提出了更小的能独立运行的基本单位，也就是线程。

为什么使用线程？

我们举个例子，假设你要编写一个视频播放器软件，那么该软件功能的核心模块有三个：

• 从视频文件当中读取数据；
• 对读取的数据进行解压缩；
• 把解压缩后的视频数据播放出来；

对于单进程的实现方式，我想大家都会是以下这个方式：

对于单进程的这种方式，存在以下问题：

• 播放出来的画面和声音会不连贯，因为当 CPU 能力不够强的时候，Read 的时候可能进程就等在这了，这样就会导致等半天才进行数据解压和播放；
• 各个函数之间不是并发执行，影响资源的使用效率；

那改进成多进程的方式：

对于多进程的这种方式，依然会存在问题：

• 进程之间如何通信，共享数据？
• 维护进程的系统开销较大，如创建进程时，分配资源、建立 PCB；终止进程时，回收资源、撤销 PCB；进程切换时，保存当前进程的状态信息；

那到底如何解决呢？需要有一种新的实体，满足以下特性：

• 实体之间可以并发运行；
• 实体之间共享相同的地址空间；

这个新的实体，就是线程( *Thread* )，线程之间可以并发运行且共享相同的地址空间。

并发，以进程为例子

虽然单核的 CPU 在某一个瞬间，只能运行一个进程。但在 1 秒钟期间，它可能会运行多个进程，这样就产生并行的错觉，实际上这是并发。

什么是线程

线程是进程当中的一条执行流程。

同一个进程内多个线程之间可以共享代码段、数据段、打开的文件等资源，但每个线程都有独立一套的寄存器和栈，这样可以确保线程的控制流是相对独立的。

线程的优缺点？

线程的优点：

• 一个进程中可以同时存在多个线程；
• 各个线程之间可以并发执行；
• 各个线程之间可以共享地址空间和文件等资源；

线程的缺点：

• 当进程中的一个线程奔溃时，会导致其所属进程的所有线程奔溃。

线程与进程的比较

线程与进程的比较如下：

• 进程是资源（包括内存、打开的文件等）分配的单位，线程是 CPU 调度的单位；
• 进程拥有一个完整的资源平台，而线程只独享必不可少的资源，如寄存器和栈；
• 线程同样具有就绪、阻塞、执行三种基本状态，同样具有状态之间的转换关系；
• 线程能减少并发执行的时间和空间开销；

对于，线程相比进程能减少开销，体现在：

• 线程的创建时间比进程快，因为进程在创建的过程中，还需要资源管理信息，比如内存管理信息、文件管理信息，而线程在创建的过程中，不会涉及这些资源管理信息，而是共享它们；
• 线程的终止时间比进程快，因为线程释放的资源相比进程少很多；
• 同一个进程内的线程切换比进程切换快，因为线程具有相同的地址空间（虚拟内存共享），这意味着同一个进程的线程都具有同一个页表，那么在切换的时候不需要切换页表。而对于进程之间的切换，切换的时候要把页表给切换掉，而页表的切换过程开销是比较大的；
• 由于同一进程的各线程间共享内存和文件资源，那么在线程之间数据传递的时候，就不需要经过内核了，这就使得线程之间的数据交互效率更高了；

所以，线程比进程不管是时间效率，还是空间效率都要高。

c++11 thread

在C++11以前，C++的多线程编程均需依赖系统或第三方接口实现，一定程度上影响了代码的移植性。C++11中，引入了boost库中的多线程部分内容，形成C++标准，形成标准后的boost多线程编程部分接口基本没有变化，这样方便了以前使用boost接口开发的使用者切换使用C++标准接口，很容易把boost接口升级为C++标准接口。

我们通过如下几部分介绍C++11多线程方面的接口及使用方法。

1. std::thread

std::thread为C++11的线程类，使用方法和boost接口一样，非常方便，同时，C++11的std::thread解决了boost::thread中构成参数限制的问题，我想这都是得益于C++11的可变参数的设计风格。

//c11.cpp
#include <iostream>
#include <thread>
void threadfun1()
{
    std::cout << "threadfun1 - 1\r\n" << std::endl;
    std::this_thread::sleep_for(std::chrono::seconds(1));
    std::cout << "threadfun1 - 2" << std::endl;
}
void threadfun2(int iParam, std::string sParam)
{
    std::cout << "threadfun2 - 1" << std::endl;
    std::this_thread::sleep_for(std::chrono::seconds(5));
    std::cout << "threadfun2 - 2" << std::endl;
}
int main()
{
    std::thread t1(threadfun1);
    std::thread t2(threadfun2, 10, "abc");
    t1.join();
    std::cout << "join" << std::endl;
    t2.detach();
    std::cout << "detach" << std::endl;
}

this_thread::sleep_for（）就是让此线程休眠，可以传入休眠的时间

this_thread::sleep_for(std::chrono::milliseconds(10));让本线程休眠10毫秒

join()就是阻塞线程，直到线程函数执行完毕，如果函数有返回值，在这里会直接忽略。阻塞的目的就是让Main主线程等待一下创建的线程，免得我函数还在跑，程序就直接结束了。

如果不想阻塞在这里就将join()换成使用线程的detach()方法，将线程与线程对象分离，线程就可以继续运行下去，并且不会造成影响。

join()的官方介绍

The function returns when the thread execution has completed.This synchronizes the moment this function returns with the completion of all the operations in the thread: This blocks the execution of the thread that calls this function until the function called on construction returns (if it hasn't yet).

• 谁调用了这个函数？调用了这个函数的线程对象，一定要等这个线程对象的方法（在构造时传入的方法）执行完毕后（或者理解为这个线程的活干完了！），这个join()函数才能得到返回。
• 在什么线程环境下调用了这个函数？上面说了必须要等线程方法执行完毕后才能返回，那必然是阻塞调用线程的，也就是说如果一个线程对象在一个线程环境调用了这个函数，那么这个线程环境就会被阻塞，直到这个线程对象在构造时传入的方法执行完毕后，才能继续往下走，另外如果线程对象在调用join()函数之前，就已经做完了自己的事情（在构造时传入的方法执行完毕），那么这个函数不会阻塞线程环境，线程环境正常执行。

举个例子

 1 void download1()
 2 {
 3     cout << "开始下载第一个视频..." << endl;
 4     for (int i = 0; i < 100; ++i) {
 5         std::this_thread::sleep_for(std::chrono::milliseconds(50));
 6         cout << "第一个视频下载进度:" << i << endl;
 7     }
 8     cout << "第一个视频下载完成..." << endl;
 9 }
10 
11 void download2()
12 {
13     cout << "开始下载第二个视频..." << endl;
14     for (int i = 0; i < 100; ++i) {
15         std::this_thread::sleep_for(std::chrono::milliseconds(80));
16         cout << "第二个视频下载进度:" << i << endl;
17     }
18     cout << "第二个视频下载完成..." << endl;
19 }
20 void process()
21 {
22     cout << "开始处理两个视频" << endl;
23 }
24 
25 int main()
26 {
27     cout << "主线程开始运行\n";
28     std::thread d2(download2);
29     download1();
30     d2.join();
31     process();
32 }

现在下载视频1需要5秒，下载视频2需要8秒，当视频1下载完成后要等待视频2下载完成才能一起进行处理，为了实现这个目的我们在30行只加入了一行代码d2.join()。

在这个场景下，我们明确两个事情：

• **谁调用了join()函数？**d2这个线程对象调用了join()函数，因此必须等待d2的下载任务结束了，d2.join()函数才能得到返回。
• **d2在哪个线程环境下调用了join()函数？**d2是在主线程的环境下调用了join()函数，因此主线程要等待d2的线程工作做完，否则主线程将一直处于block状态；这里不要搞混的是d2真正做的任务（下载）是在另一个线程做的，但是d2调用join()函数的动作是在主线程环境下做的。

互斥量的使用

在多线程环境中运行的代码段，需要考虑是否存在**竞态条件**，如果存在竞态条件，我们就说该代码段**不是线程安全的**，不能直接运行在多线程环境当中，对于这样的代码段，我们经常称之为**临界区资源**，对于临界区资源，多线程环境下需要保证它以**原子操作**执行，要保证临界区的原子操作，就需要用到线程间的互斥操作-**锁机制**，thread类库还提供了更轻量级的基于CAS操作的原子操作类。

跟往常的多线程一样，多线程在运行过程中都会对临界区进行访问，也就是一起访问共享资源。这样就会造成一个问题，当两个线程都要对一个变量int value值假如为11，加一时，线程一取出11 进行加一还没有存入value,这时候线程二又取得value的11进行加一，然后线程一存入12，线程二又存入12，这就导入两个线程访问冲突，也就是临界区问题。所以引进互斥量来解决。

#include<windows.h>
#include <iostream>
#include <chrono>
#include <thread>
#include <mutex>
using namespace std;

int number = 0;
mutex g_lock;

int ThreadProc1()
{
    
    for (int i = 0; i < 100; i++)
    {
        g_lock.lock();
        ++number;
        cout << "thread 1 :" << number << endl;
        g_lock.unlock();
        this_thread::sleep_for(std::chrono::milliseconds(10));
    }
    
    return 0;
}

int ThreadProc2()
{
    
    for (int i = 0; i < 100; i++)
    {
        g_lock.lock();
        --number;
        cout << "thread 2 :" << number << endl;
        g_lock.unlock();
        this_thread::sleep_for(std::chrono::milliseconds(10));
    }
    
    return 0;
}

int main()
{
    thread t1(ThreadProc1);
    thread t2(ThreadProc2);

    t1.detach();
    t2.detach();

    system("pause");
    return 0;
}

上面的每次都要对mutex变量进行锁以及解锁，有时候忘记解锁就凉凉了。所以c++11还提供了一个lock_guard类，它利用了RAII机制可以保证安全释放mutex。

在std::lock_guard对象构造时，传入的mutex对象(即它所管理的mutex对象)会被当前线程锁住。在lock_guard对象被析构时，它所管理的mutex对象会自动解锁，不需要程序员手动调用lock和unlock对mutex进行上锁和解锁操作。lock_guard对象并不负责管理mutex对象的生命周期，lock_guard对象只是简化了mutex对象的上锁和解锁操作，方便线程对互斥量上锁，即在某个lock_guard对象的生命周期内，它所管理的锁对象会一直保持上锁状态；而lock_guard的生命周期结束之后，它所管理的锁对象会被解锁。程序员可以非常方便地使用lock_guard，而不用担心异常安全问题。

除了lock_guard，之外c++11还提供了std::unique_lock

类 unique_lock 是通用互斥包装器，允许延迟锁定、锁定的有时限尝试、递归锁定、所有权转移和与条件变量一同使用。
unique_lock比lock_guard使用更加灵活，功能更加强大。
使用unique_lock需要付出更多的时间、性能成本。

条件变量std::condition_variable的使用

std::condition_variable 是为了解决死锁而生的。当互斥操作不够用而引入的。比如，线程可能需要等待某个条件为真才能继续执行，而一个忙等待循环中可能会导致所有其他线程都无法进入临界区使得条件为真时，就会发生死锁。所以，condition_variable实例被创建出现主要就是用于唤醒等待线程从而避免死锁。std::condition_variable的 notify_one()用于唤醒一个线程；notify_all() 则是通知所有线程。
C++11中的std::condition_variable就像Linux下使用pthread_cond_wait和pthread_cond_signal一样，可以让线程休眠，直到别唤醒，现在在从新执行。线程等待在多线程编程中使用非常频繁，经常需要等待一些异步执行的条件的返回结果。