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吧。
【本文为51CTO专栏作者“刘欣”的原创稿件，转载请通过作者微信公众号coderising获取授权】
