The theory of concurrent programming

来由

借助数据库和类似Tomcat中间件而不用写并发程序的时代已经过去了。

举个例子，Java里的synchronized、wait()/notify() 相关的知识很琐碎，看懂难，会用更难。

但实际上 synchronized、wait()、notify() 不过是操作系统领域里管程模型的一种实现而已，Java SDK 并发包里的条件变量 Condition 也是管程里的概念，如果站在管程这个理论模型的高度而不是单独理解，用起来就得心应手了。

管程

一种解决并发问题的模型，与信号量在逻辑上是等价的，但管程更易用

很多语言都支持管程。

Java SDK并发包乃是并发大师 Doug Lea 出品，其章法在哪里呢？

并发编程其实就是三个核心问题【且Java SDK并发包大部分内容都是按照这三个维度组织的】：

  1. 分工
    • 如何高效地拆解任务并分配给线程
    • E.g.：Fork/Join框架
  2. 同步
    • 线程之间如何协作
    • E.g.：CountDownLatch
  3. 互斥
    • 保证同一时刻只允许一个线程访问共享资源
    • E.g.：可重入锁

Java SDK仅仅是针对并发问题开发出来的工具而已

并发编程BUG的源头

CPU、内存、I/O设备三者中间存在一个核心矛盾就是速度差异

CPU 一天对内存一年；内存一天对I/O设备十年

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

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

正是这些造就了并发编程的BUG神出鬼没

缓存导致的可见性问题

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

单核时代，所有的线程都是在一颗 CPU 上执行，CPU 缓存与内存的数据一致性容易解决。因为所有线程都是操作同一个 CPU 的缓存，一个线程对缓存的写，对另外一个线程来说一定是可见的。

img

CPU缓存与内存的关系

多核时代，每颗 CPU 都有自己的缓存，这时 CPU 缓存与内存的数据一致性就没那么容易解决了，当多个线程在不同的 CPU 上执行时，这些线程操作的是不同的 CPU 缓存。

img

多核CPU的缓存与内存关系

验证

多核场景下的可见性问题

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
public class Test1 {
  private static long count = 0;
  private void add10K() {
    int idx = 0;
    while(idx++ < 10000) {
      count += 1;
    }
  }
  public static void main(String[] args) {
    Test1 test = new Test1();
    // 创建两个线程，执行add()操作
    Thread th1 = new Thread(()->{
      test.add10K();
    });
    Thread th2 = new Thread(()->{
      test.add10K();
    });
    // 启动两个线程
    th1.start();
    th2.start();
    // 等待两个线程执行结束
    try {
		th1.join();
	} catch (InterruptedException e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	}
    try {
		th2.join();
	} catch (InterruptedException e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	}
    System.out.println("count:"+ count);
  }
}

其运行结果并非我们的直觉2000，而是一个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，原因是两个线程不是同时启动的，有一个时差。

线程切换带来的原子性问题

I/O太慢，所以早期系统发明了多进程

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

img

线程切换

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

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

支持多进程分时复用在操作系统发展史上有里程碑意义

  • 早期的操作系统基于进程来调度 CPU，不同进程间是不共享内存空间的，所以进程要做任务切换就要切换内存映射地址，而一个进程创建的所有线程，都是共享一个内存空间的，所以线程做任务切换成本就很低了。

  • 现代的操作系统都基于更轻量的线程来调度，现在我们提到的“任务切换”都是指“线程切换”。

Java并发程序都是基于多线程的，自然会涉及到任务切换，任务切换的时机大多数都是在时间片结束的时候，高级语言里一条语句往往需要多条CPU指令完成。

E.g.：count += 1

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

操作系统做任务切换，可以在任何一条CPU指令执行完，对于上述三条指令，我们假设count = 0，如果线程A在指令1执行完后做线程切换，线程A和线程B按照图示执行，那么就会两个线程都执行了count+=1的操作，得到1而不是2。

img

非原子操作的执行路径

我们潜意识里面觉得 count+=1 这个操作是一个不可分割的整体，就像一个原子一样，线程的切换可以发生在 count+=1 之前，也可以发生在 count+=1 之后，但就是不会发生在中间。

