多线程服务器的经常使用编程模型

时间 2019-11-08

标签多线程服务器经常使用编程模型栏目 Java 繁體版

原文原文链接

原文地址：http://www.cnblogs.com/Solstice/archive/2010/02/12/multithreaded_server.htmlhtml

多线程服务器的经常使用编程模型

多线程服务器的经常使用编程模型nginx

陈硕 (giantchen_AT_gmail)程序员

Blog.csdn.net/Solstice算法

2010 Feb 12数据库

本文 PDF 版下载： http://files.cppblog.com/Solstice/multithreaded_server.pdf编程

本文主要讲我我的在多线程开发方面的一些粗浅经验。总结了一两种经常使用的线程模型，概括了进程间通信与线程同步的最佳实践，以期用简单规范的方式开发多线程程序。数组

文中的“多线程服务器”是指运行在 Linux 操做系统上的独占式网络应用程序。硬件平台为 Intel x64 系列的多核 CPU，单路或双路 SMP 服务器（每台机器一共拥有四个核或八个核，十几 GB 内存），机器之间用百兆或千兆以太网链接。这大概是目前民用 PC 服务器的主流配置。安全

本文不涉及 Windows 系统，不涉及人机交互界面（不管命令行或图形）；不考虑文件读写（往磁盘写 log 除外），不考虑数据库操做，不考虑 Web 应用；不考虑低端的单核主机或嵌入式系统，不考虑手持式设备，不考虑专门的网络设备，不考虑高端的 >=32 核 Unix 主机；只考虑 TCP，不考虑 UDP，也不考虑除了局域网络以外的其余数据收发方式（例如串并口、USB口、数据采集板卡、实时控制等）。性能优化

有了以上这么多限制，那么我将要谈的“网络应用程序”的基本功能能够概括为“收到数据，算一算，再发出去”。在这个简化了的模型里，彷佛看不出用多线程的必要，单线程应该也能作得很好。“为何须要写多线程程序”这个问题容易引起口水战，我放到另外一篇博客里讨论。请容许我先假定“多线程编程”这一背景。服务器

“服务器”这个词有时指程序，有时指进程，有时指硬件（不管虚拟的或真实的），请注意按上下文区分。另外，本文不考虑虚拟化的场景，当我说“两个进程不在同一台机器上”，指的是逻辑上不在同一个操做系统里运行，虽然物理上可能位于同一机器虚拟出来的两台“虚拟机”上。

本文假定读者已经有多线程编程的知识与经验，这不是一篇入门教程。

本文承蒙 Milo Yip 先生审读，在此深表谢意。固然，文中任何错误责任均在我。

1 进程与线程 2

2 典型的单线程服务器编程模型 3

3 典型的多线程服务器的线程模型 3

One loop per thread 4

封装 MutexLock、MutexLockGuard 和 Condition 11

线程安全的 Singleton 实现 14

概括 15

7 总结 15

后文预览：Sleep 反模式 16

1 进程与线程

“进程/process”是操做里最重要的两个概念之一（另外一个是文件），粗略地讲，一个进程是“内存中正在运行的程序”。本文的进程指的是 Linux 操做系统经过 fork() 系统调用产生的那个东西，或者 Windows 下 CreateProcess() 的产物，不是 Erlang 里的那种轻量级进程。

每一个进程有本身独立的地址空间 (address space)，“在同一个进程”仍是“不在同一个进程”是系统功能划分的重要决策点。Erlang 书把“进程”比喻为“人”，我以为十分精当，为咱们提供了一个思考的框架。

每一个人有本身的记忆 (memory)，人与人经过谈话（消息传递）来交流，谈话既能够是面谈（同一台服务器），也能够在电话里谈（不一样的服务器，有网络通讯）。面谈和电话谈的区别在于，面谈能够当即知道对方死否死了（crash, SIGCHLD），而电话谈只能经过周期性的心跳来判断对方是否还活着。

有了这些比喻，设计分布式系统时能够采起“角色扮演”，团队里的几我的各自扮演一个进程，人的角色由进程的代码决定（管登录的、管消息分发的、管买卖的等等）。每一个人有本身的记忆，但不知作别人的记忆，要想知作别人的见解，只能经过交谈。（暂不考虑共享内存这种 IPC。）而后就能够思考容错（万一有人忽然死了）、扩容（新人中途加进来）、负载均衡（把 a 的活儿挪給 b 作）、退休（a 要修复 bug，先别给他派新活儿，等他作完手上的事情就把他重启）等等各类场景，十分便利。

“线程”这个概念大概是在 1993 年之后才慢慢流行起来的，距今不过十余年，比不得有 40 年光辉历史的 Unix 操做系统。线程的出现给 Unix 添了很多乱，不少 C 库函数（strtok(), ctime()）不是线程安全的，须要从新定义；signal 的语意也大为复杂化。据我所知，最先支持多线程编程的（民用）操做系统是 Solaris 2.2 和 Windows NT 3.1，它们均发布于 1993 年。随后在 1995 年，POSIX threads 标准确立。

线程的特色是共享地址空间，从而能够高效地共享数据。一台机器上的多个进程能高效地共享代码段（操做系统能够映射为一样的物理内存），但不能共享数据。若是多个进程大量共享内存，等因而把多进程程序当成多线程来写，掩耳盗铃。

