【一】 Chrome的多线程模型
0. Chrome的并发模型
如果你仔细看了前面的图，对Chrome的线程和进程框架应该有了个基本的了解。Chrome有一个主进程，称为Browser进程，它是老大，管理 Chrome大部分的日常事务；其次，会有很多Renderer进程，它们圈地而治，各管理一组站点的显示和通信（Chrome在宣传中一直宣称一个 tab对应一个进程，其实是很不确切的…），它们彼此互不搭理，只和老大说话，由老大负责权衡各方利益。它们和老大说话的渠道，称做 IPC（Inter-Process Communication），这是Google搭的一套进程间通信的机制，基本的实现后面自会分解。。。
|
不论是Browser进程还是Renderer 进程，都不只是光杆司令，它们都有一系列的线程为自己打理各种业务。对于Renderer进程，它们通常有两个线程，一个是Main thread，它负责与老大进行联系，有一些幕后黑手的意思；另一个是Render thread，它们负责页面的渲染和交互，一看就知道是这个帮派的门脸级人物。相比之下，Browser进程既然是老大，小弟自然要多一些，除了大脑般的 Main thread，和负责与各Renderer帮派通信的IO thread，其实还包括负责管文件的file thread，负责管数据库的db thread等等（一个更详细的列表，参见这里），它们各尽其责，齐心协力为老大打拼。它们和各Renderer进程的之间的关系不一样，同一个进程内的线程，往往需要很多的协同工作，这一坨线程间的并发管理，是Chrome最出彩的地方之一了。。。
|
1. Chrome的线程模型
仔细回忆一下我们大部分时候是怎么来用线程的， 在我足够贫瘠的多线程经历中，往往都是这样用的：起一个线程，传入一个特定的入口函数，看一下这个函数是否是有副作用的（Side Effect），如果有，并且还会涉及到多线程的数据访问，仔细排查，在可疑地点上锁伺候。。。
Chrome的线程模型走的是另一个路子，即，极力规避锁的存在。 换更精确的描述方式来说，Chrome的线程模型，将锁限制了极小的范围内（仅仅在将Task放入消息队列的时候才存在…），并且使得上层完全不需要 关心锁的问题（当然，前提是遵循它的编程模型，将函数用Task封装并发送到合适的线程去执行…），大大简化了开发的逻辑。。。
不过，从实现来说，Chrome的线程模型并没有什么神秘的地方（美女嘛，都是穿衣服比不穿衣服更有盼头…），它用到了消息循环的手段。每一个Chrome的线程，入口函数都差不多，都是启动一个消息循环（参见MessagePump类），等待并执行任务。而其中，唯一的差别在于，根据线程处理事务类别的不同，所起的消息循环有所不同。比如处理进程间通信的线程（注意，在Chrome中，这类线程都叫做IO线程，估计是当初设计的时候谁的脑门子拍错了…）启用的是MessagePumpForIO类，处理UI的线程用的是MessagePumpForUI类，一般的线程用到的是MessagePumpDefault类 （只讨论windows, windows, windows…）。不同的消息循环类，主要差异有两个，一是消息循环中需要处理什么样的消息和任务，第二个是循环流程（比如是死循环还是阻塞在某信 号量上…）。下图是一个完整版的Chrome消息循环图，包含处理Windows的消息，处理各种Task（Task是什么，稍后揭晓，敬请期 待…），处理各个信号量观察者（Watcher），然后阻塞在某个信号量上等待唤醒。。。
 |
| 图2 Chrome的消息循环 |
当然，不是每一个消息循环类都需要跑那么一大圈的，有些线程，它不会涉及到那么多的事情和逻辑，白白浪费体力和时间，实在是不可饶恕的。因此，在实现中，不同的MessagePump类，实现是有所不同的，详见下表：
| MessagePumpDefault | MessagePumpForIO | MessagePumpForUI | |
| 是否需要处理系统消息 | 否 | 是 | 是 |
| 是否需要处理Task | 是 | 是 | 是 |
| 是否需要处理Watcher | 否 | 是 | 否 |
| 是否阻塞在信号量上 | 否 | 是 | 是 |
2. Chrome中的Task
从上面的表不难看出，不论是哪一种消息循环，必须处理的，就是Task（暂且遗忘掉系统消息的处理和Watcher，以后，我们会缅怀它们的…）。刨去其它东西的干扰，只留下Task的话，我们可以这样认为：Chrome中的线程从实现层面来看没有任何区别，它的区别只存在于职责层面，不同职责的线程，会处理不同的Task。最后，在铺天盖地西红柿来临之前，我说一下啥是Task。。。
简单的看，Task就是一个类，一个包含了 void Run()抽象方法的类（参见Task类…）。一个真实的任务，可以派生Task类，并实现其Run方法。每个MessagePump类中，会有一个 MessagePump::Delegate的类的对象（MessagePump::Delegate的一个实现，请参见MessageLoop 类…），在这个对象中，会维护若干个Task的队列。当你期望，你的一个逻辑在某个线程内执行的时候，你可以派生一个Task，把你的逻辑封装在 Run方法中，然后实例一个对象，调用期望线程中的PostTask方法，将该Task对象放入到其Task队列中去，等待执行。我知道很多人已经抄起了 板砖，因为这种手法实在是太常见了，就不是一个简单的依赖倒置，在线程池，Undo\Redo等模块的实现中，用的太多了。。。
但，我想说的是，虽说谁家过年都是吃顿饺子，这饺子好不好吃还是得看手艺，不能一概而论。在Chrome中，线程模型是统一且唯一的，这就相当于有了一套标准，它需要满足在各个线程上执行的几十上百种任务的需求，因此，必须在灵活行和易用性上有良好的表现，这就是设计标准的难度。为了满足这些需求，Chrome在底层库上做了足够的功夫：
- 它提供了一大套的模板封装（参见task.h），可以将Task摆脱继承结构、函数名、函数参数等限制（就是基于模板的伪function实现，想要更深入了解，建议直接看鼻祖《Modern C++》和它的Loki库…）；
- 同时派生出CancelableTask、ReleaseTask、DeleteTask等子类，提供更为良好的默认实现；
- 在消息循环中，按逻辑的不同，将Task又分成即时处理的Task、延时处理的Task、Idle时处理的Task，满足不同场景的需求；
- Task派生自tracked_objects::Tracked，Tracked是为了实现多线程环境下的日志记录、统计等功能，使得Task天生就有良好的可调试性和可统计性；
这一套七荤八素的都搭建完，这才算是一个完整的Task模型，由此可知，这饺子，做的还是很费功夫的。。。
3. Chrome的多线程模型
工欲善其事，必先利其器。Chrome之所以费了老鼻子劲去磨底层框架这把刀，就是为了面对多线程这坨怪兽的时候杀的更顺畅一些。在Chrome的多线程模型下，加锁这个事情只发生在将Task放入某线程的任务队列中，其他对任何数据的操作都不需要加锁。当然，天下没有免费的午餐，为了合理传递Task，你需要了解每一个数据对象所管辖的线程，不过这个事情，与纷繁的加锁相比，真是小儿科了不知道多少倍。。。
 |
