图4 Chrome的一种异步执行的解决方案

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

1.锁少加了，导致两个线程同时修改一个变量；
2.锁多加了，轻则妨碍并发，重则导致死锁；
3.锁加错了，由于锁和需要锁的数据之间的联系，只存在于程序员的大脑中，这种事情太容易发生了；
4.加锁的顺序错了，维护锁的顺序是一件困难而又容易出错的问题；
5.错误恢复；
6.忘记唤醒和错误的重试；
7.而最根本的缺陷，是锁和条件变量不支持模块化的编程。比如一个转账业务中，A账户扣了100元钱，B账户增加了100元，即使这两个动作单独用锁保护维持其正确性，你也不能将两个操作简单的串在一起完成一个转账操作，你必须让它们的锁都暴露出来，重新设计一番。好好的两个函数，愣是不能组在一起用，这就是锁的最大悲哀；

通过这些缺点的描述，也就可以明白Chrome多线程模型的优点。它解决了锁的最根本缺陷，即，支持模块化的编程，你只需要维护对象和线程之间的职能关系即可，这个摊子，比之锁的那个烂摊子，要简化了太多。对于程序员来说，负担一瞬间从泰山降成了鸿毛。

而Chrome多线程模型的一个主要难点，在于线程与数据关系的设计上，你需要良好的划分各个线程的职责，如果有一个线程所管辖的数据，几乎占据了大半部分的Task，那么它就会从多线程沦为单线程，Task队列的锁也将成为一个大大的瓶颈。

设计者的职责
一个底层结构设计是否成功，这个设计者是否称职，我一直觉得是有一个很简单的衡量标准的。你不需要看这个设计人用了多少NB的技术，你只需要关心，他的设计，是否给其他开发人员带来了困难。一个NB的设计，是将所有困难都集中在底层搞定，把其他开发人员换成白痴都可以工作的那种；一个SB的设计，是自己弄了半天，只是为了给其他开发人员一个长达250条的注意事项，然后很NB的说，你们按照这个手册去开发，就不会有问题了。

从根本上来说，Chrome的线程模型解决的是并发中的用户体验问题而不是联合工作的问题（参见我前面喷的“闲话并发”），它不是和Map/Reduce那样将关注点放在数据和执行步骤的拆分上，而是放在线程和数据的对应关系上，这是和浏览器的工作环境相匹配的。设计总是和所处的环境相互依赖的，毕竟，在客户端，不会和服务器一样，存在超规模的并发处理任务，而只是需要尽可能的改善用户体验，从这个角度来说，Chrome的多线程模型，至少看上去很美。

Chrome源码剖析【二】—— 进程通信

【二】Chrome的进程间通信
1. Chrome进程通信的基本模式
进程间通信，叫做IPC（Inter-Process Communication）。Chrome最主要有三类进程，一类是Browser主进程，我们一直尊称它老人家为老大；还有一类是各个Render进程，前面也提过了；另外还有一类一直没说过，是Plugin进程，每一个插件，在Chrome中都是以进程的形式呈现，等到后面说插件的时候再提罢了。Render进程和Plugin进程都与老大保持进程间的通信，Render进程与Plugin进程之间也有彼此联系的通路，唯独是多个Render进程或多个Plugin进程直接，没有互相联系的途径，全靠老大协调。

进程与进程间通信，需要仰仗操作系统的特性，能玩的花着实不多，在Chrome中，用到的就是有名的管道（Named Pipe），只不过，它用一个IPC::Channel类，封装了具体的实现细节。Channel可以有两种工作模式，一种是Client，一种是Server，Server和Client分属两个进程，维系一个共同的管道名，Server负责创建该管道，Client会尝试连接该管道，然后双发往各自管道缓冲区中读写数据（在Chrome中，用的是二进制流，异步IO…），完成通信。

管道名字的协商
在Socket中，我们会事先约定好通信的端口，如果不按照这个端口进行访问，走错了门，会被直接乱棍打出门去的。与之类似，有名管道期望在两个进程间游走，就需要拿一个两个进程都能接受的进门暗号，这个就是有名管道的名字。在Chrome中（windows下…），有名管道的名字格式都是：\\.\pipe\chrome.ID。其中的ID，自然是要求独一无二，比如：进程ID.实例地址.随机数。通常，这个ID是由一个Process生成（往往是Browser Process），然后在创建另一个进程的时候，作为命令行参数传进去，从而完成名字的协商。

如果不了解并期待了解有关Windows下有名管道和信号量的知识，建议去看一些专业的书籍，比如圣经级别的《Windows核心编程》和《深入解析Windows操作系统》，当然也可以去查看SDK，你需要了解的API可能包括：CreateNamedPipe, CreateFile, ConnectNamedPipe, WaitForMultipleObjects, WaitForSingleObject, SetEvent, 等等。

Channel中，有三个比较关键的角色，一个是Message::Sender，一个是Channel::Listener，最后一个是MessageLoopForIO::Watcher。Channel本身派生自Sender和Watcher，身兼两角，而Listener是一个抽象类，具体由Channel的使用者来实现。顾名思义，Sender就是发送消息的接口，Listener就是处理接收到消息的具体实现，但这个Watcher是啥？如果你觉得Watcher这东西看上去很眼熟的话，我会激动的热泪盈眶的，没错，在前面（第一部分第一小节…）说消息循环的时候，从那个表中可以看到，IO线程（记住，在Chrome中，IO指的是网络IO，*_*）的循环会处理注册了的Watcher。其实Watcher很简单，可以视为一个信号量和一个带有OnObjectSignaled方法对象的对，当消息循环检测到信号量开启，它就会调用相应的OnObjectSignaled方法。

图5 Chrome的IPC处理流程图