我们把一个或者多个操作在 CPU 执行的过程中不被中断的特性称为原子性。CPU 能保证的原子操作是 CPU 指令级别的，而不是高级语言的操作符，这是违背我们直觉的地方。因此，很多时候我们需要在高级语言层面保证操作的原子性。

编译优化带来的有序性问题

有序性指的是程序按照代码的先后顺序执行

编译器为了优化性能，有时候会改变程序中语句的先后顺序，例如程序中：“a=6；b=7；”编译器优化后可能变成“b=7；a=6；”。

Java领域里有一个经典的案例就是利用双重检查创建单例对象

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
/**
 *在获取实例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；② 在内存上初始化Singleton对象；③ 然后M的地址赋值给instance变量

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

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

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

img

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

问题

Q：32位机器上对long型变量进行加减操作存在并发隐患。

A：long类型64位，在32位的机器上，对long类型的数据操作通常需要多条指令组合出来，无法保证原子性。

原因就是文章里的bug源头之二：线程切换带来的原子性问题。
非volatile类型的long和double型变量是8字节64位的，32位机器读或写这个变量时得把人家咔嚓分成两个32位操作，可能一个线程读了某个值的高32位，低32位已经被另一个线程改了。所以官方推荐最好把long\double 变量声明为volatile或是同步加锁synchronize以避免并发问题。Reference

解决问题

解决可见性和有序性问题

Java 内存模型

Java 内存模型规范了 JVM 如何提供按需禁用缓存和编译优化的方法。具体来说，这些方法包括 volatile、synchronized 和 final 三个关键字，以及六项 Happens-Before 规则。

我们都知道导致可见性的原因是缓存，导致有序性的原因是编译优化，那解决可见性、有序性最直接的办法就是禁用缓存和编译优化。

但是这样虽然问题解决了，但是程序的性能达不到最佳

合理的方案应该是按需禁用缓存以及编译优化，所谓“按需禁用”其实就是指按照程序员的要求来禁用。所以，为了解决可见性和有序性问题，只需要提供给程序员按需禁用缓存和编译优化的方法即可。

volatile

禁用CPU缓存

E.g.：声明一个 volatile 变量 volatile int x = 0，其代表的含义：对这个变量的读写，不能使用 CPU 缓存，必须从内存中读取或者写入。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/**
*假设线程 A 执行 writer() 方法，按照 volatile 语义，会把变量 “v=true” 写入内存；
*假设线程 B 执行 reader() 方法，同样按照 volatile 语义，线程 B 会从内存中读取变量 v，
*如果线程 B 看到 “v == true” 时，那么线程 B 看到的变量 x 是多少呢？
*/
//取决于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会是多少呢？
    }
  }
}

在Java1.5时对volatile语义进行了增强，通过Happens-Before 规则的方法。

Happens-Before 规则

前面一个操作的结果对后续操作是可见的。

约束了编译器的优化行为，虽然允许编译器优化，但是要求优化后一定遵守规则

程序的顺序性规划

在一个线程中，按照程序顺序，前面的操作 Happens-Before 于后续的任意操作。

E.g.：代码 “x = 42;” Happens-Before 于代码 “v = true;”。

符合单线程思维：程序前面对某个变量的修改一定是对后续操作可见的

volatile 变量规则

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

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

传递性

如果 A Happens-Before B，且 B Happens-Before C，那么 A Happens-Before C。

img

示例代码中的传递性规则
  1. “x=42” Happens-Before 写变量 “v=true” ，这是规则 1 的内容；
  2. 写变量“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 语义来搞定可见性的，

管程中锁的规则

对一个锁的解锁 Happens-Before 于后续对这个锁的加锁。

我们前面提到过：管程是一种通用的同步原语，在 Java 中指的就是 synchronized，synchronized 是 Java 里对管程的实现。

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

1
2
3
4
5
6
synchronized (this) { //此处自动加锁
  // x是共享变量,初始值=10
  if (this.x < 12) {
    this.x = 12; 
  }  
} //此处自动解锁

