1

前言

上次我说过，我们这个线程的世界是个弱肉强食的地方，大家为了争抢资源大打出手，时不时闹出些内存数据互相被覆盖的事故，给人类带了无穷的烦恼。

后来线程元老院强势出手，发明了一种锁的机制， 这才制止了内乱。 从此以后我们要访问共享的资源（共享变量， 文件…)都得想办法先申请到一把锁才可以。

（码农君注： 关于锁的故事在《编程世界中的那把锁》有讲述）

2

互斥锁

虽说锁是个好东西， 但是我们线程日常使用的都是互斥锁， 所谓互斥，就是同一时刻只有获得锁的那个线程才有资格去操作共享资源， 别的线程都阻塞住了，被放到了一个叫锁池(Lock pool)的地方，什么事情都干不了。

比如说这个简单的Sequence类吧， 有100个线程拼命地挤破头去进入next()方法， 但由于synchronized的存在， 大家必须得获得一把锁才可以， 隔壁的小明运气不错， 获得了操作系统的垂青， 喜滋滋的得到了宝贵的锁， 进入了next()方法去做事了。

而我们剩下的99个线程大眼瞪小眼， 除了叹口气，感慨下人生之不如意十之八九， 还能干嘛？

老老实实地进入锁池里待着去吧！

等到隔壁小明做完了事情， 美滋滋的拿着最新的value值出来以后， 我们这99个在锁池里吹牛的线程一跃而起，去竞争那个刚刚被释放的锁。

但是下一个幸运儿是谁呢？ 不知道？

有时候人类为了公平，会搞个队列让我们排好队，先进先出。 但是我已经活了4.998秒，人生快走到了尽头， 在这么长的人生里， 我体会到的真理是： 公平实在是个稀缺货，不公平才是常态！

所以年轻人不要老是抱怨这个社会， 没用的， 还是老老实实的奋斗吧。

3

不要加锁？

平淡的日子就这么过着， 有一天线程世界来了一个年轻人，自称为小李, 他看着我们这么努力地奋斗着去争抢那把锁， 不由地嘲笑道： 你们真傻啊， 难道不知道不加锁也能做事吗？

我们愣了一下，人群中立刻发出一阵爆笑：哈哈哈， 这小子疯了，没有锁岂不又回到互相覆盖数据的日子了！

小李不甘示弱：你们这帮土老帽，把元老院的那帮老家伙的话当做圣旨， 岂不知天外有天， 人外有人， 这世界大得很呐！

这句话把我们镇住了， 我小心翼翼地问： 那你说说，不加锁怎么才能保证正确性呢？

“就拿你们的那个Sequence类来说吧， 不就是并发的更新内存中的一个值吗， 可以这么分为三步来做：

1. 从内存中读取value 值，假设为10， 我们把这个值称为A

2. B = A+1 得到 B = 11

3. 用A 和 内存的值相比， 如果相等(就是说在过去的一段时间，没人修改内存的值)， 那就把B的值(11)写入内存, 如果不相等(就是说过去的一段时间， 有人修改了内存value 的值)， 意味着A已经不是最新值了， 那就放弃这次修改， 跳回第1步去”

我们面面相觑， 就这么简单？ 真的没有加锁啊。

隔壁的小明反应最快： 小李子， 你这第三步有问题啊， 你看需要读内存吧，需要比较吧，还得写入内存吧， 这不是一个原子操作， 在我们多线程并发执行的时候， 肯定会出问题！

小李说： “唉， 说你们老土吧， 你们还不服气， 听说过comare and swap 这个硬件指令没有？ 那个第三步其实就是一条硬件指令，保证原子执行。 在单个CPU上就不用说了，如果是有多个CPU， 这个指令甚至会锁住总线， 确保同一时刻只有一个CPU能访问内存！

这样吧， 干脆写成个指令： compareAndSwap(内存的值, A , B) , 这下子明白了吧？ 还不明白？ 估计是人类的语言你们听起来不太明白， 来吧，给你们来点熟悉的代码：”

看到了我们熟悉的代码， 我的脑海飞速盘算：

假定我和小明都同时进入了这段代码， 都读到了内存的值A = 10 , 然后小明的时间片到了，只好退出CPU, 我则愉快的继续执行。

对于我来说 A = 10 , B = 11, 然后我运行compareAndSwap ,我发现我的A值和内存值是相等的，于是就把新的值B写入内存， 并且返回，退出next 函数， 收工回家。

