关于后端:互斥锁深度理解与使用

大家好，我是易安!

咱们晓得一个或者多个操作在 CPU 执行的过程中不被中断的个性，称为“原子性”。了解这个个性有助于你剖析并发编程 Bug 呈现的起因，例如利用它能够剖析出 long 型变量在 32 位机器上读写可能呈现的诡异 Bug，明明曾经把变量胜利写入内存，从新读出来却不是本人写入的。

那原子性问题到底该如何解决呢？

原子性问题的源头是 线程切换，如果可能禁用线程切换那不就能解决这个问题了吗？而操作系统做线程切换是依赖 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，咱们还需在进出临界区时添上加锁操作和解锁操作。另外，在锁 LR 和受爱护资源之间，我顺便用一条线做了关联，这个关联关系十分重要。很多并发 Bug 的呈现都是因为把它疏忽了，而后就呈现了相似锁自家门来爱护他家资产的事件，这样的 Bug 十分不好诊断，因为潜意识里咱们认为曾经正确加锁了。

JDK 提供的锁：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()，这样做的益处就是加锁 lock()和解锁 unlock()肯定是成对呈现的，毕竟遗记解锁 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 = 0L;
  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 = 0L;
  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()也没有可见性保障，这就导致并发问题了。

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

刚刚咱们谈过 受爱护资源和锁之间正当的关联关系应该是 N:1 的关系，也就是说能够用一把锁来爱护多个资源，然而不能用多把锁来爱护一个资源，并且联合文中示例，咱们也重点强调了“不能用多把锁来爱护一个资源”这个问题。而至于如何爱护多个资源，咱们上面就来聊聊。

当咱们要爱护多个资源时，首先要辨别这些资源是否存在关联关系。

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

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

同样这对应到编程畛域，也很容易解决。例如，银行业务中有针对账户余额（余额是一种资源）的取款操作，也有针对账户明码（明码也是一种资源）的更改操作，咱们能够为账户余额和账户明码调配不同的锁来解决并发问题，这个还是很简略的。

相干的示例代码如下，账户类 Account 有两个成员变量，别离是账户余额 balance 和账户明码 password。取款 withdraw()和查看余额 getBalance()操作会拜访账户余额 balance，咱们创立一个 final 对象 balLock 作为锁（类比球赛门票）；而更改明码 updatePassword()和查看明码 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 转给账户 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。

并发转账示意图

应用锁的正确姿态

刚刚，咱们提到用同一把锁来爱护多个资源，也就是事实世界的“包场”，那在编程畛域应该怎么“包场”呢？很简略，只有咱们的 锁能笼罩所有受爱护资源 就能够了。在下面的例子中，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 对象时传入了，代码更简略。

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 来爱护不同对象的临界区的。

这个计划不存在并发问题，然而所有账户的转账操作都是串行的，例如账户 A 转账户 B、账户 C 转账户 D 这两个转账操作事实世界里是能够并行的，然而在这个计划里却被串行化了，这样的话，性能太差。事实世界里，账户转账操作是反对并发的，而且相对是真正的并行，银行所有的窗口都能够做转账操作。只有咱们能仿照事实世界做转账操作，串行的问题就解决了。

咱们试想在现代，没有信息化，账户的存在模式真的就是一个账本，而且每个账户都有一个账本，这些账本都对立寄存在文件架上。银行柜员在给咱们做转账时，要去文件架上把转出账本和转入账本都拿到手，而后做转账。这个柜员在拿账本的时候可能遇到以下三种状况：

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

下面这个过程如何用编程实现呢？其实用两把锁就实现了，转出账本一把，转入账本另一把。在 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 作为互斥锁，锁定的范畴太大，而咱们锁定两个账户范畴就小多了，这样的锁，叫 细粒度锁 。 应用细粒度锁能够进步并行度，是性能优化的一个重要伎俩。

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

转账业务中的“死等”

事实世界里的死等，就是编程畛域的死锁了。死锁 的一个比拟业余的定义是： 一组相互竞争资源的线程因相互期待，导致“永恒”阻塞的景象。

下面转账的代码是怎么产生死锁的呢？咱们假如线程 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 的牛人早就总结过了，只有以下这四个条件都产生时才会呈现死锁：

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

反过来剖析，也就是说只有咱们毁坏其中一个，就能够胜利防止死锁的产生。

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

