第 1 部分 C 多線程繫統編程
第 1 章 線程安全的對像生命期管理
1.1 當析構函數遇到多線程
1.1.1 線程安全的定義
1.1.2 MutexLock 與 MutexLockGuard
1.1.3 一個線程安全的 Counter 示例
1.2 對像的創建很簡單
1.3 銷毀太難
1.3.1 mutex 不是辦法
1.3.2 作為數據成員的 mutex 不能保護析構
1.4 線程安全的 Observer 有多難
1.5 原始指針有何不妥
1.6 神器 shared_ptr/weak_ptr
1.7 插曲：繫統地避免各種指針錯誤
1.8 應用到 Observer 上
1.9 再論 shared_ptr 的線程安全
1.10 shared_ptr 技術與陷阱
1.11 對像池
1.11.1 enable_shared_from_this
1.11.2 弱回調
1.12 替代方案
1.13 心得與小結
1.14 Observer 之謬
第 2 章 線程同步精要
2.1 互斥器（mutex）
2.1.1 隻使用非遞歸的 mutex
2.1.2 死鎖
2.2 條件變量（condition variable）
2.3 不要用讀寫鎖和信號量
2.4 封裝 MutexLock、MutexLockGuard、Condition
2.5 線程安全的 Singleton 實現
2.6 sleep(3) 不是同步原語
2.7 歸納與總結
2.8 借 shared_ptr 實現 copy-on-write
第 3 章 多線程服務器的適用場合與常用編程模型
3.1 進程與線程
3.2 單線程服務器的常用編程模型
3.3 多線程服務器的常用編程模型
3.3.1 one loop per thread
3.3.2 線程池
3.3.3 推薦模式
3.4 進程間通信隻用 TCP
3.5 多線程服務器的適用場合
3.5.1 必須用單線程的場合
3.5.2 單線程程序的優缺點
3.5.3 適用多線程程序的場景
3.6 “多線程服務器的適用場合”例釋與答疑
第 4 章 C 多線程繫統編程精要
4.1 基本線程原語的選用
4.2 C/C 繫統庫的線程安全性
4.3 Linux 上的線程標識
4.4 線程的創建與銷毀的守則
4.4.1 pthread_cancel 與 C
4.4.2 exit(3) 在 C 中不是線程安全的
4.5 善用 __thread 關鍵字
4.6 多線程與 IO
4.7 用 RAII 包裝文件描述符
4.8 RAII 與 fork()
4.9 多線程與 fork()
4.10 多線程與 signal
4.11 Linux 新增繫統調用的啟示
第 5 章 高效的多線程日志
5.1 功能需求
5.2 性能需求
5.3 多線程異步日志
5.4 其他方案
第 2 部分 muduo 網絡庫
第 6 章 muduo 網絡庫簡介
6.1 由來
6.2 安裝
6.3 目錄結構
6.3.1 代碼結構
6.3.2 例子
6.3.3 線程模型
6.4 使用教程
6.4.1 TCP 網絡編程本質論
6.4.2 echo 服務的實現
6.4.3 七步實現 finger 服務
6.5 性能評測
6.5.1 muduo 與 Boost.Asio、libevent2 的吞吐量對比
6.5.2 擊鼓傳花：對比 muduo 與 libevent2 的事件處理效率
6.5.3 muduo 與 Nginx 的吞吐量對比
6.5.4 muduo 與 ZeroMQ 的延遲對比
6.6 詳解 muduo 多線程模型
6.6.1 數獨求解服務器
6.6.2 常見的並發網絡服務程序設計方案
第 7 章 muduo 編程示例
7.1 五個簡單 TCP 示例
7.2 文件傳輸
7.3 Boost.Asio 的聊天服務器
7.3.1 TCP 分包
7.3.2 消息格式
7.3.3 編解碼器 LengthHeaderCodec
7.3.4 服務端的實現
7.3.5 客戶端的實現
7.4 muduo Buffer 類的設計與使用
7.4.1 muduo 的 IO 模型
7.4.2 為什麼 non-blocking 網絡編程中應用層 buffer 是必需的
7.4.3 Buffer 的功能需求
7.4.4 Buffer 的數據結構
7.4.5 Buffer 的操作
7.4.6 其他設計方案
7.4.7 性能是不是問題
7.5 一種自動反射消息類型的 Google Protobuf 網絡傳輸方案
7.5.1 網絡編程中使用 Protobuf 的兩個先決條件
7.5.2 根據 type name 反射自動創建 Message 對像
7.5.3 Protobuf 傳輸格式
7.6 在 muduo 中實現 Protobuf 編解碼器與消息分發器
7.6.1 什麼是編解碼器（codec）
7.6.2 實現 ProtobufCodec
7.6.3 消息分發器（dispatcher）有什麼用
7.6.4 ProtobufCodec 與 ProtobufDispatcher 的綜合運用
7.6.5 ProtobufDispatcher 的兩種實現
7.6.6 ProtobufCodec 和 ProtobufDispatcher 有何意義
7.7 限制服務器的並發連接數
7.7.1 為什麼要限制並發連接數
7.7.2 在 muduo 中限制並發連接數
7.8 定時器
7.8.1 程序中的時間
7.8.2 Linux 時間函數
7.8.3 muduo 的定時器接口
7.8.4 Boost.Asio Timer 示例
7.8.5 Java Netty 示例
7.9 測量兩臺機器的網絡延遲和時間差
7.10 用 timing wheel 踢掉空閑連接
7.10.1 timing wheel 原理
7.10.2 代碼實現與改進
7.11 簡單的消息廣播服務
7.12 “串並轉換”連接服務器及其自動化測試
7.13 socks4a 代理服務器
7.13.1 TCP 中繼器
7.13.2 socks4a 代理服務器
7.13.3 N : 1 與 1 : N 連接轉發
7.14 短址服務
7.15 與其他庫集成
7.15.1 UDNS
7.15.2 c-ares DNS
7.15.3 curl
7.15.4 更多
第 8 章 muduo 網絡庫設計與實現
8.0 什麼都不做的 EventLoop
8.1 Reactor 的關鍵結構
8.1.1 Channel class
8.1.2 Poller class
8.1.3 EventLoop 的改動
8.2 TimerQueue 定時器
8.2.1 TimerQueue class
8.2.2 EventLoop 的改動
8.3 EventLoop::runInLoop() 函數
8.3.1 提高 TimerQueue 的線程安全性
8.3.2 EventLoopThread class
8.4 實現 TCP 網絡庫
8.5 TcpServer 接受新連接
8.5.1 TcpServer class
8.5.2 TcpConnection class
8.6 TcpConnection 斷開連接
8.7 Buffer 讀取數據
8.7.1 TcpConnection 使用 Buffer 作為輸入緩衝
8.7.2 Buffer::readFd()
8.8 TcpConnection 發送數據
8.9 完善 TcpConnection
8.9.1 SIGPIPE
8.9.2 TCP No Delay 和 TCP keepalive
8.9.3 WriteCompleteCallback 和 HighWaterMarkCallback
8.10 多線程 TcpServer
8.11 Connector
8.12 TcpClient
8.13 epoll
8.14 測試程序一覽
第 3 部分 工程實踐經驗談
第 9 章 分布式繫統工程實踐
9.1 我們在技術浪潮中的位置
9.1.1 分布式繫統的本質困難
9.1.2 分布式繫統是個險惡的問題
9.2 分布式繫統的可靠性淺說
9.2.1 分布式繫統的軟件不要求 7 × 24 可靠
9.2.2 “能隨時重啟進程”作為程序設計目標
9.3 分布式繫統中心跳協議的設計
9.4 分布式繫統中的進程標識
9.4.1 錯誤做法
9.4.2 正確做法
9.4.3 TCP 協議的啟示
9.5 構建易於維護的分布式程序
9.6 為繫統演化做準備
9.6.1 可擴展的消息格式
9.6.2 反面教材：ICE 的消息打包格式
9.7 分布式程序的自動化回歸測試
9.7.測試的能與不能
9.7.2 分布式繫統測試的要點
9.7.3 分布式繫統的抽像觀點
9.7.4 一種自動化的回歸測試方案
9.7.5 其他用處
9.8 分布式繫統部署、監控與進程管理的幾重境界
9.8.1 境界 1：全手工操作
9.8.2 境界 2：使用零散的自動化腳本和第三方組件
9.8.3 境界 3：自制機群管理繫統，集中化配置
9.8.4 境界 4：機群管理與 naming service 結合
第 10 章 C 編譯鏈接模型精要
10.1 C 語言的編譯模型及其成因
10.1.1 為什麼 C 語言需要預處理
10.1.2 C 語言的編譯模型
10.2 C 的編譯模型
10.2.1 單遍編譯
10.2.2 前向聲明
10.3 C 鏈接（linking）
10.3.1 函數重載
10.3.2 inline 函數
10.3.3 模板
10.3.4 虛函數
10.4 工程項目中頭文件的使用規則
10.4.1 頭文件的害處
10.4.2 頭文件的使用規則
10

