1、一個Thread只能有一個MessageLoop被實例化。例如，在BrowserMain函數(該函數是Browser進程的入口函數)中實例化一個局部變量MessageLoop main_message_loop(MessageLoop:TYPE_UI)，以后在該線程中任意位置可以通過調用MessageLoop:current()來獲取該MessageLoop并調用MessageLoop:current()-Run()來執行該線程實體。這其中的技術就是線程局部存儲（ThreadLocalPointer），當構造一個MessageLoop時，構造函數會將這個MessageLoop指針設置到這個線程

2、的ThreadLocalPointer 對象中，當MessageLoop對象析構時，會重置ThreadLocalPointer 對象。在多線程模型中最令人頭疼的問題是“加鎖”。為了極力避免鎖的存在，Chromium的線程模型中加入了一種名為TASK的概念。當你期望你的一個邏輯（or函數）在某個線程中執行時，你可以在當前線程中創建一個Task對象，并將該邏輯放入到Task的Run方法中，最后通過調用“期望執行邏輯線程的PostTask方法”，就可以將該Task放入到期望線程的Task隊列中了。這樣做的好處是避免了“加鎖”操作，使得多線程與單線程編程模型很好的結合在了一起。例如：MessageLo

3、op:current()-PostTask(task),該操作可以方便客戶端將TASK放入到當前線程的消息隊列中去執行。也可以SomeThread-message_loop()-PostTask(task),將task放到其他線程中去執行。在一般的多線程模型中，同步模式下，一切看上去沒什么區別，但也喪失了多線程的優勢；如果采用異步模式，那么你必須注冊回調函數，小心管理對象的生命周期。在Chromium的多線程模型中，同步和異步的編程模型區別就不復存在了。例如：A線程需要B線程做一些事情，然后返回A線程繼續做一些事情。在Chromium中可以這樣做：生成一個Task,放到B線程的隊列中，在該Ta

4、sk的Run方法最后，生成另一個Task，將該Task放回到A線程的隊列中，由A來執行Chromium采用多進程的原因： 提高Browser的健壯性：包括單個Plugin、單個頁面的崩潰導致整個Browser的崩潰問題； 提高Browser的安全性：基于多進程的安全模型（sandbox模型），Render進程默認是基于Sandbox模型的。Chromium中的主要進程： Browser進程。主進程，負責瀏覽器界面的顯示，各個頁面的管理，是所有其他進程的祖先，負責它們的創建和銷毀等工作，它又且僅有一個。 Render進程。渲染進程，負責網頁的渲染工作，WebKit/Blink的渲染工作主要在該進

5、程中完成，可以有多個。 GPU進程。有且只有一個，當且僅當GPU硬件加速打開的時候才會被創建，主要用于對3D圖像加速調用的實現。 Pepper/NPAPI插件進程。在Chromium中，IPC用的是“有名管道”（Named Pipe），它通過類IPC:Channel封裝了具體實現細節。Channel中有三個比較關鍵的角色 IPC:Sender IPC:Listener MessagePumpLibevent:Watcher顧名思義，Sender就是發送消息的接口；Listener是處理接收到消息的具體實現；Watcher中是一些事件回調函數，即當注冊到libevent中的Read、Write事件被觸發時會調用到Wathcer中的回調函數。在每個進程中，只能有一個線程來負責操作Channel，這個線程叫做IO線程，但是有些時候，我們需要從非IO線程與別的進程進行通信，這該如何是好呢？你一定會想到通過postTask將一個對Channel進行操作的Task放到IO線程隊列中。這就是ChannelProxy類的作用。從接口上看，ChannelProxy的接口與Channel沒啥區別，你可以像使用Channel一樣使用ChannelProxy來Send你的消息。不僅如此，ChannelP