“多线程”的价值，我认为是为了更好地发挥对称多路处理 (SMP) 的效能。在 SMP 以前，多线程没有多大价值。Alan Cox 说过 A computer is a state machine. Threads are for people who can't program state machines. （计算机是一台状态机。线程是给那些不能编写状态机程序的人准备的。）若是只有一个执行单元，一个 CPU，那么确实如 Alan Cox 所说，按状态机的思路去写程序是最高效的，这正好也是下一节展现的编程模型。

2 典型的单线程服务器编程模型

UNP3e 对此有很好的总结（第 6 章：IO 模型，第 30 章：客户端/服务器设计范式），这里再也不赘述。据我了解，在高性能的网络程序中，使用得最为普遍的恐怕要数“non-blocking IO + IO multiplexing”这种模型，即 Reactor 模式，我知道的有：

lighttpd，单线程服务器。（nginx 估计与之相似，待查）
libevent/libev
ACE，Poco C++ libraries（QT 待查）
Java NIO (Selector/SelectableChannel), Apache Mina, Netty (Java)
POE (Perl)
Twisted (Python)

相反，boost::asio 和 Windows I/O Completion Ports 实现了 Proactor 模式，应用面彷佛要窄一些。固然，ACE 也实现了 Proactor 模式，不表。

在“non-blocking IO + IO multiplexing”这种模型下，程序的基本结构是一个事件循环 (event loop)：（代码仅为示意，没有完整考虑各类状况）

 
         while  
         (!done) 
        
         { 
        
         int  
         timeout_ms = max(1000, getNextTimedCallback()); 
        
         int  
         retval = ::poll(fds, nfds, timeout_ms); 
        
         if  
         (retval < 0) { 
        
         处理错误 
        
         }  
         else  
         { 
        
         处理到期的 timers 
        
         if  
         (retval > 0) { 
        
         处理 IO 事件 
        
         } 
        
         } 
        
         }

固然，select(2)/poll(2) 有不少不足，Linux 下可替换为 epoll，其余操做系统也有对应的高性能替代品（搜 c10k problem）。

Reactor 模型的优势很明显，编程简单，效率也不错。不只网络读写能够用，链接的创建（connect/accept）甚至 DNS 解析均可以用非阻塞方式进行，以提升并发度和吞吐量 (throughput)。对于 IO 密集的应用是个不错的选择，Lighttpd 便是这样，它内部的 fdevent 结构十分精妙，值得学习。（这里且不考虑用阻塞 IO 这种次优的方案。）

固然，实现一个优质的 Reactor 不是那么容易，我也没有用过坊间开源的库，这里就不推荐了。

3 典型的多线程服务器的线程模型

这方面我能找到的文献很少，大概有这么几种：

1. 每一个请求建立一个线程，使用阻塞式 IO 操做。在 Java 1.4 引入 NIO 以前，这是 Java 网络编程的推荐作法。惋惜伸缩性不佳。

2. 使用线程池，一样使用阻塞式 IO 操做。与 1 相比，这是提升性能的措施。

3. 使用 non-blocking IO + IO multiplexing。即 Java NIO 的方式。

4. Leader/Follower 等高级模式

在默认状况下，我会使用第 3 种，即 non-blocking IO + one loop per thread 模式。
http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#THREADS_AND_COROUTINES

One loop per thread

此种模型下，程序里的每一个 IO 线程有一个 event loop （或者叫 Reactor），用于处理读写和定时事件（不管周期性的仍是单次的），代码框架跟第 2 节同样。

这种方式的好处是：

线程数目基本固定，能够在程序启动的时候设置，不会频繁建立与销毁。
能够很方便地在线程间调配负载。

event loop 表明了线程的主循环，须要让哪一个线程干活，就把 timer 或 IO channel (TCP connection) 注册到那个线程的 loop 里便可。对实时性有要求的 connection 能够单独用一个线程；数据量大的 connection 能够独占一个线程，并把数据处理任务分摊到另几个线程中；其余次要的辅助性 connections 能够共享一个线程。

对于 non-trivial 的服务端程序，通常会采用 non-blocking IO + IO multiplexing，每一个 connection/acceptor 都会注册到某个 Reactor 上，程序里有多个 Reactor，每一个线程至多有一个 Reactor。

多线程程序对 Reactor 提出了更高的要求，那就是“线程安全”。要容许一个线程往别的线程的 loop 里塞东西，这个 loop 必须得是线程安全的。

线程池

不过，对于没有 IO 光有计算任务的线程，使用 event loop 有点浪费，我会用有一种补充方案，即用 blocking queue 实现的任务队列(TaskQueue)：

 
         blocking_queue<boost::function< 
         void 
         ()> > taskQueue;   
         // 线程安全的阻塞队列 
        
         void  
         worker_thread() 
        
         { 
        
         while  
         (!quit) { 
        
         boost::function< 
         void 
         ()> task = taskQueue.take();   
         // this blocks 
        
         task();   
         // 在产品代码中须要考虑异常处理 
        
         } 
        
         }

用这种方式实现线程池特别容易：

 
         // 启动容量为 N 的线程池： 
        
         int  
         N = num_of_computing_threads; 
        
         for  
         ( 
         int  
         i = 0; i < N; ++i) { 
        
         create_thread(&worker_thread);   
         // 伪代码：启动线程 
        
         }

使用起来也很简单：

 
         boost::function< 
         void 
         ()> task = boost::bind(&Foo::calc,  
         this 
         ); 
        
         taskQueue.post(task);

