2012 不宜進入的三個技術點

賴勇浩（http://laiyonghao.com）

執行緒是指程式中的一個單一順序的控制流，是作業系統能夠排程的最小單位，一個程式中可以有多條執行緒，分別執行不同的任務。執行緒有核心執行緒和使用者執行緒之分，但在本文中僅指核心執行緒。在軟體開發中，使用執行緒有以下好處：
1、在多核或多路 CPU 的機器上多執行緒程式能夠併發執行，提高運算速度；
2、把 I/O，人機互動等與密集運算部分分離，提升 I/O 吞吐量和增進使用者體驗。
執行緒的缺點也很明顯：
1、建立一條執行緒需要較大的記憶體開銷，導致不能建立海量的執行緒；
2、執行緒由作業系統排程（分配時間片），執行緒切換的 CPU 成本比較高，導致大量執行緒存在時大量 CPU 資源消耗線上程切換上；
3、同一程式的多條執行緒共享全部系統資源，在多執行緒間共享資源需要進入加鎖，大量的鎖開銷不提，重要的是加大了編寫程式的複雜性，這一點你看看有多少書名含有“多執行緒”三個字就明白寫個多執行緒應用有多難了；
4、 I/O 方面，多執行緒幫助有限，以 TCP Socket Server 為例，如果每一個 client connection 由一條專屬的執行緒服務，那麼這個 server 可能併發量很難超過 1000。為了進一步解決併發帶來的問題，現代伺服器都使用 event-driven i/o 了。
event-driven i/o 解決了併發量的問題，但引入了“程式碼被回撥函式分割得零零碎碎”的問題。特別是當 event-driven i/o 跟 multi-threading 結合在一起的時候，麻煩就倍增了。解決這個問題的辦法就使用綠色執行緒，綠色執行緒可以在同一個程式中成千上萬地存在，從而可以在非同步 I/O 上封裝出同步的 APIs，典型的就是用基於 greenlet + libevent 開發的 python 庫 gevent。綠色執行緒的缺陷在於作業系統不知道它的存在，需要使用者進行排程，也就無法利用到多核或多路 CPU 了。為了解決這個問題，很多大牛都做出了巨大的努力，並且成果斐然，scala、google go 和 rust 都較好地解決了問題，下文以 rust 的併發模型為例講一下。
rust 提出一個 Task 的概念，Task 有一個入口函式，也有自己的棧，並擁有程式堆記憶體的一部分，為方便理解，你可以把它看作一條綠色執行緒。rust 程式可以建立成千上萬個 Tasks，它們由內建的排程器進行排程，因為 Tasks 之間並不共享資料，只通過 channels/ports 通訊，所以它們是可並行程度很高。rust 程式啟動時會生成若干條（數量由 CPU 核數決定或執行時指定）執行緒，這些執行緒並行執行 Tasks，從而利用多個 CPU 核心。

如 上圖，rust 應用程式不停地 spawn 出一個又一個 Tasks，它們由 tasks 排程器管理，在適當的時機，排程器會把某一個 Task 分配給原生執行緒執行，如果這個 Task 進入 I/O 等待或主動讓出 CPU（sleep），那麼這個 Task 會被交回給排程器，而相應的原生執行緒會執行另一個新分派的 Task。儘管使用 rust 程式語言是不能建立執行緒的（直接呼叫 C 函式不算），但 rust 應用程式實際上是多執行緒的（一般情況下），它能夠充分地利用多核或多路 CPU。
綜上，類似 rust 的 Task 的概念是比執行緒更好的併發模型，更安全，編寫的程式碼也更加容易維護（關於維護性，我相信寫過 gevent 程度或 go 程式的同學會認同的）。執行緒當然不會消亡，但隨著 scala/go/rust 的成熟，在可以預見的將來，執行緒會退到它呆著的角落：遠離普通程式設計師，只有少數人需要了解它的細節。

賴勇浩（http://laiyonghao.com）

