2.为了加速完成某项工作。大名鼎鼎的Map/Reduce，做的就是这样的事情，它将一个大的任务，拆分成若干个小的任务，分配个若干个进程去完成，各自收工后，再汇集在一起，更快地得到最后的结果。为了达到这个目的，只有在多CPU的情形下才有可能，在单CPU的场合（单机单CPU…），是无法实现的。
在第二种场合下，我们会自然而然的关注数据的分离，从而很好的利用上多CPU的能力；而在第一种场合，我们习惯了单CPU的模式，往往不注重数据与行为的对应关系，导致在多CPU的场景下，性能不升反降。

1. Chrome的线程模型
仔细回忆一下我们大部分时候是怎么来用线程的，在我足够贫瘠的多线程经历中，往往都是这样用的：起一个线程，传入一个特定的入口函数，看一下这个函数是否是有副作用的（Side Effect），如果有，并且还会涉及到多线程的数据访问，仔细排查，在可疑地点上锁伺候。

Chrome的线程模型走的是另一个路子，即，极力规避锁的存在。换更精确的描述方式来说，Chrome的线程模型，将锁限制了极小的范围内（仅仅在将Task放入消息队列的时候才存在…），并且使得上层完全不需要关心锁的问题（当然，前提是遵循它的编程模型，将函数用Task封装并发送到合适的线程去执行…），大大 化了开发的逻辑。

不过，从实现来说，Chrome的线程模型并没有什么神秘的地方，它用到了消息循环的手段。每一个Chrome的线程，入口函数都差不多，都是启动一个消息循环（参见MessagePump类），等待并执行任务。
而其中，唯一的差别在于，根据线程处理事务类别的不同，所起的消息循环有所不同。比如处理进程间通信的线程（注意，在Chrome中，这类线程都叫做IO线程）启用的是MessagePumpForIO类，处理UI的线程用的是MessagePumpForUI类，一般的线程用到的是MessagePumpDefault类（只讨论windows）。
不同的消息循环类，主要差异有两个，一是消息循环中需要处理什么样的消息和任务，第二个是循环流程（比如是死循环还是阻塞在某信号量上…）。下图是一个完整版的Chrome消息循环图，包含处理Windows的消息，处理各种Task（Task是什么，稍后揭晓，敬请期待），处理各个信号量观察者（Watcher），然后阻塞在某个信号量上等待唤醒。

图2 Chrome的消息循环

当然，不是每一个消息循环类都需要跑那么一大圈的，有些线程，它不会涉及到那么多的事情和逻辑，白白浪费体力和时间，实在是不可饶恕的。因此，在实际中，不同的MessagePump类，实现是有所不同的，详见下表：

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在底层库上做了足够的功夫：
1.它提供了一大套的模板封装（参见task.h），可以将Task摆脱继承结构、函数名、函数参数等限制（就是基于模板的伪function实现，想要更深入了解，建议直接看鼻祖《Modern C++》和它的Loki库…）；
2.同时派生出CancelableTask、ReleaseTask、DeleteTask等子类，提供更为良好的默认实现；
3.在消息循环中，按逻辑的不同，将Task又分成即时处理的Task、延时处理的Task、Idle时处理的Task，满足不同场景的需求；
4.Task派生自tracked_objects::Tracked，Tracked是为了实现多线程环境下的日志记录、统计等功能，使得Task天生就有良好的可调试性和可统计性；
这一套七荤八素的都搭建完，这才算是一个完整的Task模型，由此可知，这饺子，做的还是很费功夫的。

3. Chrome的多线程模型
工欲善其事，必先利其器。Chrome之所以费了老鼻子劲去磨底层框架这把刀，就是为了面对多线程这坨怪兽的时候杀的更顺畅一些。在Chrome的多线程模型下，加锁这个事情只发生在将Task放入某线程的任务队列中，其他对任何数据的操作都不需要加锁。当然，天下没有免费的午餐，为了合理传递Task，你需要了解每一个数据对象所管辖的线程，不过这个事情，与纷繁的加锁相比，真是小儿科了不知道多少倍。

图3 Task的执行模型

如果你熟悉设计模式，你会发现这是一个Command模式，将创建于执行的环境相分离，在一个线程中创建行为，在另一个线程中执行行为。Command模式的优点在于，将实现操作与构造操作解耦，这就避免了锁的问题，使得多线程与单线程编程模型统一起来，其次，Command还有一个优点，就是有利于命令的组合和扩展，在Chrome中，它有效统一了同步和异步处理的逻辑。

Command模式
Command模式，是一种看上去很酷的模式，传统的面向对象编程，我们封装的往往都是数据，在Command模式下，我们希望封装的是行为。这件事在函数式编程中很正常，封装一个函数作为参数，传来传去，稀疏平常的事儿；但在面向对象的编程中，我们需要通过继承、模板、函数指针等手法，才能将其实现。

应用Command模式，我们是期望这个行为能到一个不同于它出生的环境中去执行，简而言之，这是一种想生不想养的行为。我们做Undo/Redo的时候，会把在任一一个环境中创建的Command，放到一个队列环境中去，供统一的调度；在Chrome中，也是如此，我们在一个线程环境中创建了Task，却把它放到别的线程中去执行，这种寄居蟹似的生活方式，在很多场合都是有用武之地的。