上面十几行代码就实现了一个简单的固定数目的线程池，功能大概至关于 Java 5 的 ThreadPoolExecutor 的某种“配置”。固然，在真实的项目中，这些代码都应该封装到一个 class 中，而不是使用全局对象。另外须要注意一点：Foo 对象的生命期，个人另外一篇博客《当析构函数遇到多线程——C++ 中线程安全的对象回调》详细讨论了这个问题
http://blog.csdn.net/Solstice/archive/2010/01/22/5238671.aspx

除了任务队列，还能够用 blocking_queue<T> 实现数据的消费者-生产者队列，即 T 的是数据类型而非函数对象，queue 的消费者(s)从中拿到数据进行处理。这样作比 task queue 更加 specific 一些。

blocking_queue<T> 是多线程编程的利器，它的实现可参照 Java 5 util.concurrent 里的 (Array|Linked)BlockingQueue，一般 C++ 能够用 deque 来作底层的容器。Java 5 里的代码可读性很高，代码的基本结构和教科书一致（1 个 mutex，2 个 condition variables），健壮性要高得多。若是不想本身实现，用现成的库更好。（我没有用过免费的库，这里就不乱推荐了，有兴趣的同窗能够试试 Intel Threading Building Blocks 里的 concurrent_queue<T>。）

概括

总结起来，我推荐的多线程服务端编程模式为：event loop per thread + thread pool。

event loop 用做 non-blocking IO 和定时器。
thread pool 用来作计算，具体能够是任务队列或消费者-生产者队列。

以这种方式写服务器程序，须要一个优质的基于 Reactor 模式的网络库来支撑，我只用过 in-house 的产品，无从比较并推荐市面上常见的 C++ 网络库，抱歉。

程序里具体用几个 loop、线程池的大小等参数须要根据应用来设定，基本的原则是“阻抗匹配”，使得 CPU 和 IO 都能高效地运做，具体的考虑点容我之后再谈。

这里没有谈线程的退出，留待下一篇 blog“多线程编程反模式”探讨。

此外，程序里或许还有个别执行特殊任务的线程，好比 logging，这对应用程序来讲基本是不可见的，可是在分配资源（CPU 和 IO）的时候要算进去，以避免高估了系统的容量。

4 进程间通讯与线程间通讯

Linux 下进程间通讯 (IPC) 的方式数不胜数，光 UNPv2 列出的就有：pipe、FIFO、POSIX 消息队列、共享内存、信号 (signals) 等等，更没必要说 Sockets 了。同步原语 (synchronization primitives) 也不少，互斥器 (mutex)、条件变量 (condition variable)、读写锁 (reader-writer lock)、文件锁 (Record locking)、信号量 (Semaphore) 等等。

如何选择呢？根据个人我的经验，贵精不贵多，认真挑选三四样东西就能彻底知足个人工做须要，并且每样我都能用得很熟,，不容易犯错。

5 进程间通讯

进程间通讯我首选 Sockets（主要指 TCP，我没有用过 UDP，也不考虑 Unix domain 协议），其最大的好处在于：能够跨主机，具备伸缩性。反正都是多进程了，若是一台机器处理能力不够，很天然地就能用多台机器来处理。把进程分散到同一局域网的多台机器上，程序改改 host:port 配置就能继续用。相反，前面列出的其余 IPC 都不能跨机器（好比共享内存效率最高，但再怎么着也不能高效地共享两台机器的内存），限制了 scalability。

在编程上，TCP sockets 和 pipe 都是一个文件描述符，用来收发字节流，均可以 read/write/fcntl/select/poll 等。不一样的是，TCP 是双向的，pipe 是单向的 (Linux)，进程间双向通信还得开两个文件描述符，不方便；并且进程要有父子关系才能用 pipe，这些都限制了 pipe 的使用。在收发字节流这一通信模型下，没有比 sockets/TCP 更天然的 IPC 了。固然，pipe 也有一个经典应用场景，那就是写 Reactor/Selector 时用来异步唤醒 select (或等价的 poll/epoll) 调用（Sun JVM 在 Linux 就是这么作的）。

TCP port 是由一个进程独占，且操做系统会自动回收（listening port 和已创建链接的 TCP socket 都是文件描述符，在进程结束时操做系统会关闭全部文件描述符）。这说明，即便程序意外退出，也不会给系统留下垃圾，程序重启以后能比较容易地恢复，而不须要重启操做系统（用跨进程的 mutex 就有这个风险）。还有一个好处，既然 port 是独占的，那么能够防止程序重复启动（后面那个进程抢不到 port，天然就无法工做了），形成意料以外的结果。

两个进程经过 TCP 通讯，若是一个崩溃了，操做系统会关闭链接，这样另外一个进程几乎马上就能感知，能够快速 failover。固然，应用层的心跳也是必不可少的，我之后在讲服务端的日期与时间处理的时候还会谈到心跳协议的设计。

与其余 IPC 相比，TCP 协议的一个天然好处是“可记录可重现”，tcpdump/Wireshark 是解决两个进程间协议/状态争端的好帮手。

另外，若是网络库带“链接重试”功能的话，咱们能够不要求系统里的进程以特定的顺序启动，任何一个进程都能单独重启，这对开发牢靠的分布式系统意义重大。

使用 TCP 这种字节流 (byte stream) 方式通讯，会有 marshal/unmarshal 的开销，这要求咱们选用合适的消息格式，准确地说是 wire format。这将是我下一篇 blog 的主题，目前我推荐 Google Protocol Buffers。

