并发理论

可见性、原子性和有序性问题

这些年，CPU、内存、I/O设备的不断迭代，不断朝着更快的方向努力。但是，在这个快速发展的过程中，有一个核心核心矛盾一直存在，就是这三者的速度差异。

程序里大部分语句都要访问内存，有些还要访问I/O设备，根据木桶理论，程序整体的性能取决于最慢的操作---读写I/O设备，也就是说单方面提高CPU性能是无效的。

为了合理利用CPU的高性能，平衡这三者的速度差异，计算机体系结构、操作系统、编译程序都做出了贡献，主要体现为：

CPU增加了缓存，以均衡与内存的速度差异；
操作系统增加了进程、线程，以分时复用CPU，进而均衡CPU与I/O设备的速度差异；
编译程序优化指令执行次序，使得缓存能够得到更加合理的利用。

但是并发程序的根源也在这里：

源头之一：缓存导致可见性问题

在单核时代，所有的线程都在一颗CPU上执行，CPU缓存与内存的数据一致性容易解决。因为所有的线程都是操作同一个CPU缓存，一个线程对缓存的写，对另一个线程来说一定是可见的。例如下面的图中，线程A和线程B都是操作同一个CPU里面的缓存，所以线程A更新了变量V，那么线程B之后再访问变量V，得到的一定是V的最新值。

CPU缓存与内存的关系图

一个线程对共享变量的修改，另外一个线程能够立即看到，我们称之为可见性。

多核时代，每颗CPU都有自己的缓存，这时CPU缓存与内存的数据一致性就没那么容易解决了，当多个线程再不同的CPU上执行，这些线程操作的是不同的CPU缓存。比如，下图中，线程A操作的是CPU-1上的缓存，而线程B操作的是CPU-2上的缓存，很明显，这个时候线程A对变量V的操作对于线程B而言就不具备可见性了。这个就属于硬件给软件挖的”坑“。

多核CPU的缓存与内存的关系图

下面我们再用一段代码来验证一下多核场景下的可见性问题。下面的代码，每执行一次add10K()方法，都会循环10000次count += 1操作。在calc()方法中我们创建了两个线程，每个线程调用一次add10K()方法，我们来想一想执行calc()方法得到的结果应该是多少？

public class Test{
    private long count = 0;
    private void add10K(){
        int idx = 0;
        while(idx++ < 10000){
            count += 1;
        }
    }
    public static long calc(){
        final Test test = new Test();
        // 创建两个线程，执行add操作
        Thread th1 = new Thread(() -> {
            test.add10K();
        });
         Thread th2 = new Thread(() -> {
            test.add10K();
        });
        // 启动两个线程
        th1.start();
        th2.start();
        // 等待两个线程执行结束
        th1.join();
        th2.join();
        return count;
    }
}

直觉告诉我们应该是20000，因为在单线程里调用两次add10K()方法，count的值就是20000，但实际上calc()的执行结果是个10000到20000之间的随机数。为什么呢？

我们假设线程A和线程B同时开始执行，那么第一次都会将count = 0读到各自的CPU缓存里，执行完count += 1之后，各自CPU缓存里的值都是1，同时写入内存后，我们会发现内存中是1，而不是我们期望的2。之后由于各自的CPU缓存里都有了count的值，两个线程都是基于CPU缓存里的count值来计算，所以导致最终count的值都是小于20000的，这就是缓存可见性问题。

循环10000次count += 1操作如果改为循环1亿次，最终count的值接近1亿，而不是2亿。如果循环10000次，count的值接近20000，原因是两个线程不是同时启动的，有一个时差。

变量count在CPU缓存和内存的分布图

源头二：线程切换带来的原子性问题：

由于IO太慢，早起的操作系统就发明了多进程，即便在单核CPU上我们也可以以便听着歌，一边写Bug，这就是多进程的功劳。

操作系统允许某个进程进行一小段时间，例如50毫秒，过了50毫秒操作系统就会重新选择一个进程来执行（任务切换），这50毫秒称为”时间片“。

线程切换示意图

在一个时间片内，如果一个进程进行了一个IO操作，例如读个文件，这个时候进程可以把自己标记为”休眠状态“。并让出CPU的使用权，待文件读进内存，操作系统会把这个休眠的进程唤醒，唤醒后的进程就有机会重新获得CPU的使用权了。

这里的进程在等待IO时之所以会释放CPU使用权，是为了让CPU在这段等待时间可以做别的事情，这样一来CPU的使用率就上来了；此外，如果这时有另外一个进程也读文件，读文件的操作就会排队，磁盘驱动在完成一个进程的读操作后，发现有排队的任务，就会立即启动下一个读操作，这样IO的使用率也上来了。

