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：将写锁还原为读锁。
?
下面就实现一个写操作，三个读操作，要知道这三个读操作是并发的。