有人或许会说，具体问题具体分析，若是两个进程在同一台机器，就用共享内存，不然就用 TCP，好比 MS SQL Server 就同时支持这两种通讯方式。我问，是否值得为那么一点性能提高而让代码的复杂度大大增长呢？TCP 是字节流协议，只能顺序读取，有写缓冲；共享内存是消息协议，a 进程填好一块内存让 b 进程来读，基本是“停等”方式。要把这两种方式揉到一个程序里，须要建一个抽象层，封装两种 IPC。这会带来不透明性，而且增长测试的复杂度，并且万一通讯的某一方崩溃，状态 reconcile 也会比 sockets 麻烦。为我所不取。再说了，你舍得让几万块买来的 SQL Server 和你的程序分享机器资源吗？产品里的数据库服务器每每是独立的高配置服务器，通常不会同时运行其余占资源的程序。

TCP 自己是个数据流协议，除了直接使用它来通讯，还能够在此之上构建 RPC/REST/SOAP 之类的上层通讯协议，这超过了本文的范围。另外，除了点对点的通讯以外，应用级的广播协议也是很是有用的，能够方便地构建可观可控的分布式系统。

本文不具体讲 Reactor 方式下的网络编程，其实这里边有不少值得注意的地方，好比带 back off 的 retry connecting，用优先队列来组织 timer 等等，留做之后分析吧。

6 线程间同步

线程同步的四项原则，按重要性排列：

1. 首要原则是尽可能最低限度地共享对象，减小须要同步的场合。一个对象能不暴露给别的线程就不要暴露；若是要暴露，优先考虑 immutable 对象；实在不行才暴露可修改的对象，并用同步措施来充分保护它。

2. 其次是使用高级的并发编程构件，如 TaskQueue、Producer-Consumer Queue、CountDownLatch 等等；

3. 最后不得已必须使用底层同步原语 (primitives) 时，只用非递归的互斥器和条件变量，偶尔用一用读写锁；

4. 不本身编写 lock-free 代码，不去凭空猜想“哪一种作法性能会更好”，好比 spin lock vs. mutex。

前面两条很容易理解，这里着重讲一下第 3 条：底层同步原语的使用。

互斥器 (mutex)

互斥器 (mutex) 恐怕是使用得最多的同步原语，粗略地说，它保护了临界区，一个时刻最多只能有一个线程在临界区内活动。（请注意，我谈的是 pthreads 里的 mutex，不是 Windows 里的重量级跨进程 Mutex。）单独使用 mutex 时，咱们主要为了保护共享数据。我我的的原则是：

用 RAII 手法封装 mutex 的建立、销毁、加锁、解锁这四个操做。
只用非递归的 mutex（即不可重入的 mutex）。
不手工调用 lock() 和 unlock() 函数，一切交给栈上的 Guard 对象的构造和析构函数负责，Guard 对象的生命期正好等于临界区（分析对象在何时析构是 C++ 程序员的基本功）。这样咱们保证在同一个函数里加锁和解锁，避免在 foo() 里加锁，而后跑到 bar() 里解锁。
在每次构造 Guard 对象的时候，思考一路上（调用栈上）已经持有的锁，防止因加锁顺序不一样而致使死锁 (deadlock)。因为 Guard 对象是栈上对象，看函数调用栈就能分析用锁的状况，很是便利。

次要原则有：

不使用跨进程的 mutex，进程间通讯只用 TCP sockets。
加锁解锁在同一个线程，线程 a 不能去 unlock 线程 b 已经锁住的 mutex。（RAII 自动保证）
别忘了解锁。（RAII 自动保证）
不重复解锁。（RAII 自动保证）
必要的时候能够考虑用 PTHREAD_MUTEX_ERRORCHECK 来排错

用 RAII 封装这几个操做是通行的作法，这几乎是 C++ 的标准实践，后面我会给出具体的代码示例，相信你们都已经写过或用过相似的代码了。Java 里的 synchronized 语句和 C# 的 using 语句也有相似的效果，即保证锁的生效期间等于一个做用域，不会因异常而忘记解锁。

Mutex 恐怕是最简单的同步原语，安装上面的几条原则，几乎不可能用错。我本身历来没有违背过这些原则，编码时出现问题都很快能招到并修复。

跑题：非递归的 mutex

谈谈我坚持使用非递归的互斥器的我的想法。

Mutex 分为递归 (recursive) 和非递归(non-recursive)两种，这是 POSIX 的叫法，另外的名字是可重入 (Reentrant) 与非可重入。这两种 mutex 做为线程间 (inter-thread) 的同步工具时没有区别，它们的唯一区别在于：同一个线程能够重复对 recursive mutex 加锁，可是不能重复对 non-recursive mutex 加锁。

首选非递归 mutex，绝对不是为了性能，而是为了体现设计意图。non-recursive 和 recursive 的性能差异其实不大，由于少用一个计数器，前者略快一点点而已。在同一个线程里屡次对 non-recursive mutex 加锁会马上致使死锁，我认为这是它的优势，能帮助咱们思考代码对锁的期求，而且及早（在编码阶段）发现问题。

毫无疑问 recursive mutex 使用起来要方便一些，由于不用考虑一个线程会本身把本身给锁死了，我猜这也是 Java 和 Windows 默认提供 recursive mutex 的缘由。（Java 语言自带的 intrinsic lock 是可重入的，它的 concurrent 库里提供 ReentrantLock，Windows 的 CRITICAL_SECTION 也是可重入的。彷佛它们都不提供轻量级的 non-recursive mutex。）

