转载请注明原文地址：
http://blog.csdn.net/milado_nju/article/details/7725510
#Chromium
的进程模型
##
概述
相信你一定有这样的经历：打开很多个页面，不幸的是其中某个页面不响应了或者
崩
溃了，随之而来的是更不幸的事，所有页面都不响应或者都崩溃了。最让人崩溃的是其中一些页面还有未保存或者未发送的信息！
这绝对是不堪回首的过去。但是，现在好了，现代浏览器很多都支持多进程模型，这个模型可以很好地避免上面的问题，虽然它很复杂而且也有自身的问题，例如更多的资源消耗，但是它的优势也是非常明显地。
chromium
的多进程架构至少带来三点好处，其一是避免单个页面的不响应或者奔溃影响整个浏览器的稳定性；其二是当第三方插件奔溃时候不会影响页面或者浏览器的稳定性；其三是方便了安全模型的实施，也就是说沙箱模型是基于多进程架构的。其实，这很大程度上也是
WebKit2
产生的原因。那么，这是怎么做到的呢
?
下图给出了缺省的
chromium
浏览器的进程模型。方框代表进程，连接线代表
IPC
进程间通信。
通常来讲，
chromium
浏览器包括以下主要进程类型：
1.
Browser
进程：浏览器的主进程，负责浏览器界面的显示，各个页面的管理，其他各种进程的管理；
2.
Render
进程：页面的渲染进程，负责页面的渲染工作，
WebKit
的工作主要在这个进程中完成；
3.
NPAPI
插件进程：每种类型的插件只会有一个进程，每个插件进程可以被多个
Render
进程共享；
4.
GPU
进程：最多只有一个，当且仅当
GPU
硬件加速打开的时候才会被创建，主要用于对
3D
加速调用的实现；
5.
Pepper
插件进程：同
NPAPI
插件进程，不同的是为
Pepper
插件而创建的进程
Chromium
浏览器的进程模型，包括以下特征：
1.
browser
进程和页面是分开的，这保证了页面的奔溃不会导致浏览器主界面的奔溃；
2.
每个页面是独立的进程，这保证了页面之间相互不影响；
3.
插件进程也是独立的，插件的问题不会影响浏览器主界面和页面；
4.
GPU
硬件加速进程也是独立的。
因为这么多的进程，开发者通常需要知道进程列表中的进程类别，这很简单，可以通过进程的命令行参数”–type”来识别。
有趣的是，就在我写下上面这段文字的时候，我的
chrome
浏览器的
flash插件崩
溃了，幸运的是其他一切都很好，感谢
chrome
的多进程模型！
##
模型的类型
其实介绍了进程模型，其实
Chromium
支持多种进程模型，特别是对页面而言，下面简单的介绍以下模型的类型：
###Process-per-site-instance
该类型的含义是对同一个域的实例都会创建独立的进程。举个例子来讲，例如，用户访问了
milado_nju
的
CSDN
博客（我的博客），然后从个人主页打开多篇文章时，每篇文章的页面都是该域的一个实例，因而它们都共享同一个的进程。如果新打开
CSDN
博客的主页，那么就是另一个实例，会重新创建进程来渲染它。这带来的好处是每个页面互不影响，坏处自然是资源的巨大浪费。
###Process-per-site
该类型的含义是不同一个域会创建独立的进程，同一域的不同实例共享同一个进程。好处是对于不同的域可以共享，相对较小的内存消耗，坏处是可能会有特别大的
Renderer
进程。可以在命令行加入参数
–process-per-site
来尝试它。
###Process-per-tab
该类型的含义是为每个标签页创建一个独立的进程，这也是
chrome/chromium
的缺省行为
###Single process
该类型的含义是不为页面创建任何独立的进程，所有渲染工作都在
browser
进程中。但是这个类型只是实验性质的，不稳定，因而不推荐使用，只有在比较单进程和多进程时候比较有用，可以在命令行加入参数
–single-process
来尝试它。
##
沙箱模型
在页面的多进程模型中，页面的渲染是运行在沙箱模型中的
Render
进程中实现的，这些渲染引擎没有访问本地资源的能力（例如文件系统，窗口系统，等等），这可以保护渲染引擎被入侵。
##
参考文献
1.
http://www.chromium.org/developers/design-documents/process-models
By
yongsheng@chromium.org