假设 x 的初始值是 10，线程 A 执行完代码块后 x 的值会变成 12（执行完自动释放锁），线程 B 进入代码块时，能够看到线程 A 对 x 的写操作，也就是线程 B 能够看到 x==12。

线程start()规则

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

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

1
2
3
4
5
6
7
8
9
Thread B = new Thread(()->{
  // 主线程调用B.start()之前
  // 所有对共享变量的修改，此处皆可见
  // 此例中，var==77
});
// 此处对共享变量var修改
var = 77;
// 主线程启动子线程
B.start();
线程 join() 规则

关于线程等待的，主线程 A 等待子线程 B 完成（主线程 A 通过调用子线程 B 的 join() 方法实现），当子线程 B 完成后（主线程 A 中 join() 方法返回），主线程能够看到子线程的操作。

看到：指的是对共享变量的操作

如果在线程 A 中，调用线程 B 的 join() 并成功返回，那么线程 B 中的任意操作 Happens-Before 于该 join() 操作的返回。

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

final

我们提到volatile为禁用缓存以及编译优化，final可以告诉编译器优化得更好一些。

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

问题类似于上一期提到的利用双重检查方法创建单例，构造函数的错误重排导致线程可能看到 final 变量的值会变化。详细的案例可以参考Reference

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

1
2
3
4
5
6
7
8
9
10
11
12
13
/**
*在构造函数里面将 this 赋值给了全局变量 global.obj，这就是“逸出”，
*线程通过 global.obj 读取 x 是有可能读到 0 的。因此我们一定要避免“逸出”。
*/
// 以下代码来源于【参考1】
final int x;
// 错误的构造函数
public FinalFieldExample() { 
  x = 3;
  y = 4;
  // 此处就是讲this逸出，
  global.obj = this;
}

Reference：

  1. JSR 133 (Java Memory Model) FAQ

  2. Java 内存模型 FAQ

  3. JSR-133: JavaTM Memory Model and Thread Specification

在这里插入图片描述

Q: 有一个共享变量 abc，在一个线程里设置了 abc 的值 abc=3，有哪些办法可以让其他线程能够看到abc==3？

A:

  1. 声明共享变量abc，并使用volatile关键字修饰abc
  2. 声明共享变量abc，在synchronized关键字对abc的赋值代码块加锁，由于Happen-before管程锁的规则，可以使得后续的线程可以看到abc的值。
  3. A线程启动后，使用A.JOIN()方法来完成运行，后续线程再启动，则一定可以看到abc==3

解决原子性问题

一个或者多个操作在CPU执行的过程中不被中断的特性，称为原子性

原子性问题的源头是线程切换，而操作系统做线程切换是依CPU中断的，所以禁止CPU发生中断就能够禁止线程切换。

这样的方案在单核CPU上可行，但是对于多核CPU，例如前面的问题，long型变量时64位，在32位CPU上执行写操作会被拆分成两次操作(写高32位和写低32位)

img

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

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

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

简易锁模型

谈到互斥，首要的解决方案肯定是锁

img

简易锁模型

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

改进锁模型

img

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

在锁 LR 和受保护资源之间，我特地用一条线做了关联，这个关联关系非常重要。很多并发 Bug 的出现都是因为把它忽略了，然后就出现了类似锁自家门来保护他家资产的事情，这样的 Bug 非常不好诊断，因为潜意识里我们认为已经正确加锁了。

Java语言提供的锁技术：synchronized

可以用来修饰方法、也可以修饰代码块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class X {
  // 修饰非静态方法
  synchronized void foo() {
    // 临界区
  }
  // 修饰静态方法
  synchronized static void bar() {
    // 临界区
  }
  // 修饰代码块
  Object obj = new Object()；
  void baz() {
    synchronized(obj) {
      // 临界区
    }
  }
}

可能从这些用法中我们没有发现lock()和unlock()，这两个操作是被Java自动默认加上的，在synchronized修饰的方法或代码块前后自动加上lock()和unlock() ，好处是一定是成对出现的，忘记unlock()比较致命，容易导致线程一直等待。