早期的操作系统基于进程来调度CPU，不同进程间是不共享内存空间的，所以进程要做任务切换就要切换内存映射地址，而一个进程创建的所有线程，都是共享一个内存空间的，所以线程做任务切换成本就很低了。现代的操作系统都基于更轻量的线程来调度，现在我们提到的”任务切换“都是指”线程切换“。

Java并发程序都是基于多线程的，自然也会涉及到任务切换。任务切换的时机大多数是在时间片结束的时候，我们现在基本都使用高级语言编程，高级语言里一条语句往往需要多条CPU指令完成，例如上面代码的count += 1，至少需要三条CPU指令。

指令1：首先，需要把变量count从内存加载到CPU的寄存器
指令2：之后，在寄存器中执行+1操作
指令3：最后，将结果写入内存（缓存机制导致可能写入的是CPU缓存而不是内存）

操作系统做任务切换，可以发送在任何一条CPU指令执行完，是的，是CPU指令，而不是高级语言里的一条语句。对于上面的三条指令来说，我们假设count = 0，如果线程A在指令1执行完后做线程切换，线程A和线程B按照下图的序列执行，那么我们会发现两个线程都执行了count += 1的操作，但是得到的结果不是我们期望的2，而是1。

非原子操作的执行路径示意图

我们潜意识里面觉得count += 1这个操作是一个不可分割的整体，就像一个原子一样，线程的切换可以发生在count += 1之前，也可以发生在count += 1之后，但就是不会发生在中间。我们把一个或多个操作在CPU执行过程中不被中断的特性称为原子性。CPU能保证的原子操作是CPU指令级别的，而不是高级语言的操作符，这违背了我们的直觉，因此，很多时候我们需要在高级语言层面保证操作的原子性。

源头三：编译优化带来的有序性问题

有序性指的是程序按照代码的先后顺序执行。编译器为了优化性能，有时候会改变程序中语句的先后顺序，例如程序中：a = 6；b = 7；编译器优化后可能变成：b = 7；a = 6；在这个例子中，编译器调整了语句的顺序，但是不影响程序的最终结果。不过有时候编译器及解释器的优化可能导致意想不到的Bug。

在Java 领域一个经典的案例就是利用双重检查创建单例对象，例如下面的代码：在获取实例getInstance()的方法中，我们首先判断instance是否为空，如果为空，则锁定Singleton.class并再次检查instance是否为空，如果还为空则创建Singleton的一个实例。

public class Singleton{
    static Singleton instance;
    static Singleton getInstance(){
        if (instance == null){
            synchronized(Singleton.class){
                if (instance == null){
                    instance = new Singleton();
                }
            }
            return instance;
        }
    }
}

假设有两个线程A、B同时调用getInstance()方法，它们会发现instance == null，于是同时对Singleton.class加锁，此时JVM只有一个线程能够加锁成功（假设是线程A），另外一个线程则会处于等待状态（假设线程B）；此时线程A会创建一个Singleton实例，之后释放锁，锁释放后，线程B被唤醒，线程B再次尝试加锁，此时是可以加锁成功的，加锁成功之后，线程B检查instance == null时发现，已经创建过Singleton实例了，所限线程B不会再创建一个Singleton实例。

这看上去一切完美，无懈可击，但实际上这个getInstance()方法并不完美。问题出在哪里呢？出在new操作上，我们意味new的操作应该是：

分配一块内存M；
在内存M上初始化Singleton对象；
然后M的地址赋值给instance变量。

但是实际上优化后的执行路径却是这样的：

分配一块内存M；
将M的地址赋值给instance变量；
最后在内存M上初始化Singleton对象。

优化后会导致什么问题？我们假设线程A先执行getInstance()方法，当执行完指令2时恰好发生了线程切换，切换到了线程B上，如果此时线程B也执行getInstance()方法，那么线程B在执行第一个判断时会发现instance != null，所以直接返回instance，而此时的instance是没有初始化过的，如果我们这个时候访问instance的成员变量就可能触发空指针异常。

双重检查创建单例的异常执行路径

Java内存模型

导致可见性的原因是缓存，导致有序性的原因是编译优化，那解决可见性、有序性最直接的办法就是禁用缓存和编译优化，但是这样问题虽然解决了，但是性能可就堪忧了。

合理的方案应该是按需禁用缓存以及编译优化。

Java内存模型是个很复杂的规范，可以从不同的视角来解读。具体来说，这些方法包括volatile、synchronized和final三个关键字，以及六项Happens-Before规则。

使用volatile的困惑：

volatile关键字并不是java语言的特产，古老的C语言里也有，它最原始的意义就是禁用CPU缓存。

例如，我们声明一个volatile int x = 0；它表大的是：告诉编译器，对这个变量的读写，不能使用CPU缓存，必须从内存中读取或写入。这个语义看上去相当明确，但是在实际上使用的时候却会带来困惑。

