轉載請註明原文地址：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
該類型的含義是爲每一個頁面都創建一個獨立的Render進程，不管這些頁面是否來自於同一域。舉個例子來講，例如，用戶訪問了milado_nju的CSDN博客（我的博客），然後從個人主頁打開多篇文章時，每篇文章的頁面都是該域的一個實例，因而它們都有各自不同的渲染進程。如果新打開CSDN博客的主頁，那麼就是另一個實例，會重新創建進程來渲染它。這帶來的好處是每個頁面互不影響，壞處自然是資源的巨大浪費。
###Process-per-site
該類型的含義是爲屬於同一個域的頁面共享同一個進程，而不同一個域的網頁則分屬不同的進程。好處是對於相同的域可以共享，相對較小的內存消耗，壞處是可能會有特別大的Renderer進程。可以在命令行加入參數--process-per-site來嘗試它。
###Process-per-tab
該類型的含義是爲每個標籤頁創建一個獨立的進程，這也是chrome/chromium的缺省行爲
###Single process
該類型的含義是不爲頁面創建任何獨立的進程，所有渲染工作都在browser進程中。但是這個類型只是實驗性質的，不穩定，因而不推薦使用，只有在比較單進程和多進程時候比較有用，可以在命令行加入參數--single-process來嘗試它。
值得提出的是，在Android系統上，不是上面的模型都支持的很好。
##沙箱模型
在頁面的多進程模型中，頁面的渲染是運行在沙箱模型中的Render進程中實現的，這些渲染引擎沒有訪問本地資源的能力（例如文件系統，窗口系統，等等），這可以保護渲染引擎被入侵。
##參考文獻
1. http://www.chromium.org/developers/design-documents/process-models