本書主要講述采用現代C 在x86-64 Linux 上編寫多線程TCP 網絡服務程序的主流常規技術，這也是我對過去5 年編寫生產環境下的多線程服務端程序的經驗總結。本書重點講解多線程網絡服務器的一種IO 模型，即one loop per thread。這是一種適應性較強的模型，也是Linux 下以native 語言編寫用戶態高性能網絡程序成熟的模式，掌握之後可順利地開發各類常見的服務端網絡應用程序。本書以muduo網絡庫為例，講解這種編程模型的使用方法及注意事項。
muduo 是一個基於非阻塞IO 和事件驅動的現代C 網絡庫，原生支持oneloop per thread 這種IO 模型。muduo 適合開發Linux 下的面向業務的多線程服務端網絡應用程序，其中“面向業務的網絡編程”的定義見附錄A。“現代C ”指的不是C 11 新標準，而是2005 年TR1 發布之後的C 語言和庫。與傳統C 相比，現代C 的變化主要有兩方面：資源管理（見第1 章）與事件回調（見第449 頁）。
本書不是多線程編程教程，也不是網絡編程教程，更不是C 教程。讀者應該已經大致讀過《UNIX 環境高級編程》、《UNIX 網絡編程》、《C Primer》或與之內容相近的書籍。本書不談C 11，因為目前（2012 年）主流的Linux 服務端發行版的g 版本都還停留在4.4，C 11 進入實用尚需一段時日。
本書適用的硬件環境是主流x86-64 服務器，多路多核CPU、幾十GB 內存、千兆以太網互聯。除了第5 章講診斷日志之外，本書不涉及文件IO。
本書分為四大部分，第1 部分“C 多線程繫統編程”考察多線程下的對像生命期管理、線程同步方法、多線程與C 的結合、高效的多線程日志等。第2 部分“muduo 網絡庫”介紹使用現成的非阻塞網絡庫編寫網絡應用程序的方法，以及muduo 的設計與實現。第3 部分“工程實踐經驗談”介紹分布式繫統的工程化開發方法和C 在工程實踐中的功能特性取舍。第4 部分“附錄”分享網絡編程和C 語言的學習經驗。
本書的宗旨是貴精不貴多。掌握兩種基本的同步原語就可以滿足各種多線程同步的功能需求，還能寫出更易用的同步設施。掌握一種進程間通信方式和一種多線程網絡編程模型就足以應對日常開發任務，編寫運行於公司內網環境的分布式服務繫統。（本書不涉及分布式存儲繫統，也不涉及UDP。）
陳碩
中國·香港