正由于它方便，recursive mutex 可能会隐藏代码里的一些问题。典型状况是你觉得拿到一个锁就能修改对象了，没想到外层代码已经拿到了锁，正在修改（或读取）同一个对象呢。具体的例子：

 
         std::vector<Foo> foos; 
        
         MutexLock mutex; 
        
         void  
         post( 
         const  
         Foo& f) 
        
         { 
        
         MutexLockGuard lock(mutex); 
        
         foos.push_back(f); 
        
         } 
        
         void  
         traverse() 
        
         { 
        
         MutexLockGuard lock(mutex); 
        
         for  
         ( 
         auto  
         it = foos.begin(); it != foos.end(); ++it) {  
         // 用了 0x 新写法 
        
         it->doit(); 
        
         } 
        
         }

post() 加锁，而后修改 foos 对象； traverse() 加锁，而后遍历 foos 数组。未来有一天，Foo::doit() 间接调用了 post() （这在逻辑上是错误的），那么会颇有戏剧性的：

1. Mutex 是非递归的，因而死锁了。

2. Mutex 是递归的，因为 push_back 可能（但不老是）致使 vector 迭代器失效，程序偶尔会 crash。

这时候就能体现 non-recursive 的优越性：把程序的逻辑错误暴露出来。死锁比较容易 debug，把各个线程的调用栈打出来（(gdb) thread apply all bt），只要每一个函数不是特别长，很容易看出来是怎么死的。（另外一方面支持了函数不要写过长。）或者能够用 PTHREAD_MUTEX_ERRORCHECK 一会儿就能找到错误（前提是 MutexLock 带 debug 选项。）

程序反正要死，不如死得有意义一点，让验尸官的日子好过些。

若是一个函数既可能在已加锁的状况下调用，又可能在未加锁的状况下调用，那么就拆成两个函数：

1. 跟原来的函数同名，函数加锁，转而调用第 2 个函数。

2. 给函数名加上后缀 WithLockHold，不加锁，把原来的函数体搬过来。

就像这样：

 
         void  
         post( 
         const  
         Foo& f) 
        
         { 
        
         MutexLockGuard lock(mutex); 
        
         postWithLockHold(f);   
         // 不用担忧开销，编译器会自动内联的 
        
         } 
        
         // 引入这个函数是为了体现代码做者的意图，尽管 push_back 一般能够手动内联 
        
         void  
         postWithLockHold( 
         const  
         Foo& f) 
        
         { 
        
         foos.push_back(f); 
        
         }

这有可能出现两个问题（感谢水木网友 ilovecpp 提出）：a) 误用了加锁版本，死锁了。b) 误用了不加锁版本，数据损坏了。

对于 a)，仿造前面的办法能比较容易地排错。对于 b)，若是 pthreads 提供 isLocked() 就好办，能够写成：

 
         void  
         postWithLockHold( 
         const  
         Foo& f) 
        
         { 
        
         assert 
         (mutex.isLocked());   
         // 目前只是一个愿望 
        
         // ... 
        
         }

另外，WithLockHold 这个显眼的后缀也让程序中的误用容易暴露出来。

C++ 没有 annotation，不能像 Java 那样给 method 或 field 标上 @GuardedBy 注解，须要程序员本身当心在乎。虽然这里的办法不能一劳永逸地解决所有多线程错误，但能帮上一点是一点了。

我尚未遇到过须要使用 recursive mutex 的状况，我想未来遇到了均可以借助 wrapper 改用 non-recursive mutex，代码只会更清晰。

=== 回到正题 ===

本文这里只谈了 mutex 自己的正确使用，在 C++ 里多线程编程还会遇到其余不少 race condition，请参考拙做《当析构函数遇到多线程——C++ 中线程安全的对象回调》
http://blog.csdn.net/Solstice/archive/2010/01/22/5238671.aspx 。请注意这里的 class 命名与那篇文章有所不一样。我如今认为 MutexLock 和 MutexLockGuard 是更好的名称。

性能注脚：Linux 的 pthreads mutex 采用 futex 实现，没必要每次加锁解锁都陷入系统调用，效率不错。Windows 的 CRITICAL_SECTION 也是相似。

条件变量

条件变量 (condition variable) 顾名思义是一个或多个线程等待某个布尔表达式为真，即等待别的线程“唤醒”它。条件变量的学名叫管程 (monitor)。Java Object 内置的 wait(), notify(), notifyAll() 便是条件变量（它们以容易用错著称）。条件变量只有一种正确使用的方式，对于 wait() 端：

1. 必须与 mutex 一块儿使用，该布尔表达式的读写需受此 mutex 保护

2. 在 mutex 已上锁的时候才能调用 wait()

3. 把判断布尔条件和 wait() 放到 while 循环中

写成代码是：

 
         MutexLock mutex; 
        
         Condition cond(mutex); 
        
         std::deque< 
         int 
         > queue; 
        
         int  
         dequeue() 
        
         { 
        
         MutexLockGuard lock(mutex); 
        
         while  
         (queue.empty()) {   
         // 必须用循环；必须在判断以后再 wait() 
        
         cond.wait();  
         // 这一步会原子地 unlock mutex 并进入 blocking，不会与 enqueue 死锁 
        
         } 
        
         assert 
         (!queue.empty()); 
        
         int  
         top = queue.front(); 
        
         queue.pop_front(); 
        
         return  
         top; 
        
         }

