原著：duguguiyu。
整理：July。
时间：二零一一年四月二日。
出处：http://blog.csdn.net/v_JULY_v。
说明：此Chrome源码剖析很大一部分编辑整理自此博客：http://flyvenus.net/。我对写原创文章的作者向来是以最大的尊重的。近期想好好研究和学习下Chrome源码，正巧看到了此duguguiyu兄台的源码剖析，处于学习的目的，就不客气的根据他的博客整理了此文。若有诸多冒犯之处，还望海涵。
--------------------------------
前言：
1、之所以整理此文，有俩个目的：一是为了供自己学习研究之用；二是为了备份，以作日后反复研究。除此之外，无它。
2、此文的形式其实是有点俩不像的，既不是个人首创即原创，又非单纯的转载（有加工），无奈之下，权且称作翻译吧。有不妥之处，还望原作者，及读者见谅。
文中加入了我自己的一些见解，请自行辨别。顺便再说一句，duguguiyu写的这个Chrome源码剖析，真不错，勾起了偶对源码剖析的莫大兴趣。
顺便透露下：在此份Chrome源码剖析之后，互联网上即将，首次出现sgi stl v3.3版的源码剖析拉。作者：本人July。是的，本人最近在研究sgi stl v3.3版的源码，正在做源码剖析，个人首创，敬请期待。
在具体针对源码剖析之前，再粗略回答一下网友可能关心的问题：chrome速度维护如此之快？据网上资料显示：有几个主要的关键技术：DNS预解析、Google自主开发的V8 Javacript引擎、DOM绑定技术以及多进程架构等等。但这不是本文的重点，所以略过不谈。
ok，激动人心的Chrome源码剖析旅程，即刻开始。
Chrome源码剖析【序】
此序成于08年末，Chrome刚刚推出之际。
duguguiyu：“有的人一看到Chrome用到多进程就说垃圾废物肯定低能。拜托，大家都是搞技术的，你知道多进程的缺点，Google也知道，他们不是政客，除了搞个噱头扯个蛋就一无所知了，人家也是有脸有皮的，写一坨屎一样的开源代码放出来遭世人耻笑难道会很开心？所谓技术的优劣，是不能一概而论的，同样的技术在不同场合不同环境不同代码实现下，效果是有所不同的。....”
Chrome对我来说，有吸引力的地方在于（排名分先后…）：
1、它是如何利用多进程（其实也会有多线程一起）做并发的，又是如何解决多进程间的一些问题的，比如进程间通信，进程的开销；
2、做为一个后来者，它的扩展能力如何，如何去权衡对原有插件的兼容，提供怎么样的一个插件模型；
3、它的整体框架是怎样，有没有很NB的架构思想；
4、它如何实现跨平台的UI控件系统；
5、传说中的V8，为啥那么快。
但Chrome是一个跨平台的浏览器，其Linux和Mac版本正在开发过程中，所以我把所有的眼光都放在了windows版本中，所有的代码剖析都是基于windows版本的。有错误请指正。
关于Chrome的源码下载和环境配置，大家可自行查找资料，强调一点，一定要严格按照说明来配置环境，特别是vs2005的补丁和windows SDK的安装，否则肯定是编译不过的。
最后，写这部分唯一不是废话的内容，请记住以下这幅图，这是Chrome最精华的一个缩影：
图1 Chrome的线程和进程模型
Chrome源码剖析【一】—— 多线程模型
【一】 Chrome的多线程模型
0. Chrome的并发模型
如果你仔细看了前面的图，对Chrome的线程和进程框架应该有了个基本的了解。Chrome有一个主进程，称为Browser进程，它是老大，管理Chrome大部分的日常事务；其次，会有很多Renderer进程，它们圈地而治，各管理一组站点的显示和通信（Chrome在宣传中一直宣称一个tab对应一个进程，其实是很不确切的…），它们彼此互不搭理，只和老大说话，由老大负责权衡各方利益。它们和老大说话的渠道，称做IPC（Inter-Process Communication），这是Google搭的一套进程间通信的机制，基本的实现后面自会分解。
Chrome的进程模型
Google在宣传的时候一直都说，Chrome是one tab one process的模式，其实，这只是为了宣传起来方便如是说而已，基本等同广告，实际疗效，还要从代码中来看。实际上，Chrome支持的进程模型远比宣传丰富，简单的说，Chrome支持以下几种进程模型：
1.Process-per-site-instance：就是你打开一个网站，然后从这个网站链开的一系列网站都属于一个进程。这是Chrome的默认模式。
2.Process-per-site：同域名范畴的网站放在一个进程，比如www.google.com（由于此文形成于08年，所以无法访问，你懂的）和www.google.com/bookmarks就属于一个域名内（google有自己的判定机制），不论有没有互相打开的关系，都算作是一个进程中。用命令行–process-per-site开启。
3.Process-per-tab：这个简单，一个tab一个process，不论各个tab的站点有无联系，就和宣传的那样。用–process-per-tab开启。
4.Single Process：这个很熟悉了吧，即传统浏览器的模式：没有多进程只有多线程，用–single-process开启。
关于各种模式的优缺点，官方有官方的说法，大家自己也会有自己的评述。不论如何，至少可以说明，Google不是由于白痴而采取多进程的策略，而是实验出来的效果。
大家可以用Shift+Esc观察各模式下进程状况，至少我是观察失败了（每种都和默认的一样…），原因待跟踪。
不论是Browser进程还是Renderer进程，都不只是光杆司令，它们都有一系列的线程为自己打理各种业务。对于Renderer进程，它们通常有两个线程：一个是Main thread，它负责与老大进行联系，有一些幕后黑手的意思；另一个是Render thread，它们负责页面的渲染和交互，一看就知道是这个帮派的门脸级人物。
相比之下，Browser进程既然是老大，小弟自然要多一些，除了大脑般的Main thread，和负责与各Renderer帮派通信的IO thread，其实还包括负责管文件的file thread，负责管数据库的db thread等等，它们各尽其责，齐心协力为老大打拼。它们和各Renderer进程的之间的关系不一样，同一个进程内的线程，往往需要很多的协同工作，这一坨线程间的并发管理，是Chrome最出彩的地方之一了。
闲话并发
单进程单线程的编程是最惬意的事情，所看即所得，一维的思考即可。但程序员的世界总是没有那么美好，在很多的场合，我们都需要有多线程、多进程、多机器携起手来一齐上阵共同完成某项任务，统称：并发（非官方版定义…）。在我看来，需要并发的场合主要是要两类：
1.为了更好的用户体验。有的事情处理起来太慢，比如数据库读写、远程通信、复杂计算等等，如果在一个线程一个进程里面来做，往往会影响用户感受，因此需要另开一个线程或进程转到后台进行处理。它之所以能够生效，仰仗的是单CPU的分时机制，或者是多CPU协同工作。在单CPU的条件下，两个