附錄A

談一談網絡編程學習經驗

本文談一談我在學習網絡編程方面的一些個人經驗。“網絡編程”這個術語的範圍很廣，本文指用Sockets API開發基於TCP/IP 的網絡應用程序，具體定義見§A.1.5 “網絡編程的各種任務角色”。

受限於本人的經歷和經驗，本附錄的適應範圍是：

o x86-64 Linux 服務端網絡編程，直接或間接使用Sockets API。

o 公司內網。不一定是局域網，但總體位於公司防火牆之內，環境可控。

本文可能不適合：

o PC 客戶端網絡編程，程序運行在客戶的PC 上，環境多變且不可控。

o Windows 網絡編程。

o 面向公網的服務程序。

o 高性能網絡服務器。

本文分兩個部分：

1. 網絡編程的一些“胡思亂想”，以自問自答的形式談談我對這一領域的認識。

2. 幾本必看的書，基本上還是W. Richard Stevents 的那幾本。

另外，本文沒有特別說明時均暗指TCP 協議，“連接”是“TCP 連接”，“服務

端”是“TCP 服務端”。

網絡編程的一些“胡思亂想”

以下大致列出我對網絡編程的一些想法，前後無關聯。

網絡編程是什麼

網絡編程是什麼？是熟練使用Sockets API 嗎？說實話，在實際項目裡我隻用過