例如下面实例代码，假设线程A执行writer()方法，按照volatile语义，会把变量v = true写入内存；假设线程B执行reader()方法，同样按照volatile语义，线程B会从内存读取变量v，如果线程B看到v = true时，那么线程B看到的变量x是多少呢？

直觉上看，应该是42，那实际应该是多少呢？这个要看java的版本，如果在低于1.5版本上运行，x可能是42，也有可能是0；如果在1.5以上的版本上运行，x就是等于42。

class VolatileExample{
    int x = 0;
    volatile boolean v = false;
    public void writer(){
        x = 42;
        v = true;
    }
    public void reader(){
        if (v == true){
            // 这里 x 会是多少呢？
        }
    }
}

分析一下，为什么1.5以前的版本会出现x = 0的情况呢？变量x可能被CPU缓存而导致可见性问题。这个问题在1.5版本已经被圆满解决了。java内存模型在1.5版本对volatile语义进行了增强。怎么增强的呢？答案是一项Happens-Before规则。

Happens-Before规则：

它真正要表达的是：前面一个操作的结果对后续操作是可见的。

1.程序的顺序性规则

这条规则是指在一个线程中，按照程序顺序，前面的操作Happens-Before于后续的任意操作。比如刚才那段示例代码，按照程序的顺序，第6行代码x = 42；Happens-Before于第7行代码v = true；这就是规则1的内容，程序前面对某个变量的修改一定是对后续操作可见的。

2.volatile变量规则

这条规则是指对一个volatile变量的写操作，Happens-Before于后续对这个volatile变量的读操作。

这个就有点费解了，对一个volatile变量的写操作相对于后续对这个volatile变量的读操作可见，这怎么看都是禁用缓存的意思，貌似和1.5版本以前的语义没有变化啊？如果单看这个规则，的确是这样，但是再看规则3就不一样了。

3.传递性

这条规则是指如果A Happens-Before B，且B Happens-Before C，那么A Happens-Before C。

我们将规则3的传递性应用到我们的例子中，会发生什么？

示例代码中的传递性规则

从图中，我们可以看到：

x = 42 Happens-Before 写变量v = true，这是规则1的内容；
写变量v = true Happens-Before 读变量v true，这是规则2的内容。

再根据这个传递性规则，我们得到结果：x = 42 Happens-Before读变量v = true。这意味着什么？

如果线程B读到了v = true，那么线程A设置x = 42对线程B是可见的。也就是说，线程B能看到x = 42。这就是1.5版本对volatile语义的增强，这个增强意义重大，1.5版本的并发包（java.util.concurrent）就是靠volatile语义来搞定可见性的。

4.管程中锁的规则

这条规则是指对一个锁的解锁Happens-Before于后续对这个锁的加锁。

要理解这个规则，就首先要了解”管程指的是什么“。管程是一种通用的同步原语，在java中指的就是synchronized，synchronized是java里对管程的实现。

管程中的锁在java里是隐式实现的，例如下面的代码，在进入同步快之前，会自动加锁、而在代码块执行完会自动释放锁，加锁以及释放锁都是编译器帮我们实现的。

synchronized(this){ // 此处自动加锁
    // x是共享变量，初始值是10
    if (this.x < 12){
        this.x = 12;
    }
} // 此处自动解锁

所以结合规则4---管程中锁的规则，可以这样理解：假设x的初始值是10，线程A执行完代码块后x的值会变成12（执行完自动释放锁），线程B进入代码块时，能够看到线程A对x的写操作，也就时线程B能够看到x = 12。

5.线程start()规则

这条是关于线程启动的。它是指主线程A启动子线程B后，子线程B能够看到主线程在启动子线程B前的操作。

换句话说，如果线程A调用线程B的start()方法（即在线程A中启动线程B），那么该start()操作Happens-Before于线程B中的操作。具体可参考下面示例代码。

Thread B = new Thread(() -> {
    // 主线程调用B.start（）之前
    // 所有对共享变量的修改，此处皆可见
    // 此例中，var = 77
});
// 此处对共享变量var修改
var = 77;
// 主线程启动子线程
B.start();

6.线程join()规则

这条是关于线程等待的。它是指主线程A等待子线程B完成（主线程A通过调用子线程B的join()方法实现），当子线程B完成后（主线程A中join()方法返回），主线程能够看到子线程的操作。当然所谓的看到，指的是对共享变量的操作。

换句话说，如果在线程A中，调用线程B的join()并成功返回，那么线程B中的任意操作Happens-Before于该join()操作的返回，具体可参考下面示例代码。

Thread B = new Thread(()->{
  // 此处对共享变量 var 修改
  var = 66;
});
// 例如此处对共享变量修改，
// 则这个修改结果对线程 B 可见
// 主线程启动子线程
B.start();
B.join()
// 子线程所有对共享变量的修改
// 在主线程调用 B.join() 之后皆可见
// 此例中，var==66

