并发编程学习(4) —— 互斥锁如何保护多个资源

快来打我* 2022-03-06 11:48 240阅读 0赞

## 前言 ##

锁能够广泛地被应用，是因为**一把锁能够保护多个资源，锁与资源的关系为1:N**，当我们需要保护多个资源时，最需要判定的是这些资源间有没有关联。

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

就像电影院的座位和足球场的座位是完全没有关联的，因此用电影院门票（锁）来管理电影院座位，用足球比赛门票（锁）来管理比赛座位，各自管各自，通过不同的锁来对资源进行管理。那么，在下面的代码中体现一下这种想法：

public class Ticket { 
        private Integer mTicket = 500; // 电影票数量
        private Integer rTicket = 500; // 足球门票数量
        private final Object movieTicket = new Object(); // 电影票
        private final Object footballTicket = new Object(); // 足球门票
    
        // 查看电影票余量
        Integer getMoviceCount(){ 
            synchronized (movieTicket){ 
                return mTicket;
            }
        }
    
        // 购买电影票
        void getMovieTicket(){ 
            synchronized (movieTicket){ 
                mTicket -= 1;
            }
        }
    
        // 查看足球门票数量
        Integer getFootballCount(){ 
            synchronized (footballTicket){ 
                return rTicket;
            }
        }
        
        // 购买足球门票
        void getFootballTicket(){ 
            synchronized (footballTicket){ 
                rTicket -= 1;
            }
        }
    }

可以看到，对于足球门票和电影票这些不相关的资源，我们用不同的锁进行管理。**用不同的锁对受保护资源进行精细化的管理，这种锁就叫做细粒度锁**。为什么不能用同一把锁对电影票和足球门票进行统一管理？我相信你也肯定会想到，就是性能问题，如果用细粒度锁，足球门票和电影票的操作就能并行。

## 保护有关联的资源 ##

银行业务中，在转账业务中会出现A账户转出100元，B账户转入100元，B账户转出100元，C账户转入100元。A、B、C这三个账户是有关联关系的，那么，对于这些有关联关系的资源我们应该怎么设计锁？这里定义一个Account类，这个类有个成员变量余额：balance，一个转账方法：transfer，以下为代码：

public class Account { 
        private int balance; // 余额
        
        // 转账
        void transfer(Account account, int money){ 
            if(this.balance > money){ 
                account.balance += money;
                this.balance -= money;
            }
        }
    }

那么如何保证这个操作没有并发问题？如果直接用synchronized来修饰transfer方法是错误的：

synchronized void transfer(Account account, int money){ 
            if(this.balance > money){ 
                account.balance += money;
                this.balance -= money;
            }
        }

synchronized void transfer的实际意思是synchronized(this) void transfer，this这把锁只能保护自己的balance而不能保护其他的balance，简单来说你不能够用自己的锁来把别人的财产也保护起来，自己的锁只能保护自己的财产。那么该如何操作？下面用以上的A、B、C三个账号来举例子。

假设A、B、C三个账号各有200元，A账户转给B账户100元，B账户转给C账户100元，最终结果是A有100元、B有200原、C有300元。如果用以上直接用synchronized来修饰transfer方法的话，会出现什么后果？如果有两个线程同时执行，线程1执行A转B的操作，线程2执行B转C的操作，它们读到的B余额都是200元。如果线程1执行的比线程2快，那么线程1写入的结果就会被线程2的结果覆盖，最终结果为B的余额是100元，如果线程1比线程2慢，结果B的余额为300元。这实际上就不是互斥了。

## 最佳办法 ##

为了能够实现真正的互斥，我们可以使用Account.class这个class对象来进行“包场”，所谓的包场就是**锁能覆盖所有受保护资源**。好比电影院，当你包场后，其他人不能进入电影院，更不能使用电影院的资源，只有当你用完才能轮到下一个人用。回到转账这个例子来说，当线程1正在执行A转帐给B时，其他线程只能够等待到线程1执行完才能执行转账操作，以下是代码的实现：

void transfer(Account account, int money){ 
            synchronized(Account.class){ 
                if(this.balance > money){ 
                    account.balance += money;
                    this.balance -= money;
                }
            }
        }

## 结尾 ##

有时候包场并不一定是最好的方法，因为如果当业务量太过庞大，那么效率就非常低下，上面最佳办法只能够应对一些场景，如果想要更好地提高性能，那么就需要继续优化。