旺财和小强的三生三世

 ***世

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

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的局限性， 如果对于同一个数据，并发写入很多的时候，冲突就大大增加了，不断地重复执行，效率很低。所以更适合写入少，读取多的场景。”

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

【本文为51CTO专栏作者“刘欣”的原创稿件，转载请通过作者微信公众号coderising获取授权】

 

戳这里，看该作者更多好文