在 Java 中，锁好像是颗万能药，没什么问题是加锁解决不了的。的确，锁能解决绝大部分的并发问题。
然而，最简单的东西也往往最容易出现问题。你只要稍有不慎，不但 Bug 没有解决，还得花费大量的时间做各种排查。
既然如此，我们就来好好看看：为什么用了锁，程序还是出错了。
什么才是正确的锁模型
一说到锁，你的大脑中可能立马想起这个模型。
中间蓝色的一段代码，叫做：临界区。线程进入临界区前，先尝试加锁，如果成功，就进入临界区。此时，这个线程持有锁，等执行完临界区的代码后，持有锁的线程就会执行解锁。
同样的道理，如果加锁失败，线程就会一直等待，直到持有锁的线程解锁后，再重新尝试加锁。
这是锁的简易模型，看起来简单明了，但这个模型是错的，它忽略了最最重要的一点：锁与资源的关系。
你还记得吗？锁是为了实现互斥，即：在同一时刻，一个资源只能由一个线程操作。
换句话说，之所以要用锁，就是要保护某些资源。因此，锁与资源之间的关系，是重点中的重点。很多并发 Bug 就是忽略了这一点导致的。比如，你看下面这段代码：
class Account {
private int balance;
// 转账
synchronized void transfer(Account target, int amt){
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
}
}你可能会觉得，这段代码没问题呀？transfer() 方法不是加锁了吗？但在并发环境下，转账后，余额很可能对不上。原因也很简单，没考虑锁和资源的关系。
既然如此，那正确的锁模型是怎样的呢？
首先，我们要标注出受保护的资源 R；然后，为资源 R 创建一把锁 LR；最后，在进出临界区的时候，再加上加锁、解锁操作。
其中，锁 LR和受保护资源 R 之间有一条关联线，这非常重要，代表的是：锁与资源之间，是有对应关系的。
打个比方，你家的锁只能保护你家的东西，我家的锁只能保护我家的东西。这个关系要搞清楚，不然，就是锁自家的门来保护他家的东西。
可以说，我们平时对锁的理解都是错的。虽然这一般不会有什么问题，但只要出现问题，就是公司破产之类的大事。
比如，我前东家的支付系统，就是因为锁的问题，巨亏了几十万，负责人引咎辞职。在濒临倒闭之际，我接手了，这个项目才起死回生。
所以，如果你不想重蹈覆辙，而是想升职加薪。那必须要掌握正确的锁模型，千万不能忽略锁和资源的关系。
锁与资源的关系
你已经知道了，想要用好用锁，关键是搞清楚锁和资源的关系。那么，这两者的关系是怎样的呢？
资源和锁之间的关系是 N:1。
换句话说，你可以用一把锁，来保护多个资源。但是，你不能用多把锁，来保护一个资源。原因在于，如果你针对一个资源创建了多把锁，那么就达不到互斥的效果了。
打个比方，现实世界中，你可以用好几把锁，来保护你家的东西。但在编程世界中，你不能这样做。你看这个例子：
class SafeCalc {
private long value = 0L;
void addOne() {
synchronized (this) {
value += 1;
}
}
void addTwo() {
synchronized (SafeCalc.class) {
value += 2;
}
}
}你看下 addOne() 和 addTwo() 两个方法，它们分别用了两把锁 this 和 SafeCalc.class。虽然都是保护同一个资源，但临界区被拆成了 2 个，而这 2 个临界区是没有互斥关系的，这导致了并发问题。
那问题该怎么解决呢？
很简单，不要用多把锁来保护一个资源，你可以只用 this，又或者只用 SafeCalc.class。
当然，这个例子比较简单。在现实工作中，情况肯定更加复杂，我们要保护的资源不止一个，而是多个，这又该怎么处理呢？
如何保护多个资源
无论是单个资源，还是多个资源，关键都在于：锁要覆盖所有受保护的资源。
单个资源比较好理解，但如果要保护的资源不止一个，那我们首先要做的是，区分这些资源是否有关联，这分为两种情况。
第一，如何保护没有关联的多个资源，这和处理单个资源差不多。如果不考虑性能，你可以用一把锁来保护；如果想提高性能，你可以用不同的锁来保护。
你看下面的代码：
class Account {
// 余额
private Integer balance;
// 密码
private String password;
// 锁：保护余额
private final Object balLock = new Object();
// 锁：保护密码
private final Object pwLock = new Object();
// 取款
void withdraw(Integer amt) {
synchronized (balLock) {
if (this.balance > amt) {
this.balance -= amt;
}
}
}
// 更改密码
void updatePassword(String pw) {
synchronized (pwLock) {
this.password = pw;
}
}
}账户类-Account有两个方法：取款-withdraw()、更改密码-updatePassword()。从功能上看，这两个方法没什么关联。所以，为了提升性能，我用了两把锁，让它们各管各的。
当然，你也可以用一把锁来管理所有资源，就像下面这样：
class Account {
// 余额
private Integer balance;
// 密码
private String password;
// 取款
synchronized void withdraw(Integer amt) {
if (this.balance > amt) {
this.balance -= amt;
}
}
// 更改密码
synchronized void updatePassword(String pw) {
this.password = pw;
}
}在这里，我对性能没有要求，所以只要用 this 这一把锁，直接管理账户的所有资源。
第二，如何保护有关联的多个资源，这个问题就有点复杂了。
比如，银行的转账操作，不同的账户是有关联的，账户 A 如果减少 100 元，账户 B 就得增加 100 元。这时候，该怎么避免转账的并发问题呢？
你可能想到加锁，用 synchronized 关键词修饰一下，就像下面这样：
class Account {
// 余额
private Integer balance;
// 转账
synchronized void transfer(Account target, Integer amt) {
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
}
}一把锁可以保护多个资源，这看上去没问题。然而，却是错误的做法。
你想象一下这样的场景，A、B、C 三个账户的余额都是 100 元。这时候，有两笔转账操作：账户 A 转 100 元到账户 B，账户 B 转 100 元到账户 C。照理说，结果应该是：账户A-0元，账户B-100元，账户C-200元。
然而，如果是并发转账，最终的结果还有两种可能。一种是：账户A-0元，账户B-200元，账户C-200元；另一种是：账户A-0元，账户B-0元，账户C-200元。
简单来说，账户 B 的余额很可能是错的，问题就出在this这把锁上。
还记得吗？锁要覆盖所有受保护的资源。
在这个例子中，却没能做到这一点。临界区内有两个资源：this.balance、target.balance。但this这把锁只能保护this.balance，不能保护target.balance。
打个比方，你家的锁就算再厉害，也没法保护邻居家的东西吧？
因此，我们要找到一把锁，同时覆盖所有账号。
方案还是挺多的，最简单的一个就是：Account.class。Account.class 共享给所有 Account 对象。而且，Account.class 由 Java 虚拟机创建，具有唯一性。
这样一来，转账的并发问题就解决了，代码也特别简单。
class Account {
// 余额
private Integer balance;
// 转账
void transfer(Account target, Integer amt) {
synchronized (Account.class) {
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
}
}
}写在最后
在 Java 中，锁是解决并发的万能药，但我们却往往用不好，这是因为我们忽略了锁与资源的关系。
一般情况下，这不会有什么大问题。
然而，一旦出现多个资源，这些资源还相互关联，就很可能出现公司破产之类的大事。因此，你要时刻记住 3 点：
- 锁与资源有对应关系；
- 资源和锁之间的关系是 N:1；
- 锁要覆盖所有受保护的资源；
你只要检查好这三点，坏事就轮不到你头上。
