第一世

旺财和小强是线程池的两个线程， 他们经常做的工作就是对一个数加加减减，用人类的话来说就是存款，取款。

public class Account{private int balance;public synchronized void deposit(int amt){balance += amt;}public synchronized void withdraw(int amt){if(balance >= amt){balance -= amt;}throw new RuntimeException("insufficent blance");}
}

（友情提示，可左右滑动，下同）

每次进行存款，取款操作的时候，他们两个都需要获得一把锁，这样就能保证同一时刻只有一个人在修改，不会出乱子。

这一天，他们俩又遇到了一个叫做转账的操作：

public void transfer(Account from,Account to, int amt){synchronized(from){synchronized(to){from.withdraw(amt);to.deposit(amt);}}
}

旺财说：“这个程序员不错，考虑得挺周全。转账的时候把两个账户都锁住了，安全！”

小强说：“没错，执行吧。”

旺财这个线程从A向B转账 ， 与此同时，小强从B向A转账

令旺财和小强没有想到的是，居然出现了死锁。

类似的事件发生不少， 线程池的线程用光了，Tomcat被迫重启，这个世界毁灭了。

第二世

新生代的旺财和小强从线程池中出来， Tomcat老大给他们讲了上一代旺财和小强的故事， 对他们谆谆教导：“做转账操作的时候一定要小心，别死锁了！”

旺财和小强有点儿愤愤不平：“这我们俩也控制不了啊，这要看程序员写的代码，以及操作系统中的线程调度啊！”

不满归不满，他俩还是有点小期待，想看看可怕的转账代码到底怎么样。

没过多久， 他俩就如愿了：

public static final Object lock = new Object();
public void transfer(Account from,Account to, int amt){int fromHash = System.identityHashCode(from);int toHash = System.identityHashCode(to);if(fromHash > toHash){synchronized(from){synchronized(to){from.withdraw(amt);to.deposit(amt);}}}else if(toHash > fromHash){synchronized(to){synchronized(from){from.withdraw(amt);to.deposit(amt);}}}else {synchronized(lock){synchronized(from){synchronized(to){from.withdraw(amt);to.deposit(amt);}}}}
}

看到这样的代码， 旺财倒吸了一口气，挠着头说：“搞什么鬼，转个账都这么麻烦！”

小强说：“老大不是说了吗，上一代线程老是在转账这里出错，于是代码就重写了。你看，这一次写得就很严谨了，每一次都会去比较两个账户的大小（通过hash code），谁大就先获得谁的锁。 ”

旺财说：“奥，相当于把账户给排了序，假设账户A大于账户B ， 那我们俩转账的时候，每次都先获得A的锁，这样就不会互相等待了。 ”

“没错，还有一个特殊情况，如果这两个账户的hash code 相同，那就再去竞争另外一个特殊的锁，谁抢到谁就可以先执行。另一个就在那里等待。”

旺财和小强这次顺利地把转账给执行完了，回去给Tomcat汇报了一遍。

Tomcat老大感慨地说：“有这么复杂的代码，可见使用‘共享内存’的方式来并发编程很不容易啊！”

“共享内存？”

“对啊，你看这些账户的数据，每个线程都可以访问，不就是共享内存吗， 为了能够安全访问，只有来‘加锁’了。 古人说，这个世界上有两种构建软件的方式，一种方法是使其足够简单以至于不存在明显的缺陷，另外一种是使其足够复杂以至于看不出有什么问题。 我很担心啊， 现在这个系统就属于第二种，不知道有多少坑在等着我们呢！”

（码农翻身： 实际上这句话是托尼·霍尔说的）

老大不幸言中，终于有一天，这个复杂到看不出问题的系统崩溃了，这个世界又毁灭了。

第三世

第三代的旺财和小强从线程池出来。

出发前，Tomcat老大把前两代线程遇到的问题给他们说了一遍，威胁说：如果再出现死锁，小心你们两个的脑袋！

旺财和小强战战兢兢，如履薄冰地执行代码。

最终他们还是遇到了传说中的可怕的转账代码：

def transfer(from: Account, to: Account,amt:Int){atomic{from.withdraw(amt);to.deposit(amt);}
}