| 图3 Task的执行模型 |
如果你熟悉设计模式，你会发现这是一个Command模式， 将创建于执行的环境相分离，在一个线程中创建行为，在另一个线程中执行行为。Command模式的优点在于，将实现操作与构造操作解耦，这就避免了锁的问 题，使得多线程与单线程编程模型统一起来，其次，Command还有一个优点，就是有利于命令的组合和扩展，在Chrome中，它有效统一了同步和异步处理的逻辑。。。
|
在一般的多线程模型中，我们需要分清楚啥是同步 啥是异步，在同步模式下，一切看上去和单线程没啥区别，但同时也丧失了多线程的优势（沦落成为多线程串行…）。而如果采用异步的模式，那写起来就麻烦 多了，你需要注册回调，小心管理对象的生命周期，程序写出来是嗷嗷恶心。在Chrome的多线程模型下，同步和异步的编程模型区别就不复存在了，如果是这 样一个场景：A线程需要B线程做一些事情，然后回到A线程继续做一些事情；在Chrome下你可以这样来做：生成一个Task，放到B线程的队列中，在该 Task的Run方法最后，会生成另一个Task，这个Task会放回到A的线程队列，由A来执行。如此一来，同步异步，天下一统，都是Task传来传 去，想不会，都难了。。。
 |
| 图4 Chrome的一种异步执行的解决方案 |
4. Chrome多线程模型的优缺点
一直在说Chrome在规避锁的问题，那到底锁 是哪里不好，犯了何等滔天罪责，落得如此人见人嫌恨不得先杀而后快的境地。《代码之美》的第二十四章“美丽的并发”中，Haskell设计人之一的 Simon Peyton Jones总结了一下用锁的困难之处，我罚抄一遍，如下：
- 锁少加了，导致两个线程同时修改一个变量；
- 锁多加了，轻则妨碍并发，重则导致死锁；
- 锁加错了，由于锁和需要锁的数据之间的联系，只存在于程序员的大脑中，这种事情太容易发生了；
- 加锁的顺序错了，维护锁的顺序是一件困难而又容易出错的问题；
- 错误恢复；
- 忘记唤醒和错误的重试；
- 而最根本的缺陷，是锁和条件变量不支持模块化的编程。比如一个转账业务中，A账户扣了100元钱，B账户增加了100元，即使这两个动作单独用锁保护维持其正确性，你也不能将两个操作简单的串在一起完成一个转账操作，你必须让它们的锁都暴露出来，重新设计一番。好好的两个函数，愣是不能组在一起用，这就是锁的最大悲哀；
通过这些缺点的描述，也就可以明白Chrome多线程模型的优点。它解决了锁的最根本缺陷，即，支持模块化的编程，你只需要维护对象和线程之间的职能关系即可，这个摊子，比之锁的那个烂摊子，要简化了太多。对于程序员来说，负担一瞬间从泰山降成了鸿毛。。。
而Chrome多线程模型的一个主要难点，在于线程与数据关系的设计上，你需要良好的划分各个线程的职责，如果有一个线程所管辖的数据，几乎占据了大半部分的Task，那么它就会从多线程沦为单线程，Task队列的锁也将成为一个大大的瓶颈。。。
|
从根本上来说，Chrome的线程模型解决的是 并发中的用户体验问题而不是联合工作的问题（参见我前面喷的“闲话并发”），它不是和Map/Reduce那样将关注点放在数据和执行步骤的拆分上，而是 放在线程和数据的对应关系上，这是和浏览器的工作环境相匹配的。设计总是和所处的环境相互依赖的，毕竟，在客户端，不会和服务器一样，存在超规模的并发处理任务，而只是需要尽可能的改善用户体验，从这个角度来说，Chrome的多线程模型，至少看上去很美。。。
作者：duguguiyu
本人重新排版~~
- Google Chrome源码剖析【五】：插件模型
- Google Chrome源码剖析【四】：UI绘制
- Google Chrome源码剖析【三】：进程模型
- Google Chrome源码剖析【二】：进程通信
- Google Chrome源码剖析【一】：多线程模型
- Google Chrome源码剖析【序】
