线程基础

除了进程之外，线程是一个十分重要的概念，特别是随着CPU频率增长开始出现停滞，而开始往多核方向发展，多线程，作为实现软件的并发执行的一个重要方法，有着越来越重要的地位。

一、什么是线程

线程（Thread），有时也叫轻量级进程（LWP），是程序执行流和CPU调度的最小单元。一个标准的线程由线程ID，当前指令指针（PC），寄存器集合和堆栈组成。通常意义上讲，一个进程由多个线程组成，各个线程之间共享程序的内存空间（包括代码段，数据段，堆等）及一些进程级的资源（如打开文件和信号），一个进程和线程的经典关系如下：

                                  

大多数应用中，线程的数量不止一个，多个线程可以互不干扰的并发执行，并共享进程的全局变量，那么多线程的进程和单线程的进程相比，优势如下：

（1）某个操作可能会陷入长时间的等待，等待的线程会进入睡眠状态，无法继续执行，多线程可以有效的利用等待的时间，典型的例子是等待网络响应，这可能花费数秒或数十秒。

（2）某个操作（比如计算）可能花费较长时间，如果只有一个线程，程序和用户之间的交互将会中断，多线程可以让另一个线程进行交互，另一个线程进行计算。

（3）程序逻辑本身就要求并发操作，例如下载多端下载软件。

（4）多CPU或多核计算机（这种基本就是未来的主流计算机），本身具备了同时执行多个线程的能力，单线程无法发挥其本身能力。

（5）相对于多进程的应用，多线程在数据共享方面效率更高。

二、线程的访问权限

线程的访问时比较自由的，他可以访问进程内存里的所有数据，甚至包括其他线程里的堆栈（如果他知道其他线程的堆栈地址的话，这只是很少见的情况），但实际运用中线程也拥有自己的私有存储空间，包括以下几个方面：

（1）栈（尽管并非完全不被其他线程访问，但一般情况下仍然认为是线程私有的）

（2）线程局部存储（TLS），线程局部存储是某些操作系统为线程单独提供的存储空间，但通常只具有很小的容量。

（3）寄存器（包括PC寄存器）寄存器是执行流的基本数据，因此为线程私有。

以上为线程私有的，而线程之间共享的有：全局变量，堆上的数据，函数里的静态变量，程序代码（任何线程都有权利读取并执行任何代码），打开的文件（比如A线程打开的文件可以由B线程读写）

三、线程的调度与优先级

无论是多处理器还是单处理器的计算机，线程总是并发执行，当线程的数量小于处理器数量时（并且操作系统支持多处理器），线程的并发是真正意义上的并发，不同线程运行在不同的处理器上，彼此互不相。而当线程数量大于处理器数量时，线程的并发会受到一些阻碍，此时至少有一个处理器会运行多个线程。

在单处理器对应多线程的情况下，并发是一种模拟出来的状态，操作系统会让这些多线程轮流执行，每次仅执行一小段时间（通常是几十到几百毫秒）这样每个线程就看起来在同时执行。这样的一个不断在处理器上切换不同线程的行为称为线程调度。在线程调度中，线程至少有三种状态（进程也有类似的三种状态）：

（1）运行：线程正在运行

（2）就绪：此时线程可以立即执行，但CPU已经被占用

（3）等待：此时线程正在等待某一事件（通常是I/O或同步）发生，无法执行。

处于运行中的线程有一段可以执行的时间，这段时间称为时间片，当时间片用尽的时候，该线程将进入就绪状态，如果在时间片用尽之前进程就开始等待某事件，那么它将进入等待状态，每当一个线程离开运行状态时，调度系统就会选择一个其他就绪的线程继续执行，在一个处于等待状态的线程所等待的事件发生之后，该线程就进入就绪状态。

线程调度自多任务操作系统问世以来被不断提出不同方案和算法。现在主流的调度方法尽管不同，但都带有优先级调度和轮转法的痕迹。所谓轮转法，就是上面提到的让每一个线程都执行一小段时间。这决定了线程之间交错执行的特点。而优先级调度则决定了线程按什么顺序轮流执行。在具有优先级调度的系统中，线程都有各自的线程优先级。具有高优先级调度的线程会更早的执行，而低优先级的线程通常要等待系统中已经没有更高优先级的可执行线程存在时才能执行。在windows中，可以通过使用：

