5天不再惧怕多线程——第二天 锁机制

?当多个线程在并发的时候，难免会碰到相互冲突的事情，比如最经典的ATM机的问题，并发不可怕，可怕的是我们没有能力控制。

线程以我的理解可以分为三种

① 锁。

② 互斥。

③ 信号。

? 好，这一篇主要整理“锁”，C#提供了2种手工控制的锁

一: ?Monitor类

? ? ?这个算是实现锁机制的纯正类，在锁定的临界区中只允许让一个线程访问，其他线程排队等待。主要整理为2组方法。

?

1：Monitor.Enter和Monitor.Exit

? ? ? ? ?微软很照护我们，给了我们语法糖Lock,对的，语言糖确实减少了我们不必要的劳动并且让代码更可观，但是如果我们要精细的

? ? ?控制，则必须使用原生类，这里要注意一个问题就是“锁住什么”的问题，一般情况下我们锁住的都是静态对象，我们知道静态对象

? ? ?属于类级别，当有很多线程共同访问的时候，那个静态对象对多个线程来说是一个，不像实例字段会被认为是多个。

?

不加锁的情况：

?

加锁的情况：

?

2：Monitor.Wait和Monitor.Pulse

?首先这两个方法是成对出现，通常使用在Enter，Exit之间。

?Wait： 暂时的释放资源锁，然后该线程进入”等待队列“中，那么自然别的线程就能获取到资源锁。

?Pulse: ?唤醒“等待队列”中的线程，那么当时被Wait的线程就重新获取到了锁。

?

这里我们是否注意到了两点：

① ? 可能A线程进入到临界区后，需要B线程做一些初始化操作，然后A线程继续干剩下的事情。

② ? 用上面的两个方法，我们可以实现线程间的彼此通信。

?

下面举个例子来模拟两个人的对话。

?

二：ReaderWriterLock类

? ? 先前也知道，Monitor实现的是在读写两种情况的临界区中只可以让一个线程访问，那么如果业务中存在”读取密集型“操作，就

好比数据库一样，读取的操作永远比写入的操作多。针对这种情况，我们使用Monitor的话很吃亏，不过没关系，ReadWriterLock

就很牛X，因为实现了”写入串行“，”读取并行“。

ReaderWriteLock中主要用3组方法：

<1> ?AcquireWriterLock: 获取写入锁。

? ? ? ? ? ReleaseWriterLock：释放写入锁。

<2> ?AcquireReaderLock: 获取读锁。

? ? ? ? ??ReleaseReaderLock：释放读锁。

<3> ?UpgradeToWriterLock:将读锁转为写锁。

? ? ? ? ?DowngradeFromWriterLock：将写锁还原为读锁。

?

下面就实现一个写操作，三个读操作，要知道这三个读操作是并发的。