兩次Sockets API，其他時候都是使用封裝好的網絡庫。

次是2005 年在學校做一個羽毛球賽場計分繫統：我用C# 編寫運行在PC上的軟件，負責比分的顯示；再用C#寫了運行在PDA 上的計分界面，記分員拿著PDA 記錄比分；這兩部分程序通過TCP協議相互通信。這其實是個簡單的分布式繫統，體育館有幾片場地，每個場地都有一名拿PDA 的記分員，每個場地都有兩臺顯示比分的PC（顯示器是42 寸平板電視，放在場地的對角，這樣兩邊看臺的觀眾都能看到比分）。這兩臺PC的功能不完全一樣，一臺隻負責顯示當前比分，另一臺還要負責與PDA 通信，並更新數據庫裡的比分信息。此外，還有一臺PC負責周期性地從數據庫讀出全部7 片場地的比分，顯示在體育館牆上的大屏幕上。這臺PC上還運行著一個程序，負責生成比分數據的靜態頁面，通過FTP上傳發布到某門戶網站的體育頻道。繫統中還有一個錄入賽程（參賽隊、運動員、出場順序等）數據庫的程序，運行在數據庫服務器上。算下來整個繫統有十來個程序，運行在二十多臺設備（PC和PDA）上，還要考慮可靠性，避免single point of failure。

這是我次寫實際項目中的網絡程序，當時寫下來的感覺是像寫命令行與用戶交互的程序：程序在命令行輸出一句提示語，等待客戶輸入一句話，然後處理客戶輸入，再輸出下一句提示語，如此循環。隻不過這裡的“客戶”不是人，而是另一個程序。在建立好TCP連接之後，雙方的程序都是read/write 循環（為求簡單，我用的是blocking 讀寫），直到有一方斷開連接。

第二次是2010 年編寫muduo 網絡庫，我再次拿起了Sockets API，寫了一個基於Reactor 模式的C 網絡庫。寫這個庫的目的之一就是想讓日常的網絡編程從Sockets API的瑣碎細節中解脫出來，讓程序員專注於業務邏輯，把時間用在刀刃上。muduo網絡庫的示例代碼包含了幾十個網絡程序，這些示例程序都沒有直接使用Sockets API。

在此之外，無論是實習還是工作，雖然我寫的程序都會通過TCP 協議與其他程序打交道，但我沒有直接使用過SocketsAPI。對於TCP 網絡編程，我認為核心是處理“三個半事件”，見§6.4.1 “TCP網絡編程本質論”。程序員的主要工作是在事件處理函數中實現業務邏輯，而不是和Sockets API“較勁”。

這裡還是沒有說清楚“網絡編程”是什麼，請繼續閱讀後文§A.1.5“網絡編程的各種任務角色”。

學習網絡編程有用嗎

以上說的是比較底層的網絡編程，程序代碼直接面對從TCP 或UDP收到的數據以及構造數據包發出去。在實際工作中，另一種常見的情況是通過各種clientlibrary來與服務端打交道，或者在現成的框架中填空來實現server，或者采用更上層的通信方式。比如用libmemcached與memcached 打交道，使用libpq 來與PostgreSQL 打交道，編寫Servlet 來響應HTTP請求，使用某種RPC與其他進程通信，等等。這些情況都會發生網絡通信，但不一定算作“網絡編程”。如果你的工作是前面列舉的這些，學習TCP/IP網絡編程還有用嗎？

我認為還是有必要學一學，至少在troubleshooting 的時候有用。無論如何，這些library 或framework都會調用底層的Sockets API 來實現網絡功能。當你的程序遇到一個線上問題時，如果你熟悉SocketsAPI，那麼從strace 不難發現程序卡在哪裡，盡管可能你沒有直接調用這些Sockets API。另外，熟悉TCP/IP協議、會用tcpdump 也非常有助於分析解決線上網絡服務問題。

在什麼平臺上學習網絡編程

對於服務端網絡編程，我建議在Linux 上學習。

