【一】 Chrome的多執行緒模型

0. Chrome的併發模型

如果你仔細看了前面的圖，對Chrome的執行緒和程序框架應該有了個基本的瞭解。Chrome有一個主程序，稱為Browser程序，它是老大，管理Chrome大部分的日常事務；其次，會有很多Renderer程序，它們圈地而治，各管理一組站點的顯示和通訊（Chrome在宣傳中一直宣稱一個tab對應一個程序，其實是很不確切的...），它們彼此互不搭理，只和老大說話，由老大負責權衡各方利益。它們和老大說話的渠道，稱做IPC（Inter-Process Communication），這是Google搭的一套程序間通訊的機制，基本的實現後面自會分解。。。

Chrome的程序模型 Google在宣傳的時候一直都說，Chrome是one tab one process的模式，其實，這只是為了宣傳起來方便如是說而已，基本等同廣告，實際療效，還要從程式碼中來看。實際上，Chrome支援的程序模型遠比宣傳豐富，你可以參考一下這裡 ，簡單的說，Chrome支援以下幾種程序模型： Process-per-site-instance：就是你開啟一個網站，然後從這個網站鏈開的一系列網站都屬於一個程序。這是Chrome的預設模式。 Process-per-site：同域名範疇的網站放在一個程序，比如www.google.com和www.google.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等等（一個更詳細的列表，參見

這裡），它們各盡其責，齊心協力為老大打拼。它們和各Renderer程序的之間的關係不一樣，同一個程序內的執行緒，往往需要很多的協同工作，這一坨執行緒間的併發管理，是Chrome最出彩的地方之一了。。。

閒話併發 單程序單執行緒的程式設計是最愜意的事情，所看即所得，一維的思考即可。但程式設計師的世界總是沒有那麼美好，在很多的場合，我們都需要有多執行緒、多程序、多機器攜起手來一齊上陣共同完成某項任務，統稱：併發（非官方版定義...）。在我看來，需要併發的場合主要是要兩類： 為了更好的使用者體驗。有的事情處理起來太慢，比如資料庫讀寫、遠端通訊、複雜計算等等，如果在一個執行緒一個程序裡面來做，往往會影響使用者感受，因此需要另開一個執行緒或程序轉到後臺進行處理。它之所以能夠生效，仰仗的是單CPU的分時機制，或者是多CPU協同工作。在單CPU的條件下，兩個任務分成兩撥完成的總時間，是大於兩個任務輪流完成的，但是由於彼此交錯，更人的感覺更為的自然一些。 為了加速完成某項工作。大名鼎鼎的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, windows, windows...）。不同的訊息迴圈類，主要差異有兩個，一是訊息迴圈中需要處理什麼樣的訊息和任務，第二個是迴圈流程（比如是死迴圈還是阻塞在某訊號量上...）。下圖是一個完整版的Chrome訊息迴圈圖，包含處理Windows的訊息，處理各種Task（Task是什麼，稍後揭曉，敬請期待...），處理各個訊號量觀察者（Watcher），然後阻塞在某個訊號量上等待喚醒。。。

圖2 Chrome的訊息迴圈

當然，不是每一個訊息迴圈類都需要跑那麼一大圈的，有些執行緒，它不會涉及到那麼多的事情和邏輯，白白浪費體力和時間，實在是不可饒恕的。因此，在實現中，不同的MessagePump類，實現是有所不同的，詳見下表：

MessagePumpDefault	MessagePumpForIO	MessagePumpForUI
是否需要處理系統訊息	否	是	是
是否需要處理Task	是	是	是
是否需要處理Watcher	否	是	否
是否阻塞在訊號量上	否	是	是

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，卻把它放到別的執行緒中去執行，這種寄居蟹似的生活方式，在很多場合都是有用武之地的。。。