旺财非常吃惊：“这是什么代码？不是Java？”

小强说：“嗯，不是Java ，是Scala写的，这是运行在JVM上的一个语言。”

（码农翻身注：实际上JVM线程能看到的只是Java 字节码，根本看不到源码，也就不知道是Java写的代码，还是Scala写的代码， 这里只是为了展示方便。）

旺财说：“怎么这么简单，会不会出问题？那个atomic是怎么回事？表示原子执行？”

小强也有点懵，不敢贸然去执行：“咱们还是去问Tomcat老大吧。”

Tomcat看了一眼：“人类程序员又改代码了啊，开始使用Software Transaction Memory（STM）了。 去把STM老头儿叫来，让他给你俩解释。”

STM老头儿满脸沧桑：“放心执行吧，只要你把代码放到atomic中，我就能保证他们像事务一样，实现ACID，哦不，D(持久化)实现不了，这些数据都是在内存中的。”

“这有什么用？ ”

“可以让你们俩安全地并发执行啊？”

旺财和小强面面相觑，这连锁都没有，还安全地并发？

“别看没有锁，” STM老头儿说，“在atomic代码开始执行的时候，我会记录下代码块涉及到的数据的值（复制了一份），然后才真正执行，执行完了要‘提交’， 这时候我会看看那些数据的值是否也被别的线程改动了，如果有改动，那本次改动就撤销，重新从代码开始处执行。 ”

老头儿画了一个图，展示旺财从账户A给账户B转20元， 与此同时小强从B向A转30元。

还真是，没有加锁就安全地完成了两个并发操作。

当然，老头儿为了实现这个atomic操作，背后偷偷做了不少事情：复制数据，提交，重复执行。

旺财想起来自己曾经执行过一下Java 的Compare and swap的代码，说道：“你这不就是CAS嘛！”

老头儿说：“原理上类似，都是乐观锁，不过我这个方式和数据库的事务更加类似，所以叫做Software Transaction Memory。”

小强想了想，说道：“不对啊，atomic是个代码块，里边可能有很多代码，涉及到很多class， 你怎么知道哪些字段需要被STM管理起来啊！”

STM老头儿说：“这真是个好问题，实际上，需要程序员们来告诉我。比如使用这个方法”

class Account(val initialBalance : Int){val balance = Ref(initialBalance)......
}

“看到那个Ref没有，这就是一种办法，通过它，我就知道这个balance的字段需要让我管理起来，在atomic代码块运行的时候，就需要复制它的值，比较它的值。”

“明白了，但是‘重复执行’有问题啊，假设程序员张大胖是这么写代码的：”

def transfer(from: Account, to: Account,amt:Int){atomic{from.withdraw(amt);...在这里执行一些其他操作，例如打印日志，发送邮件.....to.deposit(amt);}
}

“这其中有一些打印日志，发送邮件的操作，那你重复执行，岂不会执行很多次，就完全乱套了。”

STM老头儿说：“不错，想得挺深，你说的这些操作，我把他们叫做副作用，不能重复执行，不能放到atomic代码块中让STM管理。换句话说atomic中的代码应该是幂等的。如果违背了这一点，后果自负！”

小强心中一凛：“这是程序员要操心的事情了，不管我俩的事情， 不过即使如此，他们的代码也极度地简化了，只需要用个atomic，就能实现安全地并发，实在是太爽了。”

旺财说道：“你说得天花乱坠，这STM有什么缺点？”

老头儿说：“天下没有免费的午餐，很容易想到STM的局限性， 如果对于同一个数据，并发写入很多的时候，冲突就大大增加了，不断地重复执行，效率很低。所以更适合写入少，读取多的场景。”

“好吧，我们这就执行这个转账操作，有问题就找你！”

后记： 本文的例子来源于两本书：《Java 并发编程实践》和《Java虚拟机并发编程》， 感兴趣的同学可以看一看。

往期精彩回顾

关于老刘和码农翻身

我是一个线程

我是一个Java Class

面向对象圣经

TCP/IP之大明邮差

CPU阿甘

我是一个网卡

我是一个路由器

一个故事讲完HTTPs

编程语言的巅峰

Java：一个帝国的诞生

JavaScript：一个屌丝的逆袭