如果在10 年前，這個問題的答案或許是FreeBSD，因為FreeBSD“根正苗紅”，在2000年那一次互聯網浪潮中扮演了重要角色，是很多公司的免費服務器操作繫統。2000 年那會兒Linux 還遠未成熟，連epoll都還沒有實現。（FreeBSD 在2001年發布4.1 版，加入了kqueue，從此C10k 不是問題。）

10 年後的今天，事情起了一些變化，Linux 成為市場份額的服務器操作繫統。在Linux這種大眾繫統上學網絡編程，遇到什麼問題會比較容易解決。因為用的人多，你遇到的問題別人多半也遇到過；同樣因為用的人多，如果真的有什麼內核bug，很快就會得到修復，至少有workaround 的辦法。如果用別的繫統，可能一個問題發到論壇上半個月都不會有人理。從內核源碼的風格看，FreeBSD更干淨整潔，注釋到位，但是無奈它的市場份額遠不如Linux，學習Linux 是更好的技術投資。

可移植性重要嗎

寫網絡程序要不要考慮移植性？要不要跨平臺？這取決於項目需要，如果貴公司做的程序要賣給其他公司，而對方可能使用Windows、Linux、FreeBSD、Solaris、AIX、HP-UX等等操作繫統，這時候當然要考慮移植性。如果編寫公司內部的服務器上用的網絡程序，那麼大可隻關注一個平臺，比如Linux。因為編寫和維護可移植的網絡程序的代價相當高，平臺間的差異可能遠比想像中大，即便是POSIX繫統之間也有不小的差異（比如Linux 沒有SO_NOSIGPIPE 選項，Linux 的pipe(2) 是單向的，而FreeBSD是雙向的），錯誤的返回碼也大不一樣。

我就不打算把muduo 往Windows或其他操作繫統移植。如果需要編寫可移植的網絡程序，我寧願用libevent、libuv、Java Netty這樣現成的庫，把“髒活、累活”留給別人。

網絡編程的各種任務角色

計算機網絡是個big topic，涉及很多人物和角色，既有開發人員，也有運維人員。比方說：公司內部兩臺機器之間ping不通，通常由網絡運維人員解決，看看是布線有問題還是路由器設置不對；兩臺機器能ping通，但是程序連不上，經檢查是本機防火牆設置有問題，通常由繫統管理員解決；兩臺機器能連上，但是丟包很嚴重，發現是網卡或者交換機的網口故障，由硬件維修人員解決；兩臺機器的程序能連上，但是偶爾發過去的請求得不到響應，通常是程序bug，應該由開發人員解決。

面向業務的網絡編程的特點

與通用的網絡服務器不同，面向公司業務的專用網絡程序有其自身的特點。

業務邏輯比較復雜，而且時常變化 如果寫一個HTTP 服務器，在大致實現HTTP 1.1標準之後，程序的主體功能一般不會有太大的變化，程序員會把時間放在性能調優和bug修復上。而開發針對公司業務的專用程序時，功能說明書（spec）很可能不如HTTP 1.1標準那麼細致明確。更重要的是，程序是快速演化的。以即時聊天工具的後臺服務器為例，可能版隻支持在線聊天；幾個月之後發布第二版，支持離線消息；又過了幾個月，第三版支持隱身聊天；隨後，第四版支持上傳頭像；如此等等。這要求程序員能快速響應新的業務需求，公司纔能保持競爭力。由於業務時常變化（假設每月一次版本升級），也會降低服務程序連續運行時間的要求。相反，我們要設計一套流程，通過輪流重啟服務器來完成平滑升級（§9.2.2）。

不一定需要遵循公認的通信協議標準比方說網遊服務器就沒什麼協議標準，反正客戶端和服務端都是本公司開發的，如果發現目前的協議設計有問題，兩邊一起改就行了。由於可以自己設計協議，因此我們可以繞開一些性能難點，簡化程序結構。比方說，對於多線程的服務程序，如果用短連接TCP協議，為了優化性能通常要精心設計accept新連接的機制2，避免驚群並減少上下文切換。但是如果改用長連接，用簡單的單線程accept 就行了。