在一般的多執行緒模型中，我們需要分清楚啥是同步啥是非同步，在同步模式下，一切看上去和單執行緒沒啥區別，但同時也喪失了多執行緒的優勢（淪落成為多執行緒序列...）。而如果採用非同步的模式，那寫起來就麻煩多了，你需要註冊回撥，小心管理物件的生命週期，程式寫出來是嗷嗷噁心。在Chrome的多執行緒模型下，同步和非同步的程式設計模型區別就不復存在了，如果是這樣一個場景：A執行緒需要B執行緒做一些事情，然後回到A執行緒繼續做一些事情；在Chrome下你可以這樣來做：生成一個Task，放到B執行緒的佇列中，在該Task的Run方法最後，會生成另一個Task，這個Task會放回到A的執行緒佇列，由A來執行。如此一來，同步非同步，天下一統，都是Task傳來傳去，想不會，都難了。。。

圖4 Chrome的一種非同步執行的解決方案

4. Chrome多執行緒模型的優缺點

一直在說Chrome在規避鎖的問題，那到底鎖是哪裡不好，犯了何等滔天罪責，落得如此人見人嫌恨不得先殺而後快的境地。《程式碼之美》的第二十四章“美麗的併發”中，Haskell設計人之一的Simon Peyton Jones總結了一下用鎖的困難之處，我罰抄一遍，如下：

1. 鎖少加了，導致兩個執行緒同時修改一個變數；
   
2. 鎖多加了，輕則妨礙併發，重則導致死鎖；
   
3. 鎖加錯了，由於鎖和需要鎖的資料之間的聯絡，只存在於程式設計師的大腦中，這種事情太容易發生了；
   
4. 加鎖的順序錯了，維護鎖的順序是一件困難而又容易出錯的問題；
   
5. 錯誤恢復；
   
6. 忘記喚醒和錯誤的重試；
   
7. 而最根本的缺陷，是鎖和條件變數不支援模組化的程式設計。比如一個轉賬業務中，A賬戶扣了100元錢，B賬戶增加了100元，即使這兩個動作單獨用鎖保護維持其正確性，你也不能將兩個操作簡單的串在一起完成一個轉賬操作，你必須讓它們的鎖都暴露出來，重新設計一番。好好的兩個函式，愣是不能組在一起用，這就是鎖的最大悲哀；
   

通過這些缺點的描述，也就可以明白Chrome多執行緒模型的優點。它解決了鎖的最根本缺陷，即，支援模組化的程式設計，你只需要維護物件和執行緒之間的職能關係即可，這個攤子，比之鎖的那個爛攤子，要簡化了太多。對於程式設計師來說，負擔一瞬間從泰山降成了鴻毛。。。 而Chrome多執行緒模型的一個主要難點，在於執行緒與資料關係的設計上，你需要良好的劃分各個執行緒的職責，如果有一個執行緒所管轄的資料，幾乎佔據了大半部分的Task，那麼它就會從多執行緒淪為單執行緒，Task佇列的鎖也將成為一個大大的瓶頸。。。

設計者的職責 一個底層結構設計是否成功，這個設計者是否稱職，我一直覺得是有一個很簡單的衡量標準的。你不需要看這個設計人用了多少NB的技術，你只需要關心，他的設計，是否給其他開發人員帶來了困難。一個NB的設計，是將所有困難都集中在底層搞定，把其他開發人員換成白痴都可以工作的那種；一個SB的設計，是自己弄了半天，只是為了給其他開發人員一個長達250條的注意事項，然後很NB的說，你們按照這個手冊去開發，就不會有問題了。。。

從根本上來說，Chrome的執行緒模型解決的是併發中的使用者體驗問題而不是聯合工作的問題（參見我前面噴的“閒話併發”），它不是和Map/Reduce那樣將關注點放在資料和執行步驟的拆分上，而是放線上程和資料的對應關係上，這是和瀏覽器的工作環境相匹配的。設計總是和所處的環境相互依賴的，畢竟，在客戶端，不會和伺服器一樣，存在超規模的併發處理任務，而只是需要儘可能的改善使用者體驗，從這個角度來說，Chrome的多執行緒模型，至少看上去很美。。。