被我们忽略的final

前面将volatile为的是禁用缓存以及编译优化，我们再从另外一个方面来看，有没有办法告诉编译器优化得更好一点呢？就是final关键字。

final修饰变量时，初衷是告诉编译器：这个变量生而不变，可以可劲儿优化。

在1.5以后java内存模型对final类型变量的重排进行了约束，现在只要我们提供正确构造函数没有”逸出“，就不会出问题了。

”逸出“有点抽象，在下面例子中，在构造函数里面将this赋值给了全局变量global.obj，这就是”逸出“，线程通过global.obj读取x是可能读到0的。因此我们一定要避免”逸出“。

// 以下代码来源于【参考 1】
final int x;
// 错误的构造函数
public FinalFieldExample() { 
  x = 3;
  y = 4;
  // 此处就是讲 this 逸出，
  global.obj = this;
}

互斥锁

原子性问题的源头是线程切换，如果能够禁用线程切换那不就能解决这个问题了吗？而操作系统做线程切换时依赖CPU中断的，所以禁止CPU发生中断就能够进制线程切换。

在早期单核CPU时代，这个方案的确是可行的，而且也有很多应用案例，但是并不适合多核场景。这里我们以32位CPU上执行long型变量的写操作为例来说明这个问题，long型变量是64位，在32位CPU上执行写操作会被拆分成两次写操作（写高32位和写低32位，如下如所示）。

在单核CPU场景下，同一时刻只有一个线程执行，禁止CPU中断，意味着操作系统不会重新调度线程，也就是禁止了线程切换，获得CPU使用权的线程就可以不间断地执行，所以两次写操作一定是：要么都被执行，要么都没有被执行，具有原子性。

但是在多核场景下，同一时刻，有可能有两个线程同时在执行，一个线程执行在CPU-1上，一个线程执行在CPU-2上，此时进制CPU中断，只能保证CPU上的线程连续执行，并不能保证同一时刻只有一个线程执行，如果这两个线程同时写long型变量高32位的话，那就有可能出现Bug。

同一时刻只有一个线程执行这个条件非常重要，我们称之为互斥。如果我们能够保证对共享变量的修改是互斥的，那么，无论是单核CPU还是多核CPU，就都能保证原子性了。

简易锁模型

当谈到互斥，解决方案：锁。

简易锁模型

我们把一段需要互斥执行的代码称为临界区。线程在进入临界区之前，首先尝试加锁lock()，如果成功，则进入临界区，此时我们成这个线程持有锁；否则就等待，直到持有锁的线程解锁；持有锁的线程执行完临界区的代码后，执行解锁unlock()。

这个过程非常想办公室高峰期抢占坑位，每个人都是进坑锁门（加锁），出坑开门（解锁），如厕这个事就是临界区。

改进后的锁模型

我们知道在现实世界里，锁和锁要保护的资源是有对应关系的，比如你用你家的锁保护你家的东西，我用我家的锁保护我家的东西。在并发编程世界里，锁和资源也应该有这个关系，但这个关系在我们上面模型中是没有体现的，所以我们需要完善一下我们的模型。

改进后的锁模型

首先，我们要把临界区要保护的资源标注出来，如图中临界区里增加了一个元素：受保护的资源R；其次，我们要保护资源R就得它创建一把锁LR；最后，针对这把锁LR，我们还需在进出临界区时添加加锁操作和解锁操作。

java语言提供的锁技术：synchronized

锁时一种通用的技术方案，java语言提供的synchronized关键字，就是锁的一种实现。synchronized关键字可以用来修饰方法，也可以用来修饰代码块，他的使用示例基本上都是下面这个样子：

class X{
    // 修饰非静态方法
    synchronized void foo(){
        // 临界区
    }
    // 修饰静态方法
    synchronized static void bar(){
        // 临界区
    }
    // 修饰代码块
    Object obj = new Object();
    void baz(){
        synchronized(obj){
            // 临界区
        }
    }
}

看完之后你可能会觉得有点奇怪，这个和我们上面提到的模型有点对不上号啊，加锁lock()和解锁unlock()在哪里呢？其实这两个操作都是有的，只是这两个操作是被java默默加上的，java编译器会在synchronized修饰的方法或代码块前后自动加上锁lock()和解锁unlock()，这样做的好初就是加锁和解锁一定是成对出现的，毕竟忘记解锁是个致命的bug（意味着其它线程只能死等下去）。

那synchronized里的加锁lock()和解锁unlock()锁定的对象在哪里呢？上面的代码我们看到只有修饰代码块的时候，锁定了一个obj对象，那修饰方法的时候锁定的是什么呢？这个也是java的一条隐式规则：

当修饰静态方法的时候，锁定的是当前类的Class对象，在上面的例子就是Class X；