那么synchronized里的加锁 lock() 和解锁 unlock() 锁定的对象在哪里呢？

上面的代码我们看到只有修饰代码块的时候，锁定了一个 obj 对象，那修饰方法的时候锁定的是什么呢？这个也是 Java 的一条隐式规则：

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

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

1
2
3
4
5
6
7

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

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

1
2
3
4
5
6
7

class X {
  // 修饰非静态方法
  synchronized(this) void foo() {
    // 临界区
  }
}
用synchronized解决count+=1的问题

SafeCalc这个类有两个方法：

  • get方法，获得value
  • addOne方法，给value加1，并且用synchronized修饰
1
2
3
4
5
6
7
8
9
10

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

addOne方法首先被肯定的是被修饰后，无论是单核还是多核，只有一个线程能够执行addOne方法，所以一定能保证原子性操作，那是否有可见性问题呢？

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

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

按照这个规则，如果多个线程同时执行 addOne() 方法，可见性是可以保证的，也就说如果有 1000 个线程执行 addOne() 方法，最终结果一定是 value 的值增加了 1000。看到这个结果，我们长出一口气，问题终于解决了。

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

1
2
3
4
5
6
7
8
9
10

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

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

img

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

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

锁和受保护资源的关系

受保护资源和锁之间的关联关系是 N:1 的关系

拿前面球赛门票的管理来类比，就是一个座位，我们只能用一张票来保护，如果多发了重复的票，那就要打架了。现实世界里，我们可以用多把锁来保护同一个资源，但在并发领域是不行的，并发领域的锁和现实世界的锁不是完全匹配的。不过倒是可以用同一把锁来保护多个资源，这个对应到现实世界就是我们所谓的“包场”了。

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

1
2
3
4
5
6
7
8
9
10

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() 也没有可见性保证，这就导致并发问题了。

锁保护了资源，同时锁和资源是有对应关系的，所以从资源出发，也可以区分两把锁是不是同一个。 参见下一节课的笔记，可以看出Java里没有单独的锁类型，锁就是用一个对象来表示的，锁和被保护资源之间的对应关系是靠代码逻辑实现的。

img

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

Conclusion

并发问题首要想到的解决办法还是加锁，因为加锁能够保证执行临界区代码的互斥性。

真正用好互斥锁： 临界区的代码是操作受保护资源的路径，类似于球场的入口，入口一定要检票，也就是要加锁，但不是随便一把锁都能有效。所以必须深入分析锁定的对象和受保护资源的关系，综合考虑受保护资源的访问路径，多方面考量才能用好互斥锁。

synchronized 是 Java 在语言层面提供的互斥原语，其实 Java 里面还有很多其他类型的锁，但作为互斥锁，原理都是相通的：锁，一定有一个要锁定的对象，至于这个锁定的对象要保护的资源以及在哪里加锁 / 解锁，就属于设计层面的事情了。

问题

1
2
3
4
5
6
7
8
9
10
11
12
13
class SafeCalc {
  long value = 0L;
  long get() {
    synchronized (new Object()) {
      return value;
    }
  }
  void addOne() {
    synchronized (new Object()) {
      value += 1;
    }
  }
}

synchronized这个使用方式正确吗？有哪些问题呢？能解决可见性和原子性问题吗？

  • 加锁的本质就是在锁对象的对象头中写入当前线程id，但是new object每次在内存中都是新对象，所以加锁无效
  • 经过JVM逃逸分析的优化后，这段代码会被直接优化掉，所以在运行时是无锁的
  • sync锁的对象monitor指针指向一个ObjectMonitor对象，所有线程加入他的entrylist里面，去cas抢锁，更改state加1拿锁，执行完代码，释放锁state减1，和aqs机制差不多，只是所有线程不阻塞，cas抢锁，没有队列，属于非公平锁。wait的时候，线程进waitset休眠，等待notify唤醒
  • 多把锁保护同一个资源，就像一个厕所坑位，有N多门可以进去，没有丝毫保护效果，管理员一看，还不如把门都撤了，弄成开放式(编译器代码优化)😂。
  • 两把不同的锁，不能保护临界资源。而且这种new出来只在一个地方使用的对象，其它线程不能对它解锁，这个锁会被编译器优化掉。和没有syncronized代码块效果是相同的
  • 不能，因为new了，所以不是同一把锁。老师您好，我对那 synchronized的理解是这样，它并不能改变CPU时间片切换的特点，只是当其他线程要访问这个资源时，发现锁还未释放，所以只能在外面等待，不知道理解是否正确
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
public class A implements Runnable {
    public Integer b = 1;
 
