读Chrome源码剖析

chrome就不用给大家介绍了，前几天读一位兄台对他源码剖析的文章，自己也就拿来看了些，实在是水平有限，没有深入进去。

只能说按自己的理解和兄台的文章，说说自己的感受了，在chrome真正让我有所感悟的是他的多线程的处理，很长一段时间来，自己在写多线程的程序，后来把代码的维护工作交给了另外的同事，结果程序经常出现死锁现象，俺不得不又去看看，并提出了一些注意点，再后来随着系统通信量的增加，锁带来的弊端开始显现，随着数据量规模的上升及应用的增多，程序越来越慢。

chrome带来的多线程编程的思路给我了一个思路，可惜的是原来的程序太复杂，但终究有了一个重构的思路。

在兄台的文章中有这么一段，摘录在此与大家共享：

一直在说Chrome在规避锁的问题，那到底锁是哪里不好，犯了何等滔天罪责，落得如此人见人嫌恨不得先杀而后快的境地。《代码之美》的第二十四章“美丽的并发”中，Haskell设计人之一的Simon Peyton Jones总结了一下用锁的困难之处，我罚抄一遍，如下：

1.       锁少加了，导致两个线程同时修改一个变量；

2.       锁多加了，轻则妨碍并发，重则导致死锁；

3.       锁加错了，由于锁和需要锁的数据之间的联系，只存在于程序员的大脑中，这种事情太容易发生了；

4.       加锁的顺序错了，维护锁的顺序是一件困难而又容易出错的问题；

5.       错误恢复；

6.       忘记唤醒和错误的重试；

7.  而最根本的缺陷，是锁和条件变量不支持模块化的编程。比如一个转账业务中，A账户扣了100元钱，B账户增加了100元，即使这两个动作单独用锁保护维持其正确性，你也不能将两个操作简单的串在一起完成一个转账操作，你必须让它们的锁都暴露出来，重新设计一番。好好的两个函数，愣是不能组在一起用，这就是锁的最大悲哀；