当修饰非静态方法的时候，锁定的是当前实例对象this。

对应上面的例子，synchronized修饰静态方法相当于：

class X{
    // 修饰静态方法
    synchronized(X.class) static void bar(){
        // 临界区
    }
}

修饰非静态方法，相当于：

class X{
    // 修饰非静态方法
    synchronized(this) void foo(){
        // 临界区
    }
}

用synchronized解决count += 1问题

相信你一定记得前面提到的count += 1存在的并发问题，现在我们可以尝试用synchronized来小试牛刀一把。代码如下所示。SafeCalc这个类有两个方法：一个是get()方法，用来获取value的值；另一个是addOne()方法，用来给value加1，并且addOne()方法我们用synchronized修饰。那么我们使用的这两个方法有没有并发问题呢？

class SafeCalc{
    long value = 0;
    long get(){
        return value;
    }
    synchronized void addOne(){
        value += 1;
    }
}

我们先来看看addOne()方法，首先可以肯定，被synchronized修饰后，无论是单核CPU还是多核CPU，只有一个线程能够执行addOne()方法，所以一定能保证原子操作，那是否有可见性呢？要回答这个问题，就要回顾之前的管程中锁的规则。

管程中锁的规则：对一个锁的解锁Happens-Before于后续对这个锁的加锁。

管程，就是我们这里的synchronized，我们知道synchronized修饰的临界区是互斥的，也就是说同一时刻只有一个线程执行临界区的代码；而所谓”对一个锁解锁Happens-Before后续对这个锁的加锁“，指的是前一个线程的解锁操作对后一个线程的加锁操作可见，综合Happens-Before的传递性原则，我们就能得出前一个线程在临界区修改的共享变量（该操作在解锁之前），对后续进入临界区（该操作在加锁之后）的线程是可见的。

按照这个规则，如果多个线程同时执行addOne()方法，可见性是可以保证的，也就说如果有1000个线程执行addOne()方法，最终结果一定是value的值增加了1000。

但也许，一不小心就忽视了get()方法。执行addOne()方法后，value的值对get()方法是可见的吗？这个可见性是没法保证的。管程中锁的规则，是只保证后续对这个锁的加锁的可见性，而get()方法并没有加锁操作，所以可见性没发保证。那如何解决呢？很简单，就是get()方法synchronized一下，完整的代码如下所示。

class SafeCalc{
    long value = 0;
    synchronized long get(){
        return value;
    }
    synchronized void addOne(){
        value += 1;
    }
}

上面的代码转换为我们提到的锁模型，就是下面图示这个样子。get()方法和addOne()方法都需要访问value这个受保护的资源，这个资源用this这把锁来保护。线程要进入临界区get()和addOne()，必须先获得this这个锁，这样get()和addOne()也是互斥的。

保护临界区get()和addOne()的示意图

这个模型更像现实世界里面球赛门牌的管理，一个座位只允许一个人使用，这个座位就是“受保护资源”，球场的入口就是java类里的方法，而门牌就是用来保护资源的”锁“，java里的检票工作是由synchronized解决的。

锁和受保护资源的关系

我们前面提到，受保护资源和锁之间的关联关系非常重要，它们的关系是怎样的呢？一个合理的关系是：受保护资源和锁之间的关联关系是N:1的关系。还拿前面球赛门票的管理来类比，就是一个座位，我们只能用一张票来保护，如果多发了重复的票，那就要打架了。现实世界里，我们可以用多把锁来保护同一个资源，但是并发领域是不行的，并发领域的锁和现实世界的锁不是完全匹配的。不过倒是可以用同一把锁来保护多个资源，这个对应到现实世界就是我们所谓的”包场“了。

上面那个例子稍作改动，把value改成静态变量，把addOne()方法改成静态方法，此时get()方法和addOne()方法是否存在并发问题呢？

class SafeCalc {
  static long value = 0L;
  synchronized long get() {
    return value;
  }
  synchronized static void addOne() {
    value += 1;
  }
}

如果仔细观察，就会发现改动后的代码是用两个锁保护一个资源。这个受保护的资源就是静态变量value，两个锁分别是this和SafeCalc.class。我们可以用下面这副图来形象描述这个关系。由于临界区get()和addOne()使用两个锁保护的，因此这两个临界区没有互斥关系，临界区addOne()对value的修改对get()也没有可见性保证，这就导致了并发问题了。

两把锁保护一个资源的示意图

保护没有关联关系的多个资源

在现实世界里，球场的作为和电影院的作为就是没有关联关系的，这种场景非常容易解决，拿就是球赛有球赛的门票，电影院有电影院的门票，各自管理各自的。

同样这对应到编程领域，也很容易解决。例如，银行业务中有针对账户余额的取款操作，也有针对账户密码的更改操作，我们可以为账户余额和账户密码分配不同的锁来解决并发问题，这个还是很简单的。

