旺财和小强的三生三世
旺财和小强是线程池的两个线程， 他们经常做的工作就是对一个数加加减减，用人类的话来说就是存款，取款。
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虚拟机并发编程》， 感兴趣的同学可以看一看。