    @Override
    public void run() {
       System.out.println("A is begin!");
       while (true) {
               System.out.println("a");
           // System.out.println(b);
           if (b.equals(2))
              break;
       }
 
       System.out.println("A is finish!");
    }
 
    public static void main(String[] args) {
       A a = new A();
       //线程A
       new Thread(a).start();
       try {
           Thread.sleep(1000);
       } catch (InterruptedException e) {
           e.printStackTrace();
       }
       a.b = 2;
    }
}
 
我们知道这个程序会出现可见性问题。
但是在while内加上System.out.println(b)后 当主线程修改b的值后 线程A居然能够取得最新值 可见性问题得到解决
System.out.println(b)的实现如下
    public void println(String x) {
        synchronized (this) {
            print(x);
            newLine();
        }
    }
 
Doug Lea大神的Concurrent Programming in Java一书中有这样一个片段来描述synchronized这个关键字：
 
这里英文就不放出来了 字数超过两千……
这篇文章也有提及https://www.jianshu.com/p/3c06ffbf0d52
 
简单翻译一下：从本质上来说，当线程释放一个锁时会强制性的将工作内存中之前所有的写操作都刷新到主内存中去，而获取一个锁则会强制性的加载可访问到的值到线程工作内存中来。虽然锁操作只对同步方法和同步代码块这一块起到作用，但是影响的却是线程执行操作所使用的所有字段。


也就是说当调用System.out.println("a")时当前线程的缓存会被重新刷新过，所以才能够读到这个值最新值
 ---------------------------------------------------------
然后问题来了
问题1:
首先上面的说法不知道是不是真的是这样。
然后我在下面加了System.out.println(b) 结果打印出来的是旧值，但是下面的b.equals(2)却能通过 这里没弄明白 我觉得应该是编译器进行了优化?因为现在大三能力不够，还没学会看class文件 没法验证
 
问题2:
网上找了一些文章
有些人的说法是：打印是IO操作，而IO操作会引起线程的切换，线程切换会导致线程原本的缓存失效，从而也会读取到修改后的值。
 
我尝试着将打印换成File file = new File("D://1.txt");这句代码，程序也能够正常的结束。当然，在这里也可以尝试将将打印替换成synchronized(A.class){ }这句空同步代码块，发现程序也能够正常结束。
 
这里有个问题就是 线程切换时会把之前操作的相关数据保存到内存里，切换回来后会把内存里的数据重新加载到寄存器里吗，这样说的话 就算切换也是获取不到修改后的值的,不知道是什么做到能够读到这个修改后的值的？
 
问题3:
是不是
线程执行过程中，操作系统会随机性的把缓存刷到内存
线程结束后一定会把缓存里的数据刷到内存

 ---------------------------------------------------------
在评论里好多大神 能学到好多东西😄😄
作者回复: 1. println的代码里锁的this指的是你的控制台，这个锁跟你的代码没关系，而且println里也没有写操作，所以println不会导致强刷缓存。

我觉得是因为println产生了IO，IO相对CPU来说，太慢，所以这个期间大概率的会把缓存的值写入内存。也有可能这个线程被调度到了其他的CPU上，压根没有缓存，所以只能从内存取数。你调用sleep，效果应该也差不多。

2. 线程切换显然不足以保证可见性，保证的可见性只能靠hb规则。

3. 线程结束后，不一定会强刷缓存。否则Join的规则就没必要了

并发问题本来就是小概率的事件，尤其有了IO操作之后，概率就更低了。

如何用一把锁保护多个资源？

