《Java并发编程实战》课程笔记（四）

互斥锁

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

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

锁模型

在这里插入图片描述

首先，我们要把临界区要保护的资源标注出来，如图中临界区里增加了一个元素：受保护的资源 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) {// 临界区}}
}
```
- Java 编译器会在 synchronized 修饰的方法或代码块前后自动加上加锁 lock() 和解锁 unlock()。
- 这样做的好处就是加锁 lock() 和解锁 unlock() 一定是成对出现的，毕竟忘记解锁 unlock() 可是个致命的 Bug（意味着其他线程只能死等下去了）。
- 当修饰静态方法的时候，锁定的是当前类的 Class 对象，在上面的例子中就是 Class X；
- 当修饰非静态方法的时候，锁定的是当前实例对象 this。

锁和受保护资源的关系

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

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

例如，银行业务中有针对账户余额（余额是一种资源）的取款操作，也有针对账户密码（密码也是一种资源）的更改操作，我们可以为账户余额和账户密码分配不同的锁来解决并发问题，这个还是很简单的。
```
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;}}
}
```
- 账户类 Account 有两个成员变量，分别是账户余额 balance 和账户密码 password。
- 取款 withdraw() 和查看余额 getBalance() 操作会访问账户余额 balance，我们创建一个 final 对象 balLock 作为锁（类比球赛门票）；
- 更改密码 updatePassword() 和查看密码 getPassword() 操作会修改账户密码 password，我们创建一个 final 对象 pwLock 作为锁（类比电影票）。
- 不同的资源用不同的锁保护，各自管各自的，很简单。
- 用不同的锁对受保护资源进行精细化管理，能够提升性能。这种锁还有个名字，叫细粒度锁。

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

例如银行业务里面的转账操作，账户 A 减少 100 元，账户 B 增加 100 元。这两个账户就是有关联关系的。
```
class Account {private int balance;// 转账void transfer(Account target, int amt){if (this.balance > amt) {this.balance -= amt;target.balance += amt;}}
}
```
- 我们声明了个账户类：Account，该类有一个成员变量余额：balance，还有一个转账的方法：transfer()。
- 用同一把锁来保护多个资源，也就是现实世界的“包场”，那在编程领域应该怎么“包场”呢？很简单，只要我们的锁能覆盖所有受保护资源就可以了。
用 Account.class 作为共享的锁。
- Account.class 是所有 Account 对象共享的，而且这个对象是 Java 虚拟机在加载 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 作为互斥锁，锁定的范围太大，而我们锁定两个账户范围就小多了：

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

在这里插入图片描述

使用细粒度锁可以提高并行度，是性能优化的一个重要手段。使用细粒度锁是有代价的，这个代价就是可能会导致死锁。

死锁

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

如何预防死锁

并发程序一旦死锁，一般没有特别好的方法，很多时候我们只能重启应用。因此，解决死锁问题最好的办法还是规避死锁。
死锁的四个必要条件：
- 互斥，共享资源 X 和 Y 只能被一个线程占用；
- 占有且等待，线程 T1 已经取得共享资源 X，在等待共享资源 Y 的时候，不释放共享资源 X；
- 不可抢占，其他线程不能强行抢占线程 T1 占有的资源；
- 循环等待，线程 T1 等待线程 T2 占有的资源，线程 T2 等待线程 T1 占有的资源，就是循环等待。
也就是说只要我们破坏其中一个，就可以成功避免死锁的发生。
- 对于“占用且等待”这个条件，我们可以一次性申请所有的资源，这样就不存在等待了。
- 对于“不可抢占”这个条件，占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源，这样不可抢占这个条件就破坏掉了。
- 对于“循环等待”这个条件，可以靠按序申请资源来预防。所谓按序申请，是指资源是有线性顺序的，申请的时候可以先申请资源序号小的，再申请资源序号大的，这样线性化后自然就不存在循环了。

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

一个完整的等待-通知机制：线程首先获取互斥锁，当线程要求的条件不满足时，释放互斥锁，进入等待状态；当要求的条件满足时，通知等待的线程，重新获取互斥锁。

用 synchronized 实现等待-通知机制

在 Java 语言里，等待-通知机制可以有多种实现方式，比如 Java 语言内置的 synchronized 配合 wait()、notify()、notifyAll() 这三个方法就能轻松实现。
- 左边有一个等待队列，同一时刻，只允许一个线程进入synchronized 保护的临界区，当有一个线程进入临界区后，其他线程就只能进入图中左边的等待队列里等待。
- 这个等待队列和互斥锁是一对一的关系，每个互斥锁都有独立的等待队列。
- 线程在进入等待队列的同时，会释放持有的互斥锁，线程释放锁后，其他线程就有机会获得锁，并进入临界区了。
那线程要求的条件满足时，该怎么通知这个等待的线程呢？很简单，就是 Java 对象的 notify() 和 notifyAll() 方法。
- 当条件满足时调用 notify()，会通知等待队列（互斥锁的等待队列）中的线程，告诉它条件曾经满足过。
- 为什么说是曾经满足过呢？
  - 因为 notify() 只能保证在通知时间点，条件是满足的。而被通知线程的执行时间点和通知的时间点基本上不会重合，所以当线程执行的时候，很可能条件已经不满足了（保不齐有其他线程插队）。
  - 除此之外，还有一个需要注意的点，被通知的线程要想重新执行，仍然需要获取到互斥锁（因为曾经获取的锁在调用 wait() 时已经释放了）。