编程世界的那把锁

1共享变量惹得祸

我们这里是个典型的弱肉强食的世界，人口多而资源少，为了争抢有限的资源，大家都在自己能运行的CPU时间片里拼了老命，经常为了一个变量的修改而打的头破血流。

100纳秒以前，我有幸占据了CPU,从内存中读取了一个变量x == 100, 我把它加了1， 休息了一会儿后我打算把它写回内存， 但是惊奇的发现： 内存中的x 已经变成102了。

估计是哪个不着调的线程在我休息的时候也读取并且修改了x， 有不少好心的线程在冲我喊：不要写回了！ 但是写回内存是我的指令啊， 你不让我执行，难道让我退出？ 我只能毫不客气的把101写入内存， 把那个不符合我逻辑的值102给覆盖掉， 这样我才能执行下一条指令。

你看，单线程的逻辑正确并不表示多线程并发运行时的逻辑也能正确。

这样的事情发生的多了，程序总是无法正确运行， 引起了人类的强烈不满，小道消息说他们在考虑kill掉我们， 换编程语言了。

但是换编程语言有什么用，只要有共享变量，多线程读写的时候就是会出现不一致啊。

除非你消除共享变量，让每个线程只访问一个函数内的局部变量， 这些局部变量我们每个线程都会有一份， 函数结束以后就会销毁，所以线程之间就隔离了，就安全了。

消除共享变量谈何容易， 人类使用的很多语言例如C++, Java，那些共享变量大多数一个对象的字段， 你想把字段去掉， 只留下函数， 那类也没有存在的必要了， 就类似于函数式编程了， 一切都是函数。 有时候我挺羡慕函数式的世界， 那种无状态应该是一种非常美妙的感觉吧。

2争抢吧，线程

既然共享变量是无法消除的，那就想想别的办法吧， 线程元老院的那帮家伙们哼哧了半天，终于公布了一个方案： 加锁！

任何线程，只要你想操作一个共享变量，对不起， 先去申请一把锁， 拿到这把锁才能读取x的值 ， 修改x的值， 把x写回内存， 最后释放锁，让别人去玩。

元老院设计的这把锁非常简单， 类似于一个boolean 变量， boolean lock = false. 谁能抢先把这个变量改成true, 就意味着获取了这把锁。

来吧，哥几个，快来抢吧 ！

我运行的时候， 就去检查lock这个变量是否可以设置为true, 如果被别的家伙给抢到了（已经变成true了）， 我就在这里无限循环，拼命的抢， 除非我的时间片到了，被迫让出CPU, 但是我不会阻塞， 还是就绪状态，等待下一次的调度， 进入CPU继续抢。

看到某人把它变成false, 我眼疾手快迅速出手， 终于抢到了，赶紧把lock改成true, 这把锁现在属于我了， 赶快去干活，干完活要记住把lock 改成false, 让别的家伙们去抢。

我想正是由于这种无限循环的特点， 元老院把他命名为“自旋锁”吧！

列位看官，可能你已经想到了， 假设有两个线程，都读到了lock == false, 都把lock 改成true, 那这个锁算谁的？

这个问题元老院的大佬们早就考虑到了， 他们和操作系统（我听说还有硬件）都商量好了， 这个检测lock是否为false, 以及设置lock 为true 的操作 其实被合并了， 叫做test_and_set(lock), 操作系统郑重承诺，这是一个不可分割的原子操作， 在这个test_and_set执行的时候，总线都被锁住了， 别人不能访问内存， 即使有多个CPU在执行也不会乱掉。

如果你感兴趣，可以看看下面的实现， 否则直接无视跳过:

3改进

有了自旋锁， 至少可以保证程序的正确运行了， 我们大家都玩的不亦乐乎。

有一天我遇到了一个递归函数， 我是挺喜欢递归的， 因为逻辑简单， 只要递归的层次别太深， 别搞出栈溢出就好。

这个递归函数中需要获得自旋锁，做点事情， 然后继续调用自己， 类似于这样：

我第一次调用doSomething, 获取了自旋锁， 然后第二次调用doSomething, 还要获取自旋锁， 可是这个锁已经在我第一次调用的时候持有了， 现在第二次调用只有无限的等待了！

这下尴尬了， 我进退不得， 自己把自己搞成了死锁！

看来这个自旋锁虽然能实现互斥的访问， 但是不能重新进入同一个函数（简称不可重入）啊！

我赶紧把这个问题向元老院做了汇报， 修改方案很快就下来了： 每次成功的申请锁以后，要记录下到底是谁申请的， 还要用一个计数器记录重入的次数， 下一次持有锁的家伙再次申请锁只是给计数器加一而已。

释放的时候也是一样， 把计数器减一， 如果等于0了才真正的释放锁。

可重入性就这么解决了， 但是这么多线程都在那里拼命的抢也不是办法， 空耗CPU也是巨大的浪费啊。

于是元老院又发布了新的锁 ReentrantLock， 这个锁可以重入，如果你抢不到， 不要无限循环了， 乖乖的到等待队列里待着去， 等到锁被别人释放了再通知你去抢。

(在Java 中最初是synchronzied关键字，可以用在一个方法上或者一个代码块上， 后来又改进为更加灵活的ReentrantLock)

很快就有线程还抱怨说， 明明是我先发出获得锁的申请啊， 为什么隔壁老王却先拿到了锁？ 这不公平啊，不行，以后得排队， 先来先得。 好吧， 只好加上一个是否公平的参数。

还有线程说， 我是个急性子，申请锁的时候只想等待5秒钟， 5秒之内得不到锁我就放弃了， 能不能支持？ 那就再加上一个参数：等待时间。

4发扬光大

体会到锁带来的甜头以后， 各种各样样的需求纷至沓来：

1. 有时候需要多个线程都获得同一把锁，去做一件事情，那怎么办呢？

没关系，信号量（Semaphore）出马，创建信号量的时候得指定一个整数(例如10)， 表明同一时刻最多有10个线程可以获得锁：

Semaphore lock= new Semaphore(10);

当然每个线程都需要调用lock.aquire(), lock.release()去申请/释放锁。

2. 一个线程要写共享变量， 可是还有几个线程要同时读， 怎么办？ 你写的时候可以锁住， 但总不能读的时候也只允许一个线程吧？

只好来一个读写锁了ReadWriteLock， 为了保证可重入性， 元老院体贴的实现了ReentrantReadWriteLock。

3. 一个线程需要等待其他多个线程完工以后才能干活，怎么办？

CountDownLatch前来救驾， 搞一个计数器，某个线程干完了就把计数器减去1， 如果计数器为0了，那个一直耐心等待的线程就可以开始了。

4. 还有几个线程必须互相等待， 就像100米赛跑那样， 所有人都准备好了才能开闸放水， 不，是起跑， 就那就赏你一个CyclicBarrier吧。