BOOL WINAPI SetThreadPriority(HANDLE hThread, int nPriority);

来设置系统的优先级，而Linux下与线程相关的操作则可以通过Thread库来实现。

在windows和Linux系统中，线程的优先级不仅可以通过用户手动设置，系统还会根据线程的表现自动调整优先级，使得调度更有效率。例如通常情况下，频繁进入等待状态（进入等待状态，会放弃之后仍然可占用的时间份额）的线程（例如处理I/O的 线程）比频繁进行大量计算，以至于每次都要把时间片全部用尽的线程受欢迎的多。其实道理很简单，频繁等待的线程通常只占用很少的时间，CPU也喜欢先捏软柿子。一般把频繁进入等待的线程称为IO密集型线程，而把很少等待的线程称为CPU密集型线程，IO密集型线程总是比CPU密集型线程更容易得到优先级的提升。

在优先级调度下，存在一种饿死的现象，一个线程被饿死，是说它的优先级较低，在它被执行前，总有较高优先级的线程要执行，因此这个低优先级的线程始终无法执行，当一个CPU密集型线程获得较高优先级时，许多低优先级的线程就容易饿死。而一个高优先级的IO密集型线程由于大部分时间处于等待状态，因此相对于不容易造成其他线程饿死。为了避免饿死现象，调度系统常常会逐步提升那些等待了过长时间的得不到执行的线程的优先级。在这样的手段下，一个线程只要等待了足够长时间，其优先级一定会提高到足够让它执行。

总结：在优先级调度的环境下，线程的优先级改变一般有三种方法：

（1）用户指定优先级

（2）根据进入等待状态的频繁程度提升或降低优先级

（3）长时间得不到执行而被提升优先级

四、可抢占线程和不可抢占线程

上面讨论的线程调度有一个特点：那就是线程在用尽时间片之后会被强制剥夺继续执行的权利，而进入就绪状态，这个过程就叫抢占，即之后执行的别的线程抢占了当前线程。早期系统中，线程是不可抢占的（例如windows3.1），线程必须手动发出一个放弃执行的命令，才能让其他线程得到执行，在当时的调度模型下，线程必须主动进入就绪状态，而不是靠时间片用尽来强制进入就绪状态。那如果线程始终拒绝进入就绪状态，并且也不进行任何别的操作，那么其他线程将永远无法执行。在不可抢占的线程中，线程主动放弃执行无非就两种情况：

（1）当线程试图等待某事件时（I/O等）

（2）线程主动放弃时间片

因此，在不可抢占线程执行的时候，有一个显著的特点，那就是线程调度的时机是确定的，线程调度只会发生在线程主动放弃执行或线程等待某事件发生的时候。这样就可以避免一些因为抢占式线程调度时机不确定而产生的问题（一般是线程安全的问题，下面会介绍），但即便如此，非抢占式线程在如今已经很少见。

五、Linux的多线程

windows中对进程和线程的实现就像教科书一样，因为windows内核有明确的线程和进程的概念。在windowsAPI中，可以明确的使用的API：CreateProcess和CreateThread来创建进程和线程，并有一系列的API来操作。

但对于Linux来说，线程并不是一个通用的概念。Linux对多线程的支持比较匮乏，事实上，在Linux内核中并不存在真正意义上的线程概念。Linux将所有的执行实体（无论线程还是进程）都称为任务，每一个任务在概念上都类似于一个单线程的进程，并且具有内存空间，执行实体，文件资源等。不过Linux在不同任务之间可以选择共享内存空间，所以在实际意义上，共享同一个内存空间的多个任务就构成了一个进程，这些任务也就成为了这个进程里的线程。为了便于理解，我们还是按进程、线程称呼它们。

六、线程安全

多线程程序处于一个多变的环境中，可访问的全局变量和堆数据随时可能被其它线程改变，所以多线程程序在并发时数据的一致性变得非常重要。

1、竞争与原子操作

    多线程访问共享数据可能会造成不好的结果。先看一个例子：