程序結構沒有定論 對於高並發大吞吐的標準網絡服務，一般采用單線程事件驅動的方式開發，比如HAProxy、lighttpd等都是這個模式。但是對於專用的業務繫統，其業務邏輯比較復雜，占用較多的CPU資源，這種單線程事件驅動方式不見得能發揮現在多核處理器的優勢。這留給程序員比較大的自由發揮空間，做好了“橫掃千軍”，做爛了一敗塗地。我認為目前oneloop per thread 是通用性較高的一種程序結構，能發揮多核的優勢，見§3.3 和§6.6。

性能評判的標準不同 如果開發httpd 這樣的通用服務，必然會和開源的Nginx、lighttpd等高性能服務器比較，程序員要投入相當的精力去優化程序，纔能在市場上占有一席之地。而面向業務的專用網絡程序不一定是IObound，也不一定有開源的實現以供對比性能，優化方向也可能不同。程序員通常更加注重功能的穩定性與開發的便捷性。性能隻要一代比一代強即可。

網絡編程起到支撐作用，但不處於主導地位程序員的主要工作是實現業務邏輯，而不隻是實現網絡通信協議。這要求程序員深入理解業務。程序的性能瓶頸不一定在網絡上，瓶頸有可能是CPU、DiskIO、數據庫等，這時優化網絡方面的代碼並不能提高整體性能。隻有對所在的領域有深入的了解，明白各種因素的權衡（trade-off），纔能做出一些有針對性的優化。現在的機器上，簡單的並發長連接echo服務程序不用特別優化就做到十多萬qps，但是如果每個業務請求需要1ms密集計算，在8 核機器上充其量能達到8 000 qps，優化IO 不如去優化業務計算（如果投入產出合算的話）。

幾個術語

互聯網上的很多“口水戰”是由對同一術語的不同理解引起的，比如我寫的《多線程服務器的適用場合》3，就曾經被人說是“掛羊頭賣狗肉”，因為這篇文章中舉的master例子“根本就算不上是個網絡服務器。因為它的瓶頸根本就跟網絡無關。”

網絡服務器“網絡服務器”這個術語確實含義模糊，到底指硬件還是軟件？到底是服務於網絡本身的機器（交換機、路由器、防火牆、NAT），還是利用網絡為其他人或程序提供服務的機器（打印服務器、文件服務器、郵件服務器）？每個人根據自己熟悉的領域，可能會有不同的解讀。比方說，或許有人認為隻有支持高並發、高吞吐量的纔算是網絡服務器。

為了避免無謂的爭執，我隻用“網絡服務程序”或者“網絡應用程序”這種含義明確的術語。“開發網絡服務程序”通常不會造成誤解。

客戶端？服務端？ 在TCP網絡編程中，客戶端和服務端很容易區分，主動發起連接的是客戶端，被動接受連接的是服務端。當然，這個“客戶端”本身也可能是個後臺服務程序，HTTPproxy 對HTTP server 來說就是個客戶端。

客戶端編程？服務端編程？ 但是“服務端編程”和“客戶端編程”就不那麼好區分了。比如Webcrawler，它會主動發起大量連接，扮演的是HTTP 客戶端的角色，但似乎應該歸入“服務端編程”。又比如寫一個HTTPproxy，它既會扮演服務端--被動接受Web browser 發起的連接，也會扮演客戶端--主動向HTTP server發起連接，它究竟算服務端還是客戶端？我猜大多數人會把它歸入服務端編程。

那麼究竟如何定義“服務端編程”？

服務端編程需要處理大量並發連接？也許是，也許不是。比如雲風在一篇介紹網遊服務器的博客4中就談到，網遊中用到的“連接服務器”需要處理大量連接，而“邏輯服務器”隻有一個外部連接。那麼開發這種網遊“邏輯服務器”算服務端編程還是客戶端編程呢？又比如機房的服務進程監控軟件，並發數跟機器數成正比，至多也就是兩三千的並發連接。（再大規模就超出本書的範圍了。）

我認為，“服務端網絡編程”指的是編寫沒有用戶界面的長期運行的網絡程序，程序默默地運行在一臺服務器上，通過網絡與其他程序打交道，而不必和人打交道。與之對應的是客戶端網絡程序，要麼是短時間運行，比如wget；要麼是有用戶界面（無論是字符界面還是圖形界面）。本文主要談服務端網絡編程。