相关的示例代码如下，账户类Acount有两个成员变量，分别是账户余额balance和账户密码password。取款withdraw()和查看余额getBalance()操作会访问账户余额balance，我们创建一个final对象balLock作为锁；而更改密码undatePassword()和查看密码getPassword()操作会修改账户密码password。我们创建一个final对象pwLock作为锁。不同的资源用不同的锁保护，各自管各自的，很简单。

class Account {
  // 锁：保护账户余额
  private final Object balLock = new Object();
  // 账户余额  
  private Integer balance;
  // 锁：保护账户密码
  private final Object pwLock = new Object();
  // 账户密码
  private String password;
 
  // 取款
  void withdraw(Integer amt) {
    synchronized(balLock) {
      if (this.balance > amt){
        this.balance -= amt;
      }
    }
  } 
  // 查看余额
  Integer getBalance() {
    synchronized(balLock) {
      return balance;
    }
  }
   // 更改密码
  void updatePassword(String pw){
    synchronized(pwLock) {
      this.password = pw;
    }
  } 
  // 查看密码
  String getPassword() {
    synchronized(pwLock) {
      return password;
    }
  }

当然，我们可以用一把互斥锁来保护多个资源，例如我们可以用this这一把锁来管理账户类里所有的资源；账户余额和用户密码。具体实现简单，示例程序中所有的方法都增加同步关键字synchronized就可以了。

但是用一把锁有个问题，就是性能太差，会导致取款、查看余额、修改密码、查看密码这四个操作都是串行的。而我们用两把锁，取款和修改密码是可以并行的。用不同的锁对受保护资源进行精细化管理，能够提升性能。这种锁叫细粒度锁。

保护有关联关系的多个资源

如果多个资源有关联关系的，那这个问题就有点复杂了。例如银行业务里面的转账操作，账户A减少100元，账户B增加100元。这两个账户就是有关联关系的。而对于像转账这种由关联关系的操作，我们应该怎么去解决呢？先把这个问题代码化。我们声明了个账户类：Account，该类有一个成员变量余额：balance，还有一个用于转账的方法：transfer()，然后怎么保证转账操作transfer()没有并发问题呢?

class Account {
  private int balance;
  // 转账
  void transfer(
      Account target, int amt){
    if (this.balance > amt) {
      this.balance -= amt;
      target.balance += amt;
    }
  } 
}

相信你的直觉会告诉你这样的解决方案：用户synchronized关键字修饰一下transfer()方法就可以了，于是你很快就完成了相关代码，如下所示。

class Account {
  private int balance;
  // 转账
  synchronized void transfer(
      Account target, int amt){
    if (this.balance > amt) {
      this.balance -= amt;
      target.balance += amt;
    }
  } 
}

在这段代码中，临界区内有两个资源，分别是转出账户的余额this.balance和转入账户的余额target.balance，并且用的是一把锁this，符合我们前面提到的，多个资源可以用一把锁来保护，这看上去完全正确呀。真的是这样吗？可惜，这个方案仅仅看似正确，为什么呢？

问题就处在this这把锁上，this这把锁可以保护自己的余额this.balance，却保护不了别人的余额target.balance，就像你不能用自家的锁保护别人家的资产，也不能用自己的票来保护别人的座位一样。

用锁this保护this.balance和target.balance的示意图

下面我们具体分析一下，假设有A、B、C三个账户，余额都是200元，我们用两个线程分别执行两个转账操作：账户A转给账户B100元，账户B转给账户C100元，最后我们期望的结果应该是账户A的余额是100元，账户B的余额是200元，账户C的余额是300元。

我们假设线程1窒息感账户A转账户B的操作，线程2执行账户B转账户C的操作。这两个线程分别在两颗CPU上同时执行，那它们互斥吗？我们期望的是，但实际上并不是。因为线程1锁定的账户A的实例（A.this），而线程2锁定的账户B的实例（B.this），所以这两个线程可以同时进入临界区transfer()。同时进入临界区的结果是什么呢？线程1和线程2都会读到账户B的余额为200，导致最终账户B的余额可能是300（线程1后于线程2写B.balance，线程2写的B.balance值被线程1覆盖），可能是100（线程1先于线程2写B.balance，线程1写的B.balance值被线程2覆盖），就是不可能是200。

并发转账示意图

使用锁的正确姿势

在上面，我们提到用同一把锁来保护多个资源，也就是现实世界的”包场“，那在编程领域怎么”包场“呢？很简单，只要我们的锁能覆盖所有受保护资源就可以了。在上面的例子中，this是对象级别的锁，所以A对象和B对象都有自己的锁，如何让A对象和B对象共享一把锁呢？

稍微开动脑筋，你会发现其实方案还是挺多的，比如可以让所有对象都持有一个唯一性的对象，这个对象在创建Account时传入。方案有了，完成代码就简单了。实际代码如下，我们把Account默认构造函数变为private，同时增加一个带Object lock参数的构造函数，创建Account对象时，传入相同的lock，这样所有的Account对象都会共享这个lock了。

class Account {
  private Object lock；
  private int balance;
  private Account();
  // 创建 Account 时传入同一个 lock 对象
  public Account(Object lock) {
    this.lock = lock;
  } 
  // 转账
  void transfer(Account target, int amt){
    // 此处检查所有对象共享的锁
    synchronized(lock) {
      if (this.balance > amt) {
        this.balance -= amt;
        target.balance += amt;
      }
    }
  }
}

这个办法确实能解决问题，但是有点小瑕疵，它要求在创建Account对象的时候必须传入同一个对象，如果创建Account对象时，传入的lock不是同一个对象，那可就惨了，会出现锁自家门来保护他家资产的荒唐事。在真实的项目场景中，创建Account对象的代码很可能分散在多个工程中，传入共享的lock真的很难。

所以，上面的方案缺乏实践的可行性，我们需要更好的方案。还真有，就是用Account.class作为共享锁。Account.class是所有Account对象共享的，而且这个对象是java虚拟机在加载Account类的时候创建的，所以我们无需在创建Account对象时传入了，代码更简单。

class Account {
  private int balance;
  // 转账
  void transfer(Account target, int amt){
    synchronized(Account.class) {
      if (this.balance > amt) {
        this.balance -= amt;
        target.balance += amt;
      }
    }
  } 
}

下面这幅图很直观地展示了我们是如何使用共享锁Account.class来保护不同对象的临界区的。

”原子性“的本质是什么？其实不是不可分割，不可分割只是外在表现，其本质是多个资源间有一致性的要求，操作的中间状态对外部可见。所以解决原子性问题，是要保证中间状态对外不可见。

一不小心就死锁了，怎么办？

上面，用Account.class作为互斥锁，来解决银行业务里面的转账问题，虽然这个方案不存在并发问题，但是所有账户的转账操作都是串行的，例如账户 A 转账户 B、账户 C 转账户 D 这两个转账操作现实世界里是可以并行的，但是在这个方案里却被串行化了，这样的话，性能太差。

现实世界里，账户转账操作是支持并发的，而且绝对是真正的并行，银行所有的窗口都可以做转账操作。

我们试想在古代，没有信息化，账户的存在形式真的就是一个账本，而且每个账户都有一个账本，这些账本都统一存放在文件夹上。银行柜员在给我们做转账时，要去文件架上把转出账本和转入账本都拿到手，然后做转账。这个柜员在拿账本的时候可能遇到一下三种情况：

文件架上恰好有转出账本和转入账本，那就同时拿走；
如果文件架上只有转出账本和转入账本之一，那这个柜员就先把文件架上有的账本拿到手，同时等着其他柜员把另外一个账本送回来；
转出账本和转入账本都没有，那这个柜员就等着两个账本都被送回来。

上面这个过程在编程的世界里怎么实现呢？其实用两把锁就实现了，转出账本一把，转入账本另一把。在 transfer() 方法内部，我们首先尝试锁定转出账户 this（先把转出账本拿到手），然后尝试锁定转入账户 target（再把转入账本拿到手），只有当两者都成功时，才执行转账操作。这个逻辑可以图形化为下图这个样子。

两个转账操作并行示意图

而至于详细的代码实现，如下所示。经过这样的优化后，账户 A 转账户 B 和账户 C 转账户 D 这两个转账操作就可以并行了。

class Account {
  private int balance;
  // 转账
  void transfer(Account target, int amt){
    // 锁定转出账户
    synchronized(this) {              
      // 锁定转入账户
      synchronized(target) {           
        if (this.balance > amt) {
          this.balance -= amt;
          target.balance += amt;
        }
      }
    }
  } 
}

上面的实现看上去很完美，并且也算是将锁用得出神入化了。相对于用Account.class做为互斥锁，锁定的范围太大，而我们锁定两个账户范围就小多了，这样的锁，叫细粒度锁。使用细粒度锁可以提高并行度，是性能优化的一个重要手段。

使用细粒度锁是有代价的，这个代价就是可能会导致死锁。

在详细介绍死锁之前，我们先看看现实世界里的一种特殊场景。如果有客户找柜员张三做个转账业务：账户 A 转账户 B 100 元，此时另一个客户找柜员李四也做个转账业务：账户 B 转账户 A 100 元，于是张三和李四同时都去文件架上拿账本，这时候有可能凑巧张三拿到了账本 A，李四拿到了账本 B。张三拿到账本 A 后就等着账本 B（账本 B 已经被李四拿走），而李四拿到账本 B 后就等着账本 A（账本 A 已经被张三拿走），他们要等多久呢？他们会永远等待下去…因为张三不会把账本 A 送回去，李四也不会把账本 B 送回去。我们姑且称为死等吧。

转账业务中的“死等”

现实世界里的死等，就是编程领域的死锁了。死锁的一个比较专业的定义是：一组互相竞争资源的线程因互相等待，导致“永久”阻塞的现象。

上面转账的代码是怎么发生死锁的呢？我们假设线程 T1 执行账户 A 转账户 B 的操作，账户 A.transfer(账户 B)；同时线程 T2 执行账户 B 转账户 A 的操作，账户 B.transfer(账户 A)。当 T1 和 T2 同时执行完①处的代码时，T1 获得了账户 A 的锁（对于 T1，this 是账户 A），而 T2 获得了账户 B 的锁（对于 T2，this 是账户 B）。之后 T1 和 T2 在执行②处的代码时，T1 试图获取账户 B 的锁时，发现账户 B 已经被锁定（被 T2 锁定），所以 T1 开始等待；T2 则试图获取账户 A 的锁时，发现账户 A 已经被锁定（被 T1 锁定），所以 T2 也开始等待。于是 T1 和 T2 会无期限地等待下去，也就是我们所说的死锁了。

class Account {
  private int balance;
  // 转账
  void transfer(Account target, int amt){
    // 锁定转出账户
    synchronized(this){     ①
      // 锁定转入账户
      synchronized(target){ ②
        if (this.balance > amt) {
          this.balance -= amt;
          target.balance += amt;
        }
      }
    }
  } 
}

关于这种现象，我们还可以借助资源分配图来可视化锁的占用情况（资源分配图是个有向图，它可以描述资源和线程的状态）。其中，资源用方形节点表示，线程用圆形节点表示；资源中的点指向线程的边表示线程已经获得该资源，线程指向资源的边则表示线程请求资源，但尚未得到。转账发生死锁时的资源分配图就如下图所示，一个“各据山头死等”的尴尬局面。

转账发生死锁时的资源分配图

并发程序一旦死锁，一般没有特别好的方法，很多时候我们只能重启应用。因此，解决死锁问题最好的办法还是规避死锁。

那如何避免死锁呢？要避免死锁就需要分析死锁发生的条件，有个叫 Coffman 的牛人早就总结过了，只有以下这四个条件都发生时才会出现死锁：

互斥，共享资源 X 和 Y 只能被一个线程占用；
占有且等待，线程 T1 已经取得共享资源 X，在等待共享资源 Y 的时候，不释放共享资源 X；
不可抢占，其他线程不能强行抢占线程 T1 占有的资源；
循环等待，线程 T1 等待线程 T2 占有的资源，线程 T2 等待线程 T1 占有的资源，就是循环等待。

反过来分析，也就是说只要我们破坏其中一个，就可以成功避免死锁的发生。

其中，互斥这个条件我们没有办法破坏，因为我们用锁为的就是互斥。不过其他三个条件都是有办法破坏掉的，到底如何做呢？

对于“占用且等待”这个条件，我们可以一次性申请所有的资源，这样就不存在等待了。
对于“不可抢占”这个条件，占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源，这样不可抢占这个条件就破坏掉了。
对于“循环等待”这个条件，可以靠按序申请资源来预防。所谓按序申请，是指资源是有线性顺序的，申请的时候可以先申请资源序号小的，再申请资源序号大的，这样线性化后自然就不存在循环了。

我们已经从理论上解决了如何预防死锁，那具体如何体现在代码上呢？下面我们就来尝试用代码实践一下这些理论。

1.破坏占用且等待条件

从理论上讲，要破坏这个条件，可以一次性申请所有资源。在现实世界里，就拿前面我们提到的转账操作来讲，它需要的资源有两个，一个是转出账户，另一个是转入账户，当这两个账户同时被申请时，我们该怎么解决这个问题呢？

可以增加一个账本管理员，然后只允许账本管理员从文件架上拿账本，也就是说柜员不能直接在文件架上拿账本，必须通过账本管理员才能拿到想要的账本。例如，张三同时申请账本 A 和 B，账本管理员如果发现文件架上只有账本 A，这个时候账本管理员是不会把账本 A 拿下来给张三的，只有账本 A 和 B 都在的时候才会给张三。这样就保证了“一次性申请所有资源”。

通过账本管理员拿账本

class Alloctor{
    private List

并发理论

可见性、原子性和有序性问题

Java内存模型

互斥锁

一不小心就死锁了，怎么办？

安全性、活跃性以及性能问题

管程

java线程：java线程的生命周期

java线程：创建多少线程才是合适的？

java线程：为什么局部变量是线程安全的？

你可能感兴趣的:(并发理论)