C++ 在 2011 年其實風頭甚勁，C++2011 標準出臺，gcc/msvc/clang 都很快速地支援了許多新特性，新興的移動裝置的效能較差，更是 C++ 的新舞臺，在這個時候唱衰 C++，壓力很大。我使用 C++ 年頭不少，但除了在校的時候寫過兩個小遊戲參加過兩個比賽（分別是面向社會和麵向大學生的）弄些證照好找工作以外，在工作中只用過大概不到一年半，做《斬 魂》（http://zh.163.com）的早期版本，寫了伺服器端的幾條程式和客戶端的 GameAI 部分。經驗少，而且寫得不好，所以基本上有人在 weibo 上問我 C++ 的問題，我都是轉發給 @bnu_chenshuo 和 @miloyip 等真正的行家去回答的。所以實際上今天寫這一篇，我底氣很是不足，但是朋友們給前兩篇很大面子，弄得我騎虎難下，只好硬著頭皮寫了。
前 文提到 C++ 的新標準，很有必要提一下標準化對 C++ 的影響。首先我們要肯定標準定製對 C++ 的積極作用，但標準化過程中的超長流程，一次次將 C++ 推向深淵。C++ 的第一個標準是 1998 年的 ISO/IEC 14882:1998，距離整個 90 年代最流行的 C++ 程式庫 MFC（Microsoft Foundation Class Library）的第一個版本發行時間已經整整  6 年。1998 年，MFC 版本號為 6.0，與其一起釋出的 Visual C++ 6.0 佔有了巨大的市場。因為 MFC 釋出得標準制定的時間早，所以 MFC 內部實現了許多後來標準庫裡也有的元件，比如各種資料結構容器。VC6 的市場佔有率讓 windows 平臺下開發的許多 C++ 程式設計師甚至不知道有 STL，同時也無視 C++98 標準，從更相容標準的 VC2002/2003 的市場佔有率就可以看出來，直到今天，我知道國內不少公司還是隻用 VC6 的。
其實在 90 年代，計算機的運算能力有限，市場上非常需要一款效能較高、抽象較強的程式語言，C++ 獲得了成功，但它標準化的時間過長，造成各種編譯器有各自互不相容的“方言”，成了它的第一個軟肋。第一個瞄準這個軟肋的就是 java，java 在 1995 年推出，雖然效能稍遜，但它有更高的抽象能力、也更安全，並且更容易跨平臺，所以迅速獲得了成功；第二個瞄準這個軟肋的是 C#，微軟不能推動 C++ 發展，又不願 C++ 的市場被 java 鯨吞，於是在 2001 年推出了 C#，經過 10 年的發展和微軟大量的金錢推廣，C# 已經成功獲得了它應有的江湖地位。
雖然 java/c# 都不是善類，但 C++ 在 21 世紀的第一個十年裡仍然地位穩固，這是因為 Linux 和 MacOS X 大獲成功，在這兩個平臺上 C++ 都是非常有競爭力的程式語言，C++ 自然水漲船高。但隨著 web2.0 和 web app 概念的興起，以及 CPU 的主頻進一步提升，伺服器端程式語言漸漸地對執行效率不再敏感，而是更在意程式設計師的開發效率，眾多的指令碼語言開始蠶食 C++ 的市場份額，從早期的 perl 到後期的 python/php/ruby，在 2005 年以後，C++/java/C# 等靜態型別的編譯型語言的市場份額都下降了，新興的貴族是動態語言。面對動態語言在開發效率上的強勁挑戰，C++ 社群除了在 2003 年對 C++98 做了小小的 patch，基本上睡著了，完全沒有應對之策，哦不，連應用的姿態都沒有。
進入 21 世紀的第二個十年，市場又發生了變化，雲端計算越走越近，也許我們中的大部分人今天還可以說只聞其聲不見其形，但 The Data Center Is the Computer 這句話大家應該覺得很務實：完成一個使用者操作，在伺服器端的程式間通訊次數前所未有地多。在這個十年，我們需要這樣的程式語言：
1、能充分利用現代 CPU 的計算能力，不僅僅是多個核心，更是巨大的 L1/L2/L3 Cache、超執行緒等；
2、能夠大量減小非同步 I/O 的效能提升的同時帶來的副作用：非同步程式設計的複雜性以及對可維護性的傷害；
兩 句話其實也可以壓縮為一句：需要有更好的併發模型的語言。一開始大家都在已有的程式語言中尋找，然後找到了 erlang，實踐證明 erlang 自有其侷限，所以 google go/scala/rust 等新語言如同雨後春筍般撥地而出。C++2011 標準努力降低 C++ 的程式設計難度，並提供了執行緒庫以支援現代 CPU，如果在 2005 年，這個標準絕對有競爭力，但在今天，它只能成為新的程式語言的墊腳石。正如 IE 最大的用處是用來下載其它瀏覽器，不久之後，也許會流行新的冷笑話：C++ 最大的用處就是用來實現其它程式語言。
市場一直在尋找一門中間的高階 語言，它上承 C 語言和組合語言，下啟指令碼語言。C++ 最先搶佔了高地，並在與 java/c# 的爭鬥中不落下風，但新的十年，它的對手又增加了 google go/scala/rust 等新銳，並且新的標準不可能在兩三年內再次出臺，兩三年內新銳成長起來後，留給它的位置就不多了。
上 文討論的基本上都是伺服器程式設計，有必要再來看一下桌面和移動裝置領域。首先看桌面軟體，rust 是 mozilla 基金會開發系統程式語言的，它的定位是部分取代 C++ 開發 firefox 的瀏覽器，所以 rust 會進入桌面開發，google go 肯定會順道啃一口。移動裝置方面，主要是 android、ios 和 windows phone，隨著移動裝置效能增強，編譯型語言加指令碼的模式就會佔大頭，編譯型語言方面主要是 C++ 和 Objective-C 在競爭，C++ 會佔上風（但需求量遠遠小於指令碼，從 lua 在 2011 年的增長速度可以印證），但是誰知道 rust 之類的會不會進入移動裝置呢，畢竟移動裝置的 CPU 核心也越來越多了呀，C++ 還是前景堪憂。
回首 C++ 的 30 年，展望它的未來，總結起來可能就是：標準化流程拖死人了。如果不是 15 年不能標準化，java/c# 的攪局可能不會出現；如果在 2005 年能夠應對動態語言……如果雲時代有更好的併發模型……
題 外話：java/c# 不會有 C++ 的問題，因為它們有自己的平臺，有巨大的財富支撐。特別是平臺的作用非常巨大，你可以想像一下如果 Adobe 有自己的瀏覽器或手機作業系統 ActionScript/MXML 會不會是今天的境地；也可以想像一下 google go 的飛速發展動力是什麼。