线程1	线程2
i = 1 ++i	--i

一般情况下，++i的实现如下：

（1）读取i到某个寄存器x上

（2）X++

（3）将X的内容给i

由于线程1和2的并发执行，而寄存器X的内容在不同线程中是不一样的，实际上，两个线程如果同时执行的话，i的结果有可能是0，1或者2。

很明显，自增（++）操作在多线程环境下会出现错误是因为这个操作被编译为汇编代码之后不止一条指令，因此在执行的时候可能刚执行一半就被调度系统打断，然后去执行别的线程的代码。我们把单指令的操作称为原子操作。因为无论如何，单条指令的执行是不会被打断的。为了避免出错，很多体系结构都提供了一些常用操作的原子指令。在windows里，有一套专门的API进行原子操作，这些API称为Interlocked API。

Windows API	作用
InterlockedExchange	原子的交换两个值
InterlockedDecrement	原子的减少一个值
InterlockedIncrement	原子的增加一个值
InterlockedXor	原子的进行异或操作

使用这些函数时，windows保证是原子操作的，可以不用担心出问题，遗憾的是尽管原子指令很方便，但是它们仅适合比较简单的特定的场合。在复杂场合下，比如想保证一个复杂的数据结构更改的原子性就有些力不从心，所以需要更加通用的操作：锁。

七：线程同步与锁

为了避免多个线程同时读写同一数据产生不可预料的结果，我们要将各个线程对同一资源的访问进行同步。所谓同步，即在一个线程访问数据未结束时，其它线程不得对其访问，即对数据的访问就原子化了。

同步最常用的方式就是锁。锁是一种非强制，每一个线程在访问数据或资源时首先得先试图获取锁，获取到锁之后才能访问数据，并在访问结束后释放锁，在锁已经被占用的时候，获取不到，线程就会等待。锁有很多种：

1、二元信号量

最简单的一个锁，它只有两个状态：占用与非占用（或者说P操作和V操作）。它只能被一个线程独占访问，当二元信号量处于非占用的状态时，第一个试图获取它的线程将会获得该锁，并将其设为占用状态。

对于允许多个线程并发访问的资源，多元信号量简称信号量。一个初始值为N的信号量允许N个线程同时访问。线程访问资源的时候，首先需要获取信号量，会进行如下操作：

（1）将信号量减1；

（2）如果信号量的值小于0，则进入等待状态，否则继续执行。

访问完资源后，线程需要释放信号量，会进行如下操作：

（1）将信号量加1；

（2）如果信号量的值大于0，则唤醒一个等待中的线程。

2、互斥量（mutex）

和信号量相似，同一资源在同一时间只允许一个线程访问。而其和信号量不同的是，信号量在整个系统中可以被任意线程获取和释放，也就是说信号量在一个系统中，可以由一个线程获取，由另一个线程释放。而互斥量要求，哪个线程获取了互斥量，这个线程就要负责释放它，其它线程释放是无效的。

3、临界区

比互斥量更加严格。进入临界区的锁的获取称为进入临界区，而把锁的释放称为离开临界区。临界区和互斥量信号量的区别在于，互斥量和信号量在系统中任何进程中都是可见的，也就是说一个进程创建了一个互斥量或信号量，另一个进程试图去获取它们是合法的。而临界区的作用范围只能在本进程中，其它进程无法获取。除此之外，临界区和互斥量具有相同性质。

4、读写锁

一种致力于更加特定的场合的同步方式。一般对于一段数据来说，多个线程同时读取是没什么问题的，但假设操作都不是原子型的，只要有任何一个线程试图对这个数据修改，那就应该使用同步手段来避免出错。思考一下，如果使用了上述的信号量、互斥量或临界区中的任何一种方式来同步，尽管能保证程序正确，但对于读取频繁，而仅仅偶尔会写入的情况，会显得很低效。那么读写锁可以避免这个问题，对于同一个锁，读写锁有两种获取方式：共享锁 和 独占锁  。