前面我们提到，可以用一把锁来保护多个资源，但是不能用多把锁来保护一个资源。

当我们要保护多个资源时，首先要区分这些资源是否存在关联关系。

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

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

账户类 Account 有两个成员变量，分别是账户余额 balance 和账户密码 password。取款 withdraw() 和查看余额 getBalance() 操作会访问账户余额 balance，我们创建一个 final 对象 balLock 作为锁（类比球赛门票）；而更改密码 updatePassword() 和查看密码 getPassword() 操作会修改账户密码 password，我们创建一个 final 对象 pwLock 作为锁（类比电影票）。不同的资源用不同的锁保护，各自管各自的，很简单。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

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() 没有并发问题呢？

1
2
3
4
5
6
7
8
9
10
11
class Account {
  private int balance;
  // 转账
  void transfer(
      Account target, int amt){
    if (this.balance > amt) {
      this.balance -= amt;
      target.balance += amt;
    }
  } 
}

直觉告诉我，用户synchronized关键字修饰以下transfer()方法就可以，于是：

1
2
3
4
5
6
7
8
9
10
11
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，不能用自家的锁来保护被人家的资产。

img

用锁this保护this.balance和target.balance

假设有 A、B、C 三个账户，余额都是 200 元，我们用两个线程分别执行两个转账操作：账户 A 转给账户 B 100 元，账户 B 转给账户 C 100 元，最后我们期望的结果应该是账户 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。

img

并发转账

使用锁的正确姿势

前面我们提到用同一把锁来保护多个资源，就是包场

只要我们的锁能覆盖所有受保护的资源就可以。

在上面的例子中，this 是对象级别的锁，所以 A 对象和 B 对象都有自己的锁，如何让 A 对象和 B 对象共享一把锁呢？

首先想到的方法是可以让所有对象都持有一个唯一性的对象，这个对象在创建 Account 时传入。我们把 Account 默认构造函数变为 private，同时增加一个带 Object lock 参数的构造函数，创建 Account 对象时，传入相同的 lock，这样所有的 Account 对象都会共享这个 lock 了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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 对象时传入了，代码更简单。

1
2
3
4
5
6
7
8
9
10
11
12
class Account {
  private int balance;
  // 转账
  void transfer(Account target, int amt){
    synchronized(Account.class) {
      if (this.balance > amt) {
        this.balance -= amt;
        target.balance += amt;
      }
    }
  } 
}

img

使用共享的锁 Account.class 来保护不同对象的临界区

Conclusion

如何保护多个资源关键是要分析多个资源之间的关系。如果资源之间没有关系，很好处理，每个资源一把锁就可以了。如果资源之间有关联关系，就要选择一个粒度更大的锁，这个锁应该能够覆盖所有相关的资源。除此之外，还要梳理出有哪些访问路径，所有的访问路径都要设置合适的锁，这个过程可以类比一下门票管理。

关联关系如果用更具体、更专业的语言来描述的话，其实是一种“原子性”特征，在前面的文章中，我们提到的原子性，主要是面向 CPU 指令的，转账操作的原子性则是属于是面向高级语言的，不过它们本质上是一样的。

“原子性”的本质是什么？其实不是不可分割，不可分割只是外在表现，其本质是多个资源间有一致性的要求，操作的中间状态对外不可见。例如，在 32 位的机器上写 long 型变量有中间状态（只写了 64 位中的 32 位），在银行转账的操作中也有中间状态（账户 A 减少了 100，账户 B 还没来得及发生变化）。所以解决原子性问题，是要保证中间状态对外不可见。

问题

Q： 我们用了两把不同的锁来分别保护账户余额、账户密码，创建锁的时候，我们用的是：private final Object xxxLock = new Object();，如果账户余额用 this.balance 作为互斥锁，账户密码用 this.password 作为互斥锁，你觉得是否可以呢？

A： ** **不能用可变对象做锁，用this.balance 和this.password 都不行。在同一个账户多线程访问时候，A线程取款进行this.balance-=amt;时候此时this.balance对应的值已经发生变换，线程B再次取款时拿到的balance对应的值并不是A线程中的，也就是说不能把可变的对象当成一把锁。this.password 虽然说是String修饰但也会改变，所以也不行。