对于 signal/broadcast 端：

1. 不必定要在 mutex 已上锁的状况下调用 signal （理论上）

2. 在 signal 以前通常要修改布尔表达式

3. 修改布尔表达式一般要用 mutex 保护（至少用做 full memory barrier）

写成代码是：

 
         void  
         enqueue( 
         int  
         x) 
        
         { 
        
         MutexLockGuard lock(mutex); 
        
         queue.push_back(x); 
        
         cond.notify(); 
        
         }

上面的 dequeue/enqueue 实际上实现了一个简单的 unbounded BlockingQueue。

条件变量是很是底层的同步原语，不多直接使用，通常都是用它来实现高层的同步措施，如 BlockingQueue 或 CountDownLatch。

读写锁与其余

读写锁 (Reader-Writer lock)，读写锁是个优秀的抽象，它明确区分了 read 和 write 两种行为。须要注意的是，reader lock 是可重入的，writer lock 是不可重入（包括不可提高 reader lock）的。这正是我说它“优秀”的主要缘由。

遇到并发读写，若是条件合适，我会用《借 shared_ptr 实现线程安全的 copy-on-write》http://blog.csdn.net/Solstice/archive/2008/11/22/3351751.aspx 介绍的办法，而不用读写锁。固然这不是绝对的。

信号量 (Semaphore)，我没有遇到过须要使用信号量的状况，无从谈及我的经验。

说一句大逆不道的话，若是程序里须要解决如“哲学家就餐”之类的复杂 IPC 问题，我认为应该首先考察几个设计，为何线程之间会有如此复杂的资源争抢（一个线程要同时抢到两个资源，一个资源能够被两个线程争夺）？能不能把“想吃饭”这个事情专门交给一个为各位哲学家分派餐具的线程来作，而后每一个哲学家等在一个简单的 condition variable 上，到时间了有人通知他去吃饭？从哲学上说，教科书上的解决方案是平权，每一个哲学家有本身的线程，本身去拿筷子；我宁愿用集权的方式，用一个线程专门管餐具的分配，让其余哲学家线程拿个号等在食堂门口好了。这样不损失多少效率，却让程序简单不少。虽然 Windows 的 WaitForMultipleObjects 让这个问题 trivial 化，在 Linux 下正确模拟 WaitForMultipleObjects 不是普通程序员该干的。

封装 MutexLock、MutexLockGuard 和 Condition

本节把前面用到的 MutexLock、MutexLockGuard、Condition classes 的代码列出来，前面两个 classes 没多大难度，后面那个有点意思。

MutexLock 封装临界区（Critical secion），这是一个简单的资源类，用 RAII 手法 [CCS:13]封装互斥器的建立与销毁。临界区在 Windows 上是 CRITICAL_SECTION，是可重入的；在 Linux 下是 pthread_mutex_t，默认是不可重入的。MutexLock 通常是别的 class 的数据成员。

MutexLockGuard 封装临界区的进入和退出，即加锁和解锁。MutexLockGuard 通常是个栈上对象，它的做用域恰好等于临界区域。

这两个 classes 应该能在纸上默写出来，没有太多须要解释的：

 
         #include <pthread.h> 
        
         #include <boost/noncopyable.hpp> 
        
         class  
         MutexLock : boost::noncopyable 
        
         { 
        
         public 
         : 
        
         MutexLock()   
         // 为了节省版面，单行函数都没有正确缩进 
        
         { pthread_mutex_init(&mutex_, NULL); } 
        
         ~MutexLock() 
        
         { pthread_mutex_destroy(&mutex_); } 
        
         void  
         lock()   
         // 程序通常不主动调用 
        
         { pthread_mutex_lock(&mutex_); } 
        
         void  
         unlock()   
         // 程序通常不主动调用 
        
         { pthread_mutex_unlock(&mutex_); } 
        
         pthread_mutex_t* getPthreadMutex()   
         // 仅供 Condition 调用，严禁本身调用 
        
         {  
         return  
         &mutex_; } 
        
         private 
         : 
        
         pthread_mutex_t mutex_; 
        
         }; 
        
         class  
         MutexLockGuard : boost::noncopyable 
        
         { 
        
         public 
         : 
        
         explicit  
         MutexLockGuard(MutexLock& mutex) : mutex_(mutex) 
        
         { mutex_.lock(); } 
        
         ~MutexLockGuard() 
        
         { mutex_.unlock(); } 
        
         private 
         : 
        
         MutexLock& mutex_; 
        
         }; 
        
         #define MutexLockGuard(x) static_assert(false, "missing mutex guard var name")

注意代码的最后一行定义了一个宏，这个宏的做用是防止程序里出现以下错误：

 
         void  
         doit() 
        
         { 
        
         MutexLockGuard(mutex);   
         // 没有变量名，产生一个临时对象又立刻销毁了，没有锁住临界区 
        
         // 正确写法是 MutexLockGuard lock(mutex); 
        
         // 临界区 
        
         }

这里 MutexLock 没有提供 trylock() 函数，由于我没有用过它，我想不出何时程序须要“试着去锁一锁”，或许我写过的代码太简单了。