当锁处于自由的状态时，共享或独占的任何一种方式获取锁都能成功，获取后可以将锁设置对应的状态（共享状态或独占）。如果锁是处于共享的状态，其它线程以共享方式获取也能获取到，此时这个锁分配给了多个线程。而其它线程如果想以独占的方式获取处于共享状态的锁，那么必须等待锁被其它所有线程释放。相应的，处于独占状态的锁，会阻止任何其它线程获取该锁。总结如下：

读写锁的状态	以共享方式获取	以独占方式获取
自由	成功	成功
共享	成功	等待
独占	等待	等待

5、条件变量

条件变量作为一种同步手段，类似于一个栅栏，对于条件变量，线程可以有两种操作：

（1）首先线程可以等待条件变量，一个条件变量可以被多个线程等待。

（2）其次，线程可以唤醒条件变量，此时某个或所有等待此条件变量的线程都会被唤醒并继续支持，也就是说，使用条件变量可以让许多线程一起等待某个事件的发生，当事件发生时（条件变量被唤醒），所有线程回复执行。

八、可重入与线程安全

一个函数被重入，表示这个函数没有执行完成，由于外部因素或内部调用，又一次的进入该函数执行。一个函数要被重入，有两种情况：

（1）多个线程同时执行这个函数

（2）函数自身（可能经过多层调用）调用自身。

一个函数被称为可重入的，表面这个函数被重入之后不会产生任何不良后果，举个例子，如下面这个函数sqr就是可重入的：

int sqr(int x)
{
    return x * x;
}

一个函数要成为可重入，必须具有以下几个特点：

（1）不使用任何（局部）静态或全局的非const变量

（2）不返回任何（局部）静态或全局的非const变量的指针

（3）仅依赖于调用方提供的参数

（4）不依赖任何单个资源的锁（互斥量等）

（5）不调用任何不可重入的函数

可重入是并发安全的强力保障，一个可重入的函数可在多线程下放心使用。

九、过度优化

线程安全问题真是一个烫手山芋，即使使用锁，也不能百分百保证不出问题。举个例子：

x = 0;

在Thread1中：

lock();
x++;
unlock();

在Thread2中：

lock();
x++;
unlock();

由于上锁解锁，x++并不会被并发所破坏，那么x++的值必然是2了，但是，如果编译器为了提高x的访问速度，把x放入了某个寄存器里，

我们知道不同线程里的寄存器都是独立的（线程有自己的寄存器和栈），因此如果线程1先获得锁，那么上述程序的执行就可能是这样的：

（1）线程1读取了x的值到寄存器R[1]里，此时R[1] = 0;

（2）线程1，R[1]++（由于之后可能还要访问x，所以线程1暂时先不把R[1]写回x）

（3）这时线程2有开始同样的操作，此时R[2]的值为1，然后假如R[2]把值写回x，可能很久以后R[1]也写回x。

以上可以看出即使正常加锁，也不见得绝不出问题。下面是另一个例子：

x = y = 0;

Thread1:
x = 1;
r1 = y;

Thread2:
y = 1;
r2 = x;

r1 = r2 = 0是有可能发生的，早在几十年前，CPU就发展出了动态的调度，在执行过程时候为了提高效率有可能交换指令的顺序，同样编译器在进行优化的时候，也有可能为了效率交换毫不相关的两条指令（如x = 1 和r1 = y）的顺序。我们可以用volatile关键字试图阻止过度优化。valatile可以做到两件事：

（1）阻止编译器为了提高速度将一个变量缓存到寄存器内而不写回。

（2）阻止编译器调整操作volatile变量的指令顺序。

所以volatile可以完美的解决第一个 问题，但是第二个问题没法解决，即使volatile可以阻止编译器调整顺序，也无法阻止编译器动态交换顺序。再来看一个与换序有关的例子，来自单例的double-check：

volatile T* p = 0;
T* GetInstance()
{
    if(p == NULL)
    {
        lock();
        if(p == NULL)
        {
            p = new T;
        }
        unlock();
    }
    return p;
}

这里的双重if判断是为了避免频繁lock。代码看着是没问题的，函数返回时，p总能指向一个有效对象，lock和unlock也能防止多线程竞争。但实际上这样的代码是有问题的，问题依然来于CPU的乱序执行。C++的new操作符应该都知道，执行了两件事：

