G00gleChr0me源码剖析.docxVIP

【一】 Chrome的多线程模型 0. Chrome的并发模型 如果你仔细看了前面的图，对 HYPERLINK /tag/chrome \o Chrome Chrome的线程和进程框架应该有了个基本的了解。Chrome有一个主进程，称为 HYPERLINK /category/browser \o Browser Browser进程，它是老大，管理 Chrome大部分的日常事务；其次，会有很多Renderer进程，它们圈地而治，各管理一组站点的显示和通信（Chrome在宣传中一直宣称一个 tab对应一个进程，其实是很不确切的…），它们彼此互不搭理，只和老大说话，由老大负责权衡各方利益。它们和老大说话的渠道，称做 IPC（Inter-Process Communication），这是 HYPERLINK /category/google \o Google Google搭的一套进程间通信的机制，基本的实现后面自会分解。。。 Chrome的进程模型 HYPERLINK /tag/google \o Google \t _blank Google在宣传的时候一直都说，Chrome是one tab one process的模式，其实，这只是为了宣传起来方便如是说而已，基本等同广告，实际疗效，还要从代码中来看。实际上，Chrome支持的进程模型远比宣传丰富，你可以参考一下 HYPERLINK /a//dev/developers/design-documents/process-models \o 这里 这里 ，简单的说，Chrome支持以下几种进程模型： Process-per-site-instance：就是你打开一个网站，然后从这个网站链开的一系列网站都属于一个进程。这是Chrome的默认模式。 Process-per-site： 同域名范畴的网站放在一个进程，比如www.google HYPERLINK /tag/com \o .com .com和/bookmarks就属于一个域名内（google有 自己的判定机制），不论有没有互相打开的关系，都算作是一个进程中。用命令行–process-per-site开启。 Process-per-tab：这个简单，一个tab一个process，不论各个tab的站点有无联系，就和宣传的那样。用–process-per-tab开启。 Single Process：这个很熟悉了吧，传统浏览器的模式，没有多进程只有多线程，用–single-process开启。 关于各种模式的优缺点，官方有官方的说法，大家自己也会有自己的评述。不论如何，至少可以说明，Google不是由于白痴而采取多进程的策略，而是实验出来的效果。。。 大家可以用Shift+Esc观察各模式下进程状况，至少我是观察失败了（每种都和默认的一样…），原因待跟踪。。。不论是Browser进程还是Renderer 进程，都不只是光杆司令，它们都有一系列的线程为自己打理各种业务。对于Renderer进程，它们通常有两个线程，一个是Main thread，它负责与老大进行联系，有一些幕后黑手的意思；另一个是Render thread，它们负责页面的渲染和交互，一看就知道是这个帮派的门脸级人物。相比之下，Browser进程既然是老大，小弟自然要多一些，除了大脑般的 Main thread，和负责与各Renderer帮派通信的IO thread，其实还包括负责管文件的file thread，负责管数据库的db thread等等（一个更详细的列表，参见 HYPERLINK /a//dev/developers/design-documents/threading \o 这里 \t _blank 这里），它们各尽其责，齐心协力为老大打拼。它们和各Renderer进程的之间的关系不一样，同一个进程内的线程，往往需要很多的协同工作，这一坨线程间的并发管理，是Chrome最出彩的地方之一了。。。 闲话并发 单进程单线程的编程是最惬意的事情，所看即所得，一维的思考即可。但程序员的世界总是没有那么美好，在很多的场合，我们都需要有多线程、多进程、多机器携起手来一齐上阵共同完成某项任务，统称：并发（非官方版定义…）。在我看来，需要并发的场合主要是要两类： 为了更好的用户体验。 有的事情处理起来太慢，比如数据库读写、远程通信、复杂计算等等，如果在一个线程一个进程里面来做，往往会影响用户感受，因此需要另开一个线程或进程转到 后台进行处理。它之所以能够生效，仰仗的是单CPU的分时机制，或者是多CPU协同工作。在单CPU的条件下，两个任务分成两拨完成的总时间，是大于两个 任务轮流完成的，但是由于彼此交错，更人的感觉更