我见过有人把 MutexLockGuard 写成 template，我没有这么作是由于它的模板类型参数只有 MutexLock 一种可能，没有必要随意增长灵活性，因而我人肉把模板具现化 (instantiate) 了。此外一种更激进的写法是，把 lock/unlock 放到 private 区，而后把 Guard 设为 MutexLock 的 friend，我认为在注释里告知程序员便可，另外 check-in 以前的 code review 也很容易发现误用的状况 (grep getPthreadMutex)。

这段代码没有达到工业强度：a) Mutex 建立为 PTHREAD_MUTEX_DEFAULT 类型，而不是咱们预想的 PTHREAD_MUTEX_NORMAL 类型（实际上这两者极可能是等同的），严格的作法是用 mutexattr 来显示指定 mutex 的类型。b) 没有检查返回值。这里不能用 assert 检查返回值，由于 assert 在 release build 里是空语句。咱们检查返回值的意义在于防止 ENOMEM 之类的资源不足状况，这通常只可能在负载很重的产品程序中出现。一旦出现这种错误，程序必须马上清理现场并主动退出，不然会莫名其妙地崩溃，给过后调查形成困难。这里咱们须要 non-debug 的 assert，或许 google-glog 的 CHECK() 是个不错的思路。

以上两点改进留做练习。

Condition class 的实现有点意思。

Pthreads condition variable 容许在 wait() 的时候指定 mutex，可是我想不出什么理由一个 condition variable 会和不一样的 mutex 配合使用。Java 的 intrinsic condition 和 Conditon class 都不支持这么作，所以我以为能够放弃这一灵活性，老老实实一对一好了。相反 boost::thread 的 condition_varianle 是在 wait 的时候指定 mutex，请参观其同步原语的庞杂设计：

Concept 有四种 Lockable, TimedLockable, SharedLockable, UpgradeLockable.
Lock 有五六种： lock_guard, unique_lock, shared_lock, upgrade_lock, upgrade_to_unique_lock, scoped_try_lock.
Mutex 有七种：mutex, try_mutex, timed_mutex, recursive_mutex, recursive_try_mutex, recursive_timed_mutex, shared_mutex.

恕我愚钝，见到 boost::thread 这样如 Rube Goldberg Machine 同样“灵活”的库我只得三揖绕道而行。这些 class 名字也很无厘头，为何不老老实实用 reader_writer_lock 这样的通俗名字呢？非得增长精神负担，本身发明新名字。我不肯为这样的灵活性付出代价，宁愿本身作几个简简单单的一看就明白的 classes 来用，这种简单的几行代码的轮子造造也无妨。提供灵活性当然是本事，然而在不须要灵活性的地方把代码写死，更须要大智慧。

下面这个 Condition 简单地封装了 pthread cond var，用起来也容易，见本节前面的例子。这里我用 notify/notifyAll 做为函数名，由于 signal 有别的含义，C++ 里的 signal/slot，C 里的 signal handler 等等。就别 overload 这个术语了。

 
         class  
         Condition : boost::noncopyable 
        
         { 
        
         public 
         : 
        
         Condition(MutexLock& mutex) : mutex_(mutex) 
        
         { pthread_cond_init(&pcond_, NULL); } 
        
         ~Condition() 
        
         { pthread_cond_destroy(&pcond_); } 
        
         void  
         wait() 
        
         { pthread_cond_wait(&pcond_, mutex_.getPthreadMutex()); } 
        
         void  
         notify() 
        
         { pthread_cond_signal(&pcond_); } 
        
         void  
         notifyAll() 
        
         { pthread_cond_broadcast(&pcond_); } 
        
         private 
         : 
        
         MutexLock& mutex_; 
        
         pthread_cond_t pcond_; 
        
         };

若是一个 class 要包含 MutexLock 和 Condition，请注意它们的声明顺序和初始化顺序，mutex_ 应先于 condition_ 构造，并做为后者的构造参数：

 
         class  
         CountDownLatch 
        
         { 
        
         public 
         : 
        
         CountDownLatch( 
         int  
         count) 
        
         : count_(count), 
        
         mutex_(), 
        
         condition_(mutex_) 
        
         { } 
        
         private 
         : 
        
         int  
         count_; 
        
         MutexLock mutex_;   
         // 顺序很重要 
        
         Condition condition_; 
        
         };

请容许我再次强调，虽然本节花了大量篇幅介绍如何正确使用 mutex 和 condition variable，但并不表明我鼓励处处使用它们。这二者都是很是底层的同步原语，主要用来实现更高级的并发编程工具，一个多线程程序里若是大量使用 mutex 和 condition variable 来同步，基本跟用铅笔刀锯大树（孟岩语）没啥区别。

在程序里使用 pthreads 库有一个额外的好处：分析工具认得它们，懂得其语意。线程分析工具如 Intel Thread Checker 和 Valgrind-Helgrind 等能识别 pthreads 调用，并依据 happens-before 关系 [Lamport 1978] 分析程序有无 data race。

线程安全的 Singleton 实现

研究 Signleton 的线程安全实现的历史你会发现不少有意思的事情，一度人们认为 Double checked locking 是王道，兼顾了效率与正确性。后来有神牛指出因为乱序执行的影响，DCL 是靠不住的。（这个又让我想起了 SQL 注入，十年前用字符串拼接出 SQL 语句是 Web 开发的通行作法，直到有一天有人利用这个漏洞越权得到并修改网站数据，人们才幡然醒悟，赶忙修补。）Java 开发者还算幸运，能够借助内部静态类的装载来实现。C++ 就比较惨，要么次次锁，要么 eager initialize、或者动用 memory barrier 这样的大杀器（ http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf ）。接下来 Java 5 修订了内存模型，并加强了 volatile 的语义，这下 DCL (with volatile) 又是安全的了。然而 C++ 的内存模型还在修订中，C++ 的 volatile 目前还不能（未来也难说）保证 DCL 的正确性（只在 VS2005+ 上有效）。