（1）分配内存

（2）调用构造函数

所以 p = new T这句包含了三个步骤：

（1）分配内存

（2）在内存的位置调用构造函数

（3）将内存的地址赋值给p

在这三步中，（2）和（3）的顺序是可以颠倒的，也就是说，完全可能出现这样的情况：p的值已经不是null，但对象的没有构造完毕，这个时候如果出现另一个线程也调用GetInstance，此时第一个if的判断 p == NULL则为false，所以这个调用会直接返回尚未构造结束的对象的地址p给客户使用。这个时候程序崩不崩就看程序怎么设计了。

所以阻止CPU换序是必须的，但现在不存在这种可移植的阻止换序的方法。通常情况下是调用cpu提供的一条指令，这条指令通常被称为barrier()，一条barrier指令会阻止cpu将该指令的指令交换到barrier之后，反之亦然，换句话说，barrier指令的作用就像一个拦水坝，阻止换序穿过这坝。许多体系结构的CPU都提供barrier指令，不过名称各不相同，例如POWERPC提供的一条指令就叫lwsync，可以如下保证线程安全：

#define barrier（） _asm_ volatile ("lwsync")
volatile T* p = 0;
T* GetInstance()
{
    if(p == NULL)
    {
        lock();
        if(p == NULL)
        {
            T* temp = new T;
            barrier();
            p = temp;
        }
        unlock();
    }
    return p;
}

这样，一定是对象的构造在barrier执行之前。

十、多线程的内部情况

1、三种线程模型

线程的并发执行是由多处理器或操作系统调度来实现，但实际上要更为复杂：大多数操作系统，包括windows和linux，都在内核里提供线程的支持，内核线程（这里的内核线程和Linux内核里的kernel_thread不是一回事）和之前讨论的一样，由多处理器或系统调度实现。然而用户实际上使用的线程并不是内核线程，而是存在于用户态的用户线程。用户态线程并不一定在操作系统内核里对应同等数量的内核线程，例如某些轻量级的线程库，对用户来说如果有三个线程在同时执行，对内核来说很可能只有一个线程。这里主要介绍用户态多线程库的实现。

（1）一对一模型

对于直接支持线程的系统，一对一模型始终是最简单的模型，对于一对一模型来说，一个用户使用的线程就唯一对应一个内核使用的线程（反过来就不一定，一个内核里的线程在用户态不一定有对应的线程存在），如图：

                                         

这样用户线程就具有了和内核线程一致的有点，线程之间的并发时真正的并发，一个线程因为某些原因阻塞，其它线程的执行不会受到影响。

一般直接使用API或者系统调用创建的线程均为一对一，例如在Linux中使用clone（带有CLONE_VM参数）产生的线程就是一对一:

int thread_function(void*)
{
    ...
}
char thread_stack[4096];

void foo()
{
    clone(thread_function, thread_stack, CLONE_VM, 0);
}

在windows里，使用API createThread也可创建一个一对一线程。

一对一线程有两个缺点：

（1）由于许多操作系统限制了内核线程的数量，因此一对一线程会让用户线程的数量受到限制。

（2）许多操作系统内核线程调度时，上下文切换的开销较大，导致用户线程的执行效率变低。

（2）多对一模型

将多个用户线程映射到一个内核线程上，线程之间的切换由用户态的代码进行，所以相对于一对一模型，多对一的线程切换要快许多。如图：

                                               

多对一模型的问题就是如果一个用户线程阻塞，那么所有线程的将无法执行，因为内核里的线程也随之阻塞了，另外，在多处理器系统上，处理器的增多对多对一模型的线程性能也不会有明显的的帮助。但是多对一模型的好处就是上下文切换变的高效和ji胡无限制的线程数量。

（3）多对多模型

多对多模型结合了一对一、多对一的特点，将多个用户线程映射到少数但不止一个内核线程上。

在多对多模型中，一个用户线程阻塞并不会影响所有的用户线程阻塞，因为阻塞一个，还有别的内核线程来调度执行，另外多对多模型对用户线程的数量没有什么限制，在多处理器系统上，多对多模型的线程的性能也能得到提升，不过提升幅度不如一对一高。