• 三生三世 十里加锁
  • 发布于 2个月前
  • 96 热度
    0 评论
  • Zoker
  • 0 粉丝 5 篇博客
  •   

第一世

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

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

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

用户评论