等到小明再次被运行的时候， 由于他的初始值A也是10 ， 他也得到B = 11， 当他运行compareAndSwap 就发现A的值和内存不相等了（因为我改成了11） ， 那小明只好再次循环，获得A = 11, B = 12 , 再次调用compareAndSwap ， 如果还是被别人抢了先， 小明只好再次循环, 从内存获得A = 12 , B =13 …. 直到成功为止。

想到小明一直循环下去，累得要死的样子， 我”邪恶“地笑了。

我抬起头，正好和小明的目光相遇， 看到他不怀好意的样子， 估计也是把我置于无限循环的想象中了。

4

Java中的CAS

小李说： “Compare And Swap 这个词太长了， 以后简称CAS，希望你们听得懂。”

小明问道： “我们是Java 语言， 你那个读取内存的值该怎么办， 还有那个compareAndSwap 函数，我们实现不了啊？”

小李说：“你们Java 不是有JNI(Java native interface)吗？ 可以用C语言来实现， 然后在Java中封装一下不就得了？”

“看看这个AtomicInteger, 他就代表了那个内存的值， 那个count.compareAndSet方法只有两个参数， 实际上内存的值隐藏在了AtomicInteger当中，你们Java 不是喜欢面向对象嘛！”

我们仔细地审视这段代码， 它根本没有加锁， 每个人都可以进入next()方法， 读取数据，操作数据， 最后使用CAS来决定这次操作是否有效， 如果内存值被别人改过，那就再次循环尝试。

小李总结到： “你们之前的synchronized 叫做悲观锁， 元老院太悲观了，总是怕你们把事情搞砸，你看现在乐观一点儿， 不也玩的挺好嘛！ 每个线程都不用阻塞，不用在那个无聊的锁池里待着。 要知道，阻塞，激活是一笔不小的开销啊。”

5

CAS的扩展

使用非阻塞算法的线程越来越多， 小李趁热打铁，提供了一系列所谓Atomic的类：

AtomicBoolean

AtomicInteger

AtomicLong

AtomicIntegerArray

AtomicLongArray

这些工具类都很好用， 大家非常喜欢， 只是我们发现小李的这些工具类只支持简单的类型，对于一些复杂的数据结构，就不好使用CAS了，因为使用CAS需要频繁的读写内存数据，并且做数据的比较， 如果数据结构很复杂， 那读写内存是不可承受之重，还不如最早的悲观锁呢！

小李胸有成竹， 马上给出了改进： 不要比较数据啊， 只比较引用不就得了， 这里有一个AtomicReference, 拿去用吧。

我们向元老院做了推荐， 那些老家伙们可真是有两把刷子， 立刻提出了一个我做梦都没有想到的问题：

假设有两个线程， 线程1 读到内存的数值为 A , 然后时间片到期，撤出CPU。 线程2运行，线程2 也读到了A , 把它改成了B， 然后又把B改成原来的值A , 简单点说，修改的次序是 A – B -A 。 然后线程1开始运行， 它发现内存的值还是A , 完全不知道内存中已经被操作过。

(码农君注： 这就是著名的ABA问题)

我想了一下， 好像没什么啊，不就是把数字改成了原来的值吗？也没什么影响。

可是小李却陷入了沉思， 看来这是一个挺难的问题， 他口中念念有词： 如果只是简单的数字，那没什么， 可是如果使用AtomicReference， 并且操作的是复杂的数据结构，就可能会出问题了。对了， 我可以用一个版本号来处理啊， 给每个放入AtomicReference的对象都加入一个version, 这样以来尽管值相同， 也能区分开了！ 嗯， 我就叫他AtomicStampedReference 吧。

元老院很满意， 但是还是发了一个公告：

鉴于最近使用AtomicXXXX的线程越来越多， 元老院有责任提醒各位， 用这些类实现非阻塞算法是非常容易出错的，在你自己实现之前， 看看元老院有没有提供现成的类，例如： ConcurrentLinkedQueue。 如果非要自己写，也得提交给元老院审查通过才可以使用。

6

后记： Doug Lea

如果说要从Java 世界中找一个并发编程的大牛， 我想这个人非Doug Lea莫属， 从JDK 1.5开始， Java 引入了一个非常著名的线程并发库java.util.concurrent ， 由于其良好的抽象， 这个库极大的降低了并发编程的难度， 其作者就是并发编程的权威Doug Lea， 他是纽约州立大学Oswego分校计算机科学系教授， JCP（Java Community Process）执行委员会成员，JSR166（并发编程）的主席 ， 文中的小李就是向Doug Lea致敬。