其实没那么麻烦，在实践中用 pthread once 就行：

 
         #include <pthread.h> 
        
         template 
         < 
         typename  
         T> 
        
         class  
         Singleton : boost::noncopyable 
        
         { 
        
         public 
         : 
        
         static  
         T& instance() 
        
         { 
        
         pthread_once(&ponce_, &Singleton::init); 
        
         return  
         *value_; 
        
         } 
        
         static  
         void  
         init() 
        
         { 
        
         value_ =  
         new  
         T(); 
        
         } 
        
         private 
         : 
        
         static  
         pthread_once_t ponce_; 
        
         static  
         T* value_; 
        
         }; 
        
         template 
         < 
         typename  
         T> 
        
         pthread_once_t Singleton<T>::ponce_ = PTHREAD_ONCE_INIT; 
        
         template 
         < 
         typename  
         T> 
        
         T* Singleton<T>::value_ = NULL;

上面这个 Singleton 没有任何花哨的技巧，用 pthread_once_t 来保证 lazy-initialization 的线程安全。使用方法也很简单：

Foo& foo = Singleton<Foo>::instance();

固然，这个 Singleton 没有考虑对象的销毁，在服务器程序里，这不是一个问题，由于当程序退出的时候天然就释放全部资源了（前提是程序里不使用不能由操做系统自动关闭的资源，好比跨进程的 Mutex）。另外，这个 Singleton 只能调用默认构造函数，若是用户想要指定 T 的构造方式，咱们能够用模板特化 (template specialization) 技术来提供一个定制点，这须要引入另外一层间接。

概括

进程间通讯首选 TCP sockets
线程同步的四项原则
使用互斥器的条件变量的惯用手法 (idiom)，关键是 RAII

用好这几样东西，基本上能应付多线程服务端开发的各类场合，只是或许有人会以为性能没有发挥到极致。我认为，先把程序写正确了，再考虑性能优化，这在多线程下任然成立。让一个正确的程序变快，远比“让一个快的程序变正确”容易得多。

7 总结

在现代的多核计算背景下，线程是不可避免的。尽管必定程度上能够经过 framework 来屏蔽，让你感受像是在写单线程程序，好比 Java Servlet。了解 under the hood 发生了什么对于编写这种程序也会有帮助。

多线程编程是一项重要的我的技能，不能由于它难就本能地排斥，如今的软件开发比起 10 年 20 年前已经难了不知道多少倍。掌握多线程编程，才能更理智地选择用仍是不用多线程，由于你能预估多线程实现的难度与收益，在一开始作出正确的选择。要知道把一个单线程程序改为多线程的，每每比重头实现一个多线程的程序更难。

掌握同步原语和它们的适用场合时多线程编程的基本功。以个人经验，熟练使用文中提到的同步原语，就能比较容易地编写线程安全的程序。本文没有考虑 signal 对多线程编程的影响，Unix 的 signal 在多线程下的行为比较复杂，通常要靠底层的网络库 (如 Reactor) 加以屏蔽，避免干扰上层应用程序的开发。

通篇来看，“效率”并非个人主要考虑点，a) TCP 不是效率最高的 IPC，b) 我提倡正确加锁而不是本身编写 lock-free 算法（使用原子操做除外）。在程序的复杂度和性能以前取得平衡，并经考虑将来两三年扩容的可能（不管是 CPU 变快、核数变多，仍是机器数量增长，网络升级）。下一篇“多线程编程的反模式”会考察伸缩性方面的常见错误，我认为在分布式系统中，伸缩性 (scalability) 比单机的性能优化更值得投入精力。

这篇文章记录了我目前对多线程编程的理解，用文中介绍的手法，我能解决本身面临的所有多线程编程任务。若是文章的观点与您不合，好比您使用了我没有推荐使用的技术或手法（共享内存、信号量等等），只要您理由充分，但行无妨。

这篇文章原本还有两节“多线程编程的反模式”与“多线程的应用场景”，考虑到字数已经超过一万了，且听下回分解吧 :-)

后文预览：Sleep 反模式

我认为 sleep 只能出如今测试代码中，好比写单元测试的时候。（涉及时间的单元测试不那么好写，短的如一两秒钟能够用 sleep，长的如一小时一天得想其余办法，好比把算法提出来并把时间注入进去。）产品代码中线程的等待可分为两种：一种是无所事事的时候（要么等在 select/poll/epoll 上。要么等在 condition variable 上，等待 BlockingQueue /CountDownLatch 亦可纳入此类），一种是等着进入临界区（等在 mutex 上）以便继续处理。在程序的正常执行中，若是须要等待一段时间，应该往 event loop 里注册一个 timer，而后在 timer 的回调函数里接着干活，由于线程是个珍贵的共享资源，不能轻易浪费。若是多线程的安全性和效率要靠代码主动调用 sleep 来保证，这是设计出了问题。等待一个事件发生，正确的作法是用 select 或 condition variable 或（更理想地）高层同步工具。固然，在 GUI 编程中会有主动让出 CPU 的作法，好比调用 sleep(0) 来实现 yield。