不能用balance和password做为锁对象。这两个对象balance是Integer，password是String都是不可变变对象，一但对他们进行赋值就会变成新的对象，加的锁就失效了

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

前面我们用Account.class作为互斥锁，来解决银行业务里面的转账问题，虽然这个方案不存在并发问题，但是所有账户的转账操作都是串行的。

例如账户A转账户B、账户C转账户D这两个转账操作现实世界里是可以并行的。但是在这个方案里却被串行化了，这样的话，性能太差。

试想互联网支付盛行的当下，8 亿网民每人每天一笔交易，每天就是 8 亿笔交易；每笔交易都对应着一次转账操作，8 亿笔交易就是 8 亿次转账操作，也就是说平均到每秒就是近 1 万次转账操作，若所有的转账操作都串行，性能完全不能接受。

那我们就尝试把性能提升一下。

向现实世界要答案

现实世界里，账户转账操作是支持并发的，而且绝对是真正的并行，银行所有的窗口都可以做转账操作。只要我们能仿照现实世界做转账操作，串行的问题就解决了。

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

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

这个过程用两把锁就实现了，转出账本一把，转入账本另一把，在transfer()方法内部，首先尝试所的那个转出账户this（先把转出账本拿到手），然后尝试锁定转入账户 target（再把转入账本拿到手），只有当两者都成功时，才执行转账操作。

img

两个转账操作并行

经过这样的优化，账户A转账户B和账户C转账户D这两个转账操作就可以并行了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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 送回去。

img

转账业务中的“死等”

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

上面转账的代码是怎么发生死锁的呢？我们假设线程 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 会无期限地等待下去，也就是我们所说的死锁了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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;
        }
      }
    }
  } 
}

关于这种现象，我们还可以借助资源分配图来可视化锁的占用情况（资源分配图是个有向图，它可以描述资源和线程的状态）。

其中，资源用方形节点表示，线程用圆形节点表示；资源中的点指向线程的边表示线程已经获得该资源，线程指向资源的边则表示线程请求资源，但尚未得到。转账发生死锁时的资源分配图就如下图所示，一个“各据山头死等”的尴尬局面。

img

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

发现了问题，那么

如何预防死锁呢

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

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

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

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

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

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

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

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

img

通过账本管理员拿账本

对应到编程领域，“同时申请”这个操作是一个临界区，我们也需要一个角色（Java 里面的类）来管理这个临界区，我们就把这个角色定为 Allocator。它有两个重要功能，分别是：同时申请资源 apply() 和同时释放资源 free()。账户 Account 类里面持有一个 Allocator 的单例（必须是单例，只能由一个人来分配资源）。当账户 Account 在执行转账操作的时候，首先向 Allocator 同时申请转出账户和转入账户这两个资源，成功后再锁定这两个资源；当转账操作执行完，释放锁之后，我们需通知 Allocator 同时释放转出账户和转入账户这两个资源。具体的代码实现如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
class Allocator {
  private List<Object> als =
    new ArrayList<>();
  // 一次性申请所有资源
  synchronized boolean apply(
    Object from, Object to){
    if(als.contains(from) ||
         als.contains(to)){
      return false;  
    } else {
      als.add(from);
      als.add(to);  
    }
    return true;
  }
  // 归还资源
  synchronized void free(
    Object from, Object to){
    als.remove(from);
    als.remove(to);
  }
}

class Account {
  // actr应该为单例
  private Allocator actr;
  private int balance;
  // 转账
  void transfer(Account target, int amt){
    // 一次性申请转出账户和转入账户，直到成功
    while(!actr.apply(this, target))
      ；
    try{
      // 锁定转出账户
      synchronized(this){              
        // 锁定转入账户
        synchronized(target){           
          if (this.balance > amt){
            this.balance -= amt;
            target.balance += amt;
          }
        }
      }
    } finally {
      actr.free(this, target)
    }
  } 
}
破坏不可抢占条件