1. 对于“占用且期待”这个条件，咱们能够一次性申请所有的资源，这样就不存在期待了。
2. 对于“不可抢占”这个条件，占用局部资源的线程进一步申请其余资源时，如果申请不到，能够被动开释它占有的资源，这样不可抢占这个条件就毁坏掉了。
3. 对于“循环期待”这个条件，能够靠按序申请资源来预防。所谓按序申请，是指资源是有线性程序的，申请的时候能够先申请资源序号小的，再申请资源序号大的，这样线性化后天然就不存在循环了。

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

1. 毁坏占用且期待条件

从实践上讲，要毁坏这个条件，能够一次性申请所有资源。在事实世界里，就拿后面咱们提到的转账操作来讲，它须要的资源有两个，一个是转出账户，另一个是转入账户，当这两个账户同时被申请时，咱们该怎么解决这个问题呢？

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

通过账本管理员拿账本

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

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)
    }
  }
}

2. 毁坏不可抢占条件

毁坏不可抢占条件看上去很简略，外围是要可能被动开释它占有的资源，这一点 synchronized 是做不到的。起因是 synchronized 申请资源的时候，如果申请不到，线程间接进入阻塞状态了，而线程进入阻塞状态，啥都干不了，也开释不了线程曾经占有的资源。

你可能会质疑，“Java 作为排行榜第一的语言，这都解决不了？”你的狐疑很有情理，Java 在语言档次的确没有解决这个问题，不过在 SDK 层面还是解决了的，java.util.concurrent 这个包上面提供的 Lock 是能够轻松解决这个问题的。

3. 毁坏循环期待条件

毁坏这个条件，须要对资源进行排序，而后按序申请资源。这个实现非常简单，咱们假如每个账户都有不同的属性 id，这个 id 能够作为排序字段，申请的时候，咱们能够依照从小到大的程序来申请。比方上面代码中，①~⑥处的代码对转出账户（this）和转入账户（target）排序，而后依照序号从小到大的程序锁定账户。这样就不存在“循环”期待了。

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;
        }
      }
    }
  }
}

总结

互斥锁，在并发畛域的知名度极高，只有有了并发问题，大家首先容易想到的就是加锁，因为大家都晓得，加锁可能保障执行临界区代码的互斥性。这样了解尽管正确，然而却不可能领导你真正用好互斥锁。临界区的代码是操作受爱护资源的门路，相似于球场的入口，入口肯定要检票，也就是要加锁，但不是轻易一把锁都能无效。所以必须深入分析锁定的对象和受爱护资源的关系，综合思考受爱护资源的拜访门路，多方面考量能力用好互斥锁。

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

对如何爱护多个资源，要害是要剖析多个资源之间的关系。如果资源之间没有关系，很好解决，每个资源一把锁就能够了。如果资源之间有关联关系，就要抉择一个粒度更大的锁，这个锁应该可能笼罩所有相干的资源。除此之外，还要梳理出有哪些拜访门路，所有的拜访门路都要设置适合的锁，这个过程能够类比一下门票治理。

咱们再引申一下下面提到的关联关系，关联关系如果用更具体、更业余的语言来形容的话，其实是一种“原子性”特色，在后面咱们提到的原子性，次要是面向 CPU 指令的，转账操作的原子性则是属于是面向高级语言的，不过它们实质上是一样的。

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

最初咱们还讲了 用细粒度锁来锁定多个资源时，要留神死锁的问题 。这个就须要你能把它强化为一个思维定势，遇到这种场景，马上想到可能存在死锁问题。当你晓得危险之后，才有机谈判如何预防和防止，因而， 辨认出危险很重要。

预防死锁次要是毁坏三个条件中的一个，有了这个思路后，实现就简略了。但仍需注意的是，有时候预防死锁老本也是很高的。例如下面转账那个例子，咱们毁坏占用且期待条件的老本就比毁坏循环期待条件的老本高，毁坏占用且期待条件，咱们也是锁了所有的账户，而且还是用了死循环 while(!actr.apply(this, target)); 办法，不过好在 apply()这个办法根本不耗时。在转账这个例子中，毁坏循环期待条件就是老本最低的一个计划。

所以咱们在抉择具体计划的时候，还须要 评估一下操作老本，从中抉择一个老本最低的计划。

如果本文对你有帮忙的话，欢送点赞分享，这对我持续分享 & 创作优质文章十分重要。感激！

本文由 mdnice 多平台公布