- A+
背景
当我们编写double check 单例的时候，如果使用pmd等静态代码检测工具检测的时候，会报线程不安全的错误。
比如我们定义一个单例类：
public final class SingleTest { private static SingleTest sSingleTest; private SingleTest() { } public static SingleTest getInstance() { if (sSingleTest == null) { synchronized (SingleTest.class) { if (sSingleTest == null) { sSingleTest = new SingleTest(); } } } return sSingleTest; } } 执行pmd任务（如何执行pmd任务大家自行Google，网上一大堆），输出报告如下所示：
<?xml version="1.0" encoding="UTF-8"?> <pmd xmlns="http://pmd.sourceforge.net/report/2.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://pmd.sourceforge.net/report/2.0.0 http://pmd.sourceforge.net/report_2_0_0.xsd" version="6.8.0" timestamp="2021-08-21T17:37:47.921"> <file name="/Users/liuwei/AndroidStudioProjects/MyTestApplication/app/src/main/java/com/pplovely/mytestapplication/SingleTest.java"> <violation beginline="13" endline="19" begincolumn="9" endcolumn="9" rule="NonThreadSafeSingleton" ruleset="Multithreading" package="com.pplovely.mytestapplication" class="SingleTest" method="getInstance" externalInfoUrl="https://pmd.github.io/pmd-6.8.0/pmd_rules_java_multithreading.html#nonthreadsafesingleton" priority="3"> Singleton is not thread safe </violation> </file> </pmd> 这里很明显提示 “Singleton is not thread safe”。
这是什么原因呢？明明都是通过同步锁来操作了，还不能保证线程安全吗？
通过这篇文章来简要的说明线程安全相关的概念。
线程基础
线程（Thread），是程序执行流的最小单元。一个标准的线程由线程ID、当前指令指针、寄存器集合和堆栈组成。通常意义上，一个进程由一个到多个线程组成，各个线程之间共享程序的内存空间（包括代码段、数据段、堆等）及一些进程级的资源（如打开文件和信号）。
一般进程和线程的关系图如下：
多个线程可以互不干扰的并发执行，并共享进程的全局变量和堆的数据。那么多个线程与单线程的进程相比，有哪些优势呢？通常来说，使用多线程的原因有如下几点：
- 某个操作会消耗大量的时间（通常都是计算），如果只有一个线程，程序和用户之间的交互就会中断。多线程可以让一个线程负责交互，另一个线程负责计算。
- 程序逻辑本身就要求并发操作。比如商店的多端下载功能
- 多CPU和多核设备本身就支持同时执行多个线程的能力，因此单线程程序无法全面发挥计算机的全部计算能力
- 相对多进程应用，多线程在数据共享方面效率要高很多
线程的访问权限
线程也拥有属于自己的私有存储空间，包括：
- 栈
- 线程局部存储（Thread Local Storage，TLS）。线程局部存储是某些操作系统为线程单独提供的私有空间，但通常只是具有很有限的容量
- 寄存器，寄存器是执行流的基本数据，因此为线程私有
从C程序员的角度来看，数据在线程之间是否私有如下表格所示：
| 线程私有 | 线程之间共享（进程所有） |
|---|---|
| 局部变量 | 全局变量 |
| 函数的参数 | 堆上的数据 |
| TLS数据 | 函数里的静态变量 |
| 程序代码，任何线程都有权利读取并执行任何代码 | |
| 打开的文件，A线程打开的文件可以由B线程读写 |
线程的调度与优先级
当线程的数量小于等于处理器数量（包括多核处理器），线程的并发是真正的并发，不同的线程运行在不同的处理器上，彼此之间互不干扰。但是对于线程数量大于处理器器数量的情况，线程的并发就会受到一些阻碍，因此此时至少有一个处理器会运行多个线程。
在单处理器（假设单核）对应多线程的情况下，并发是一种模拟出来的状态。操作系统会让这些多线程程序轮流执行，每次执行一小段时间（通常是几十到几百毫秒），这样每个线程就“看起来”在同时执行。这样的一个不断在处理器上切换不同的线程的行为称之为线程调度（Thread Schedule）。
在线程调度中，线程通常拥有至少三种状态，分别是：
- 运行（Running）：此时线程正在执行
- 就绪（Ready）：此时线程可以立刻运行，但CPU已经被占用。
- 等待（Waiting）：此时线程正在等待某一事件（通常是I/O或同步）发生，无法执行
处于运行中线程拥有一段可以执行的时间，这段时间称为时间片（Time Slice），当时间片用尽的时候，该进程将进入就绪状态。如果在时间片用尽之前进程就在开始等待某事件，那么它将进入等待状态。每当一个线程离开运行状态时，调度系统就会选择一个其他的就绪线程继续执行。在一个处于等待状态的线程所等待的事件发生之后，该线程将进入就绪状态。这3个状态的转移如下图所示：
线程调度自多任务操作系统问世以来就不断地被提出不同的方案和算法。线在主流的调度方式尽管各不相同，但都带有优先级调度（Priority Schedule） 和 轮转法（Round Robin）的痕迹。所谓轮转法，就是上面提到的让各个线程轮流执行一小段时间的方法。这决定了线程之间交错执行的特点。而优先级调度则决定了线程按照什么顺序轮流执行。在具有优先级调度的系统中，线程都拥有各自的线程优先级（Thread Priority）。具有高优先级的线程会更早的执行，而低优先级的线程常常要等待到系统中已经没有高优先级的可执行线程存在时才能够执行。
线程的优先级不仅可以由用户手动设置，系统还会根据不同线程的表现自动调整优先级，以使得调度更有效率。例如通常情况下，频繁进入等待状态（进入等待状态，会放弃之后仍然可占用的时间份额）的线程（比如处理I/O的线程）比频繁进行大量计算，以至于每次都要把时间片全部用尽的线程要受欢迎的多。道理很好理解，频繁等待的线程通常只占用很少的时间，我们一般把频繁等待的线程称之为IO密集型线程（IO Bound Thread）， 而把很少等待的线程称之为CPU密集型线程（CPU Bound Thread）。IO密集型线程总是比CPU密集型线程容易得到优先级的提升。
在优先级调度下，存在一种饿死（Starvation）的现象。一个线程饿死，是指其优先级较低，在它执行之前，总是有较高优先级的线程执行，从而导致该线程一直没有机会被执行。当一个CPU密集型线程优先级较高时，其他低优先级的线程就可能被饿死。 而一个高优先级的IO密集型线程由于大部分时间都在等待状态，因此不容易造成其他线程饿死。 为了避免饿死现象，调度系统常常会逐步提升那些等了过长时间的得不到执行的线程的优先级。 在这样的手段下，一个线程只要等待足够长的时间，其优先级一定会提高到足够让它执行的程度。
在优先级调度的环境下，线程的优先级改变一般有三种方式：
- 用户指定优先级
- 根据进入等待状态的频繁程度提升或降低优先级
- 长时间得不到执行而被提升优先级
Linux的多线程
Windows内核有明确的线程和进程的概念，并且提供了明确的API：CreateProcess 和 CreateThread 来创建进程和线程，并且有一系列的API来操作它们。但是对于Linux来说，线程并不是一个通用的概念。
事实上，在Linux内核中并不存在真正意义上的线程概念。Linux将所有的执行实体（不管时线程还是进程）都称为任务（Task）， 每个任务概念上都类似于一个单线程的进程，具有内存空间、执行实体、文件资源等。不过，Linux下不同的任务之间可以选择共享内存空间，因而在实际意义上，共享了同一个内存空间的多个任务构成了一个进程，这些任务就成了这个进程里的线程，在Linux下，用以下方法可以创建一个新的任务：
| 系统调用 | 作用 |
|---|---|
| fork | 复制当前进程 |
| exec | 使用新的可执行映像覆盖当前可执行映像 |
| clone | 创建子进程并从指定位置开始执行 |
fork函数产生一个和当前进程完全一样的新进程，并和当前进程一样从fork函数里返回。例如：
pid_t pid; if (pid = fork()) { …… } 在fork函数调用之后，新的任务将启动并和本任务一起从fork函数返回。但是不同的是本任务的fork将返回新的pid，而新任务的fork将返回0.
fork产生新任务的速度非常快，因为fork并不复制原任务的内存空间，而是和原任务一起共享一个写时复制（Copy on Write， COW） 的内存空间。所谓写时复制，指的是两个任务可以同时自由的读取内存，但任意一个任务试图对内存进行修改时，内存就会复制一份提供给修改方单独使用，以免影响到其他的任务使用。
fork只能产生本任务的镜像，因此须要使用exec配合才能够启动别的新任务。exec可以用新的可执行映像替换当前的可执行映像，因此在fork产生了一个新的任务之后，新任务则可以调用exec来执行新的可执行文件。fork 和 exec 产生一个新任务，而如果要产生新线程，则可以使用clone。
使用clone 可以产生一个新任务，从指定位置开始执行，并且（可选的）共享当前进程的内存空间和文件等。如此就可以在实际效果上产生一个线程。
线程安全
多线程程序处于一个多变的环境中，可访问的全局和堆数据随时可能被其他的线程改变。因此多线程程序在并发时数据的一致性变得非常重要。
竞争与原子操作
多个线程同时访问一个共享数据，可能造成严重的后果。先看下面的例子，假设有2个线程要分别执行如下代码：
线程1
i = 1; ++i; ** 线程2**
--i 在很多体系结构上，++i 的实现方法会如下：
- 读取 i 到某个寄存器X
- X++
- 将X的内容存储回i
由于线程1 和 线程2 是并发执行的，因此两个线程的执行序列可能如下（注意，寄存器X 的内容在不同的线程中是不一样的，这里用X1,X2 分别表示线程1 和 线程2 中的X）
| 执行序号 | 执行指令 | 语句执行后的变量值 | 线程 |
|---|---|---|---|
| 1 | i = 1 | i=1,X1=未知 | 1 |
| 2 | X1 = i | i=1,X1=1 | 1 |
| 3 | X2 = i | i=1,X2=1 | 2 |
| 4 | X1++ | i=1,X1=2 | 1 |
| 5 | X2-- | i=1,X2=0 | 2 |
| 6 | i = X1 | i=2,X1=2 | 1 |
| 7 | i = X2 | i=0,X2=0 | 2 |
从程序逻辑看，两个线程执行完成之后，i的值应该是1， 但从之前的执行序列可以看到，i 的值为0。 实际上这两个线程如果同时执行的话，i 的结果可能是0或1或者2. 可见，两个程序同时读写同一个共享数据回导致意想不到的后果。
很明显，自增（++）操作在多线程环境下会出现错误是因为这个操作被编译为汇编代码之后不止一条指令，因此在执行的时候可能执行了一半就被调度系统打断，去执行别的代码。 我们把单指令的操作称为原子的（Atomic），因为无论如何，单条指令的执行是不会被打断的。
在复杂的场合下，比如我们要保证一个复杂的数据结构更改的原子性，这里我们就要用到：锁
同步与锁
为了避免多个线程同时读取同一个数据而产生不可预料的后果，我们将各个线程对同一数据的访问同步（Syncchronization）
。所谓同步，即指一个线程访问数据未结束时，其他线程不得对同一个数据进行访问。如此，对数据的访问被原子化了。
同步最常见的方法是使用锁（Lock）。 锁事一种非强制机制，每一个线程在访问数据或资源之前首先试图获取（Acquire） 锁，并在访问结束之后释放（Release）锁。 在锁已经被占用的时候试图获取锁时，线程会等待，直到锁重新可用。
二元信号量（Binary Semaphore） 时最简单的一种锁，它只有2种状态：占用和非占用。它适合只能被唯一一个线程独占访问的资源。当二元信号量处于非占用状态时，第一个试图获取该二元信号量的线程会获得该锁，并将二元信号量设为占用状态，此后其他所有试图获取该二元信号量的线程将会等待，知道该锁被释放。
对于允许多个线程并发访问的资源，多元信号量简称信号量（Semaphore）， 它是一个很好的选择，一个初始值为N 的信号量允许N 个线程并发访问。
线程访问资源的时候首先获取信号量，进行如下操作：
- 将信号量的值减 1.
- 如果信号量的值小于0，则进入等待状态，否则继续执行
访问完资源后，线程释放信号量，进行如下操作：
- 将信号量+1.
- 如果信号量的值小于1，唤醒一个等待中的线程。
互斥量（Mutex） 和二元信号量很类似， 资源仅同时允许一个线程访问，但和信号量不同的是：信号量在整个系统可以被任意线程获取并释放，也就是说，同一个信号量可以被系统中的一个线程获取之后由另一个线程释放。而互斥量则要求哪个线程获取了互斥量，哪个线程就要负责释放这个锁，其他线程去释放互斥量是无效的。
临界区（Critical Section） 是比互斥量更加严格的同步手段。在术语中，把临界区的锁的获取称为进入临界区，而把锁的释放称为离开临界区。临界区和互斥量与信号量的区别在于：前者的作用范围仅限于本进程，其他进程是无法访问的，二互斥量和信号量是多进程可以访问的，比如一个进程创建了某个互斥量，另一个进程试图去获取该锁是合法的。
读写锁（Read Write Lock），更多应用于IO操作。同时允许多个线程读取是没问题的，但是涉及到写入的时候必须是同步的。读写锁有2种获取方式：共享的（Shared）或 独占的（Exclusive）。
读写锁状态与获取方式之间的关系如下表所示：
| 读写锁状态 | 以共享方式获取 | 以独占方式获取 |
|---|---|---|
| 自由 | 成功 | 成功 |
| 共享 | 成功 | 等待 |
| 独占 | 等待 | 等待 |
条件变量（Condition Variable） 作为一种同步手段，作用类似于栅栏。对于条件变量，线程可以有2种操作，首先线程可以等待条件变量，一个条件变量可以被多个线程等待。其次，线程可以唤醒条件变量，此时某个或所有等待次条件变量的线程都会被唤醒并继续支持。 也就是说，使用条件变量可以让许多线程一起等待某个事件的发生，当事件发生时（条件变量被唤醒），所有的线程可以一起恢复执行。
可重入（Reentrant）与线程安全
一个函数被重入，表示这个函数并没有执行完，由于外部因素或内部调用，又一次进入该函数执行。一个函数要被重入，只有两种情况：
- 多个线程同时执行这个函数
- 函数自身调用自身（可能是经过多层调用之后）
一个函数被称为可重入的，表明该函数被重入之后不会产生任何不良后果。举个例子，如下面的这个sqr函数就是可重入的：
int sqr(int x) { return x * x; } 一个函数要成为可重入的，必须具有如下几个特点：
- 不使用任何（局部）静态变量或全局的非const 变量。
- 不返回任何（局部）静态或全局的非const 变量的指针。
- 仅依赖调用方提供的参数。
- 不依赖任何资格资源的锁（mutex等）
- 不调用任何不可重入的函数。
可重入是并发安全的强力保障，一个可重入的函数可以在多线程环境下放心使用。
过度优化
线程安全是一个非常烫手的山芋，因为即使合理的使用了锁，也不一定能保证线程的安全，这是源于落后的编译器技术已经无法满足日益增长的并发需求。很多看似无错的代码在优化和并发面前又产生了麻烦。举个简单的例子
X = 0; Thread1 Thread2 lock(); lock(); x++; x++; unlock(); unlock(); 由于有lock和unlock保护，x++的行为并不会被并发所破坏，那么x的值似乎必然时2了。然而，如果编译器为了提高x的访问速度，把x放到某个寄存器里，那么我们知道不同线程的寄存器时各自独立的，因此如果Thread1 先获得锁，则程序的执行可能会呈现如下的情况：
- 【Thread1】读取x 的值到某个寄存器R[1] （R[1] = 0）
- 【Thread1】R[1]++ (由于之后可能还要访问x，因此Thread1 暂时不将R[1] 写回x)
- 【Thread2】读取x 的值到某个寄存器R[2] (R[2] = 0)
- 【Thread2】R[2]++ (R[2] = 1)
- 【Thread2】将R[2] 写回x (x =1)
- 【Thread1】(很久以后) 将R[1] 写回至x （x=1）
可见在这样的情况下即使正确的加锁，也不能保证多线程安全。下面是另一个例子：
x = y = 0; Thread1 Thread2 x=1 y=1; r1=y r2=x 正常情况下，r1和r2 至少有一个为1，逻辑上不可能同时为0.然而，事实上r1=r2=0 的情况确实可能发生。 原因在于早几十数年前，CPU 就发展出了动态调度，在执行程序的时候为了提高效率有可能**交换指令的顺序**。 同样，编译器在进行优化的时候，也可能为了效率而**交换毫不相干的两条相邻指令**（如x=1 和 r1=y）的执行顺序，也就是说，以上代码执行的时候可能是这样的： x = y = 0; Thread1 Thread2 r1=y; y=1; x=1; r2=x 那么r1=r2=0 就完全可能了。 我们可以使用volatile 关键字试图阻止过度优化，volatile 基本可以做到两件事：
- 阻止编译器为了提高速度将一个变量缓存到寄存器内而不写回
- 阻止编译器调整操作 volatile 变量的指令顺序
可见volatile 可以完美的解决第一个问题，但是 valatile 是否也可以解决第二个问题呢？ 答案是不能。因为即使volatile 能够阻止编译器调整顺序，也无法阻止CPU 动态调度换序。
现在我们再来看下开篇的时候提到的单例double check问题。
volatile T* pInstance = 0; T* getInstance() { if (pInstance == NULL) { lock(); if (pInstance == NULL) { pInstance = new T; } unlock(); } } 抛开逻辑，这样的代码咋看是没问题的。当函数返回时，pInstance 总是指向一个有效的对象。而lock 和 unlock 防止了多线程竞争导致的麻烦。 双重的if 在这里可以让lock的调用开销降低到最小。
但是实际上这样的代码是有问题的。问题的来源仍然是CPU 的乱序执行。new 一个对象其实包含了2个步骤：
- 分配内存
- 调用构造函数
所以 pInstance = new T 包含了3个步骤
- 分配内存。
- 在内存的位置上调用构造函数。
- 将内存地址赋值给pInstance。
在这3步中，2和3 的顺序是可以颠倒的。也就是说，完全有可能出现这样的情况：pInstance 的值已经不是NULL，但是对象仍然没有构造完毕。这时候如果出现一个对getInstance的并发调用，第一个if条件已经不满足了，所以会返回一个没有初始化的对象。程序运行会不会崩溃就取决于代码实现了。
从上面两个例子可以看出 CPU 的乱序执行能力让我们对多线程的安全保障的努力变得异常困难，因此要保证线程安全，阻止CPU 换序是必须的。 一般就是调用CPU 提供的一条指令，被称为barrier指令。一条barrier指令会阻止CPU 将该指令之前的指令交换到barrier之后。 这里跟Android绘制的时候给主线程Handler设置的栅栏指令是一个意思。
当然，在java中，我们可以通过静态内部类的方式构建一个单例，这样效率是最高的，并且是线程安全的，这里就不列出代码了。
三种线程模型
一对一模型
对于直接支持线程的系统，一对一模型始终是最为简单的模型。一个用户使用的线程就为宜对应一个内核使用的线程（但是反过来不一定，一个内核里的线程在用户态不一定有对应的线程存在）如下图所示：
这样用户线程就具有了和内核线程一致的优化，线程之间的并发是真正的并发。一个线程因其他原因阻塞时，其他线程执行不会受影响。1对1模型在多处理器上有更好的性能表现。一半直接使用内核API或系统调用创建的线程均为1对1模型。
一对一模型有两个缺点：
- 由于许多操作系统限制了内核线程的数量，因此一对一线程会让用户的线程数量受到限制
- 许多操作系统内核线程调度时，上下文切换的开销较大，导致用户线程的执行效率下降
多对一模型
多对一模型将多个用户线程映射到一个内核线程上，线程之间的切换由用户态的代码来进行，因此相对一对一模型，该模型下线程切换速度要快的多， 具体如下图所示：
多对一模型最大的问题就是：其中一个用户线程阻塞，那么所有的线程都将无法执行，因为此时内核里的线程也随之阻塞了。
多对一模型最大的优势就是：高效的上下文切换和几乎无限制的线程数量
多对多模型
多对多模型结合了多对一和一对一模型的特点，将多个用户线程映射到少数但不知一个内核线程上，如下图所示：
在多对多模型中，一个用户线程阻塞并不会使得所有的用户线程阻塞，因为此时还有别的线程可以被调度来执行。另外，多对多模型对用户线程的数量也没什么限制。
本文由博客一文多发平台 OpenWrite 发布！