破坏不可抢占条件看上去很简单，核心是要能够主动释放它占有的资源，这一点 synchronized 是做不到的。原因是 synchronized 申请资源的时候，如果申请不到，线程直接进入阻塞状态了，而线程进入阻塞状态，啥都干不了，也释放不了线程已经占有的资源。

你可能会质疑，“Java 作为排行榜第一的语言，这都解决不了？”你的怀疑很有道理，Java 在语言层次确实没有解决这个问题，不过在 SDK 层面还是解决了的，java.util.concurrent 这个包下面提供的 Lock 是可以轻松解决这个问题的。关于这个话题，咱们后面会详细讲。

破坏循环等待条件

破坏这个条件，需要对资源进行排序，然后按序申请资源。这个实现非常简单，我们假设每个账户都有不同的属性 id，这个 id 可以作为排序字段，申请的时候，我们可以按照从小到大的顺序来申请。比如下面代码中，①~⑥处的代码对转出账户（this）和转入账户（target）排序，然后按照序号从小到大的顺序锁定账户。这样就不存在“循环”等待了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
class Account {
  private int id;
  private int balance;
  // 转账
  void transfer(Account target, int amt){
    Account left = this        ①
    Account right = target;    ②
    if (this.id > target.id) { ③
      left = target;           ④
      right = this;            ⑤
    }                          ⑥
    // 锁定序号小的账户
    synchronized(left){
      // 锁定序号大的账户
      synchronized(right){ 
        if (this.balance > amt){
          this.balance -= amt;
          target.balance += amt;
        }
      }
    }
  } 
}

Conclusion

利用现实世界的模型来构思解决方案

在利用现实模型建模的时候，我们还要仔细对比现实世界和编程世界里的各角色之间的差异。

用细粒度锁来锁定多个资源时，要注意死锁的问题，识别出风险很重要。

预防死锁主要是破坏三个条件中的一个，有了这个思路后，实现就简单了。但仍需注意的是，有时候预防死锁成本也是很高的。例如上面转账那个例子，我们破坏占用且等待条件的成本就比破坏循环等待条件的成本高，破坏占用且等待条件，我们也是锁了所有的账户，而且还是用了死循环 while(!actr.apply(this, target));方法，不过好在 apply() 这个方法基本不耗时。 在转账这个例子中，破坏循环等待条件就是成本最低的一个方案。

所以我们在选择具体方案的时候，还需要评估一下操作成本，从中选择一个成本最低的方案。

问题

破坏占用且等待条件，我们也是锁了所有的账户，而且还是用了死循环 while(!actr.apply(this, target));这个方法，那它比synchronized(Account.class) 有没有性能优势呢？

  • synchronized(Account.class) 锁了Account类相关的所有操作。相当于文中说的包场了，只要与Account有关联，通通需要等待当前线程操作完成。while死循环的方式只锁定了当前操作的两个相关的对象。两种影响到的范围不同。
  • 最简单的方案: 遇到死锁，我就是用资源id的从小到大的顺序去申请锁解决的
  • 用top命令查看Java线程的cpu利用率，用jstack来dump线程。开发环境可以用 java visualvm查看线程执行情况
  • while 循环就是一个自旋锁机制吧，自旋锁的话要关注它的循环时间，不能一直循环下去，不然会浪费 cpu 资源。自旋锁在JVM里是一种特殊的锁机制，自诩不会阻塞线程的。咱们这个其实还是会阻塞线程的。不过原理都一样，你这样理解也没问题。
  • 最常见的就是B转A的同时，A转账给B，那么先锁B再锁A，但是，另一个线程是先锁A再锁B，然而，如果两个线程同时执行，那么就是出现死锁的情况，线程T1锁了A请求锁B，此时线程T2锁了B请求锁A，都在等着对方释放锁，然而自己都不会释放锁，故死锁。
    最简单的办法，就是无论哪个线程执行的时候，都按照顺序加锁，即按照A和B的id大小来加锁，这样，无论哪个线程执行的时候，都会先加锁A，再加锁B，A被加锁，则等待释放。这样就不会被死锁了。

用“等待-通知”机制优化循环等待