本课程要求听课人员已经读过《Unix 网络编程》，能写简单的 TCP echo 服务。

课程地址：http://boolan.com/course/4

配套页面：http://chenshuo.com/pnp

购买地址：http://e.jd.com/30149978.html

阅读效果：

PC

iPad

目前京东的阅读器没有切白边功能，值得改进。

先说说程序员（应届生）面试的一般过程，一轮面试（面对一到两个面试官）一般是四、五十分钟，面试官会问两三个编程问题（通常是两大一小），因此留给每个编程题的时间只有 20 分钟。这 20 分钟不光是写代码，还要跟面试官讨论你的答案并解答提问，比如面试官拿过你的答案纸，问某一行代码如果修改会有什么后果。因此真正留给在纸上或白板上写代码的时间也就 10 分钟上下。本文给出了一个能用 10 分钟时间在纸上写出来且不会有错的 String class，强调正确性及易实现（白板上写也不会错），不强调效率与功能完备。

本文的配套代码位于 https://github.com/chenshuo/recipes/blob/master/string/StringTrivial.h。

全文：https://chenshuo.googlecode.com/files/CppEngineering.pdf

> 陈硕，你好，
>
> 阅读了你的书，很有收获。
> 但是没有在moduo的源代码里面找到实现线程模型11的例子。即one thread per loop + thread pool。
> 谢谢。

书第 173 页图 6-14 下面的第一段话，具体改动方法参考前一页的 diff。

> 谢谢。
>
> 另外TcpConnection和Channel的生命周期管理有点问题。
> TcpConnection如果已经被回收了，其包含的Channel也已经被回收了。而这个时候在Channel::handleEvent()里面检查tied_和tie_是危险的。因为其内存已经被回收了。
>
> 如果用户保证TcpConnection被回收之后，不会再用Channel的裸指针，则没有必要在TcpConnection::connectEstablished()中call tie().

TcpConnection 回收之前，会调用 connectDestroyed，其中调用 channel_->remove();，这样就不可能再会有 Channel::handleEvent() 被调用了。

tie() 的作用是防止 Channel::handleEvent() 运行期间其 owner 对象析构，导致 Channel 本身被销毁。

> > TcpConnection 回收之前，会调用 connectDestroyed，其中调用 channel_->remove();，这样就不可能再会有 Channel::handleEvent() 被调用了。
> 这个时候会不会有race condition？假设现在有两个active channels，处理头一个的时候回收TcpConnection，而第二个channel刚好对应这个connection。

这时你没有办法强制销毁 TcpConnection，只能降低其引用计数，所以不会有问题。你可以写段代码试试。

> 另外底层的poller OS api是否保证unregister channel之后一定不会再有这个channel的事件，会清空内核的已经就绪的事件队列？

跟内核没关系，Poller class 在 unregister channel 之后就不可能调用其 handleEvent() 成员函数。

> 那EPollPoller::fillActiveChannels()的改一改，“assert(it != channels_.end());”不再适用了，而且每次都个event都要查一次map。效率会有问题。

assert() 只有在 debug build 才执行，不会影响效率。
再说每个 event 都要涉及 read/write 等系统调用，开销比“查一次 map”大得多，优化这里是无用功。

> 但这个assert()不是invalid了吗？你可能之前在unregister channel的时候已经从map里面remove掉了它。

这个 assert 是有效的，你再想想。

> > tie() 的作用是防止 Channel::handleEvent() 运行期间其 owner 对象析构，导致 Channel 本身被销毁。

> 这个也不太make sense。仍然有race conditon。在Channel::handleEvent()拥有guard锁定ownner之前，Channel::handleEvent（)需要检查其tied_。

你再想想，tie 的作用是防止调用 handleEvent() 期间对象销毁（比如调用 closeCallback 期间），不是也不可能防止调用 handleEvent() 之前对象销毁。

> 恩，是的。整个TcpConnection, Channel, EventLoop都是一个thread里面run的。

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

最近，有一位朋友因为工作需要，需要从网游的客户端编程转向服务器端编程，找我推荐一本书。我推荐了《Linux 多线程服务器端编程——使用 muduo C++ 网络库》给他，他在网上书店看了以后问我为什么推荐这么厚一本书给他，正好这本书我已经早就看完了，一直也想写篇“书评”，就在这里多扯几句。其实实在算不上书评，原因有二：一是读书的时候囫囵吞枣，理解不够深刻，不深刻自然不能评；二是这几年虽然在 Linux 下写服务器端的网络程序，但很少用多线程，也很少用 C++，书里谈的东西，算是不熟悉的领域，自然也不能乱评。所以今天这篇，应当是推荐，是为陈硕老师背书。

继续阅读：

http://blog.csdn.net/gzlaiyonghao/article/details/10366863

http://book.douban.com/review/6249351/

前几天，我发了一条微博 http://weibo.com/1701018393/A7FrW7ZVd ，质疑某本书对 Pthreads 条件变量的封装是错的，因为它没有把 mutex 的 lock()/unlock() 函数暴露出来，导致无法实用。后来大家讨论的分歧是这个 cond class 是不是通用的条件变量封装，还是只是一个特殊的“事件等待器”。作为事件等待器，其实现也是错的，因为存在丢失事件的可能，可以算是初学者使用条件变量的典型错误。

本文的代码位于 recipes/thread/test/Waiter_test.cc，这里提到的某书的版本相当于 Waiter1 class。

我在拙作《Linux 多线程服务端编程：使用 muduo C++ 网络库》第 2.2 节总结了条件变量的使用要点：

条件变量只有一种正确使用的方式，几乎不可能用错。对于 wait 端：
1. 必须与 mutex 一起使用，该布尔表达式的读写需受此 mutex 保护。
2. 在 mutex 已上锁的时候才能调用 wait()。
3. 把判断布尔条件和 wait() 放到 while 循环中。

对于 signal/broadcast 端：
1. 不一定要在 mutex 已上锁的情况下调用 signal （理论上）。
2. 在 signal 之前一般要修改布尔表达式。
3. 修改布尔表达式通常要用 mutex 保护（至少用作 full memory barrier）。
4. 注意区分 signal 与 broadcast：“broadcast 通常用于表明状态变化，signal 通常用于表示资源可用。（broadcast should generally be used to indicate state change rather than resource availability。）”

如果用条件变量来实现一个“事件等待器/Waiter”，正确的做法是怎样的？我的最终答案见 WaiterInMuduo class。“事件等待器”的一种用途是程序启动时等待初始化完成，也可以直接用 muduo::CountDownLatch 到达相同的目的，将初值设为 1 即可。

以下根据微博上的讨论过程给出几个正确或错误的版本，博大家一笑。只要记住 Pthread 的条件变量是边沿触发（edge trigger），即 signal()/broadcast() 只会唤醒已经等在 wait() 上的线程(s)，我们在编码时必须要考虑 signal() 早于 wait() 的可能，那么就很容易判断以下各个版本的正误了。代码见 recipes/thread/test/Waiter_test.cc。

版本一：错误。某书上的原始版，有丢失事件的可能。

版本二：错误。lock() 之后再 signal()，同样有丢失事件的可能。

版本三：错误。引入了 bool signaled_; 条件，但没有正确处理 spurious wakeup。

版本四五六：正确。仅限 single waiter 使用。

版本七：最佳。可供 multiple waiters 使用。

版本八：错误。存在 data race，且有丢失事件的可能。理由见 http://stackoverflow.com/questions/4544234/calling-pthread-cond-signal-without-locking-mutex

总结：使用条件变量，调用 signal() 的时候无法知道是否已经有线程等待在 wait() 上。因此一般总是要先修改“条件”，使其为 true，再调用 signal()；这样 wait 线程先检查“条件”，只有当条件不成立时才去 wait()，避免了丢事件的可能。换言之，通过使用“条件”，将边沿触发（edge trigger）改为电平触发（level trigger）。这里“修改条件”和“检查条件”都必须在 mutex 保护下进行，而且这个 mutex 必须用于配合 wait()。

思考题：如果用两个 mutex，一个用于保护“条件”，另一个专门用于和 cond 配合 wait()，会出现什么情况？

最后注明一点，http://stackoverflow.com/questions/6419117/signal-and-unlock-order 这篇帖子里对 spurious wakeup 的解释是错的，spurious wakeup 指的是一次 signal() 调用唤醒两个或以上 wait()ing 的线程，或者没有调用 signal() 却有线程从 wait() 返回。manpage 里对 Pthreads 系列函数的介绍非常到位，值得细读。

这不是 memcached 的替代品（它没有实现LRU和超时功能，也没有实现二进制协议，更没有自己管理内存），而是一个网络编程的示例（代码只有 1000 行，比 memcached 小很多），展示 muduo 风格的事件驱动编程，以及将来性能优化的试验品（换句话说，现在这个版本完全没有在性能上做出任何努力）。读过 memcached 代码的人可以对比这两种编程风格的区别，memcached 的 read/write 操作穿插于正常逻辑处理，而 muduo 的网络数据读写是由库完成，应用程序只关心消息收发，目前二者的基本 get/set 操作的性能相当。

现在 muduo 的 inspector 内置了 gperftools 的远程 profiling 功能，memcached-debug 展示了其用法。

为什么不必优化 set 操作（含 set/add/update/append/prepend/cas 等）的性能？

1. 比例。既然是 memcache，那么 get:set 的比例很高，10:1 甚至更高，因此优化的重心应该是 get 而非 set。

假设 memcached 能处理 100k QPS，再假设这些操作都是 set（其实应该不到 10% 是 set），再假设所有的 set 都是串行执行的（没有并发），那么每次 set 的 CPU 时间不应该超过 10 us（含服务器本地的网络代码运行时间，但不含网络延迟）。而实际上一次 set 的 CPU 时间最多是 2~3 us （用 memcached-footprint 程序测得），根本不值得优化。

2. 网络带宽。假设一次 set 操作的 key + value 的长度是 1k bytes，TCP 的有效载荷带宽按110MB/s估算，那么1kB数据在千兆网上的惯性延迟是 9us（传输延迟是几十上百微秒，与此无关），也就是说服务器的网卡收到这 1kB 数据需要花 9us 时间（从第一个字节到达到服务器到收完最后一个字节），那么在 set 耗时 2~3 us 的情况下再去优化它是做无用功。

3. 产生“需要更新的数据”的成本远大于 memcached set 的开销。memcached 需要更新，往往是将已写入数据库的新数据放到 memcached 中，那么写数据库的开销远远大于 memcached set 的开销，优化 set 对提升系统整体性能没意义。

知道禁用 copy-ctor/assign operator 是 C++ 程序员的试金石。在看到一个开源项目时，我一般会先查看其 RAII handle class 是否禁用了 copy-ctor/assign operator（例如 Thread、Mutex、CondVar、Connection），如果没有，对其第一印象就很差了。

关于 class 命名风格，Google、LLVM、Mozilla、muduo 都采用 Pascal 风格（LikeThis），例如 EventLoop、SudokuSolver 等等。正巧它们也都是用 2 格缩进的，可以用 clang-format 自动格式化代码。

顺便说说我不认同的两个 C++ 教条：1. 用nullptr替换NULL，2. 用cstdio头文件替换stdio.h。

因为例如 gettimeofday(&tv, NULL) 这种系统函数传个 nullptr 进去实在是违和，现在用 NULL 也能达到 nullptr 的好处，大不了在某个头文件里define一下就行。这条将来或许会变。

另外 ctime 头文件没定义 std::gmtime_r，而 time.h 定义了 ::gmtime_r。我可不想去背哪些函数是 C 语言的哪些是 Posix 的，哪些头文件是 C 语言的哪些是 Posix 的（在Linux下，二者基本不分家）。为了用几个系统函数（例如 fcntl() ），我该 include cfcntl 还是 fcntl.h？用线程是 cpthread 还是 pthread.h？我总是记不住 memset() 的参数顺序，因此一般用 bzero() 代替，但是 manpage 说 bzero() 声明于 strings.h，那我要不要考虑试试 cstrings 呢？何必给自己找麻烦，C++ 标准库之外的内容干脆统一用 .h 头文件好了。

性能优化？

有些人常常把“性能”挂在嘴边，而且其以“提高性能”为理由的“优化措施”往往不到点子上，只增加了复杂性和维护难度，降低了代码质量。这属于决策点找偏了。我发现初学者往往过分关注微观（语句级）性能，比方说关心 while(true) 和 for(;;) 哪个更快，++i 与 i=i+1 哪个更快，i/=16 和 i >>= 4 哪个快等等，而忽视了现代编译器的优化能力。

有的人谈性能优化，一是拿不出具体的合理的性能目标，只想越快越好，二是不能实际准确测量验证性能数据，凭感觉和过时经验行事。在编码的时候，遇到两种做法都可行，决策办法是凭感觉猜选“性能会更好”的一种，而忽视了其他更重要的因素。可读性和性能的典型关系如下图，有多少场合是值得为了性能而牺牲代码的可读性和可维护性呢？我希望自己的代码位于第 3 区，而一些人以为自己的代码是在第 4 区，其实是在第 1 区。

能在第 4 区写代码的人属于凤毛麟角，有时候你费劲优化了半天，结果新CPU加了几条指令，直接在硬件层面把问题解决了。现在一些人动不动就要挽起袖子自己写内存池，号称能提高性能，真当 Ulrich Drepper 是水货？（书第 12.2.8 节“有必要自行定制内存分配器吗”）你打算如何测试内存分配器（malloc）的性能？有哪些指标？有哪些影响因素需要控制或模拟（比如线程数）？你的测试结果是否反映实际场景？

杂项

有人问为什么我说“poco不是服务端C++网络库”（ http://www.oschina.net/question/12_120943 ），虽然它也提供了reactor？因为它的reactor用的是 Socket::select()，虽然后者包装了epoll，但看其实现就知道，它每次调用都会创建并销毁 epoll fd，然后重建整个watch list，没有哪个服务端网络库会这么做。

以下谈一谈这本书的写作背景与内容取舍的原因。

参加工作以来，我编写并维护了若干C++/Java多线程网络服务程序，这本书总结了我在开发维护这类服务程序方面的经验。工作中，我没有写过单线程的网络服务程序，没有写过C语言的网络服务程序，也没有写过运行在Windows下的网络服务程序，因此本书不涉及这些内容。

在“Linux服务端开发”这一背景下，这本书主要讲三个方面的内容[1]：现代C++、多线程、网络编程，分别对应书的第3、1、2部分。这不是一本入门书，本书的读者应该在以上三方面已经具备相当的基础[2]：网络编程方面，能轻松读懂6.1节的两个Python程序；C++方面，对12.8节的代码不感到陌生；多线程方面，能明白第1章要解决什么问题。

第9章“分布式系统工程实践”详细介绍了这本书的应用背景，即开发公司内部的分布式服务系统，书中的很多决策（design decision）和技术取舍（trade-off）是在这一应用场景下做出的。以下是各章直接的交叉引用关系图（没有计算引用次数），其中第0章是前言，字母章节是附录。可见第9章是被引用最多的一章，某种意义上可以说第9章既是本书的先决条件，又是本书的终极目标。由于章节之间存在众多的交叉引用，去掉任何一章都会破坏内容的完整性。

这本书的书名原本打算叫“Linux C++ 多线程系统编程”。写完之后发现，与其他Unix/Linux系统编程方面的书不同，这本书有明确的应用场景，因此可以砍掉很多内容，突出重点。甚至可以说我主要讲别的书没有讲到的内容。这不是一本面面俱到的书，因此最终的书名也就不叫“系统编程”了。

同时，我认为很多教科书上介绍的一些做法是过时的（signal），一些是不推荐使用的（从外部终止线程、TCP OOB数据），一些是大多数情况下没必要使用的（内存池、lock-free 编程）。作为全面的教材和手册，把这些内容放进去可以理解。但是这本书定位是经验总结，我略去了教科书上那些基本用不到的知识点，以免喧宾夺主，也建议读者不要把精力花在那些次要问题上。

• 这本书没有花很大的篇幅去讲signal，而是在第4.10节说明多线程程序不要使用signal作为IPC。并且，在muduo-protorpc的示例中给出了Linux专有的signalfd(2)的用法，可以避免传统signal handler的常见陷阱，也更符合UNIX的“everything is a file”哲学。第4.4节说明不要从外部终止线程，因此也就不必去细究Pthreads cancellation point了。多线程程序最好不要fork()（第4.9节）。
• 这本书没介绍daemon进程，我认为daemon是过时的做法。因为daemon进程的父进程是init(1)，配置文件在本机，不便于多机统一监控与管理（第9.8节）。（注：如果是第三方标准的服务程序，又不需要经常升级或改配置重启，并且一旦崩溃，重启就能继续服务，那么做成 daemon 让init(1)接管是可以的，比如ntpd、sshd等。这里谈的是自己开发维护的服务程序。）另外，Java/Python/Go写的服务程序似乎也没有做成daemon的习惯，C++程序没有理由要特殊对待。补充一点，Linux的进程管理机制很落后（从UNIX继承而来），子进程退出的事件只能被父进程以SIGCHLD信号的方式收到（而且这个signal可能丢失），kill(pid) 也存在很多race condition（你怎么保证pid在kill之前的一瞬间还代表你想kill的那个进程，而不是一个新启动的进程？close(fd)就不会有这种 race condition。）。这些困难在用户态无法克服，只能修改内核，引入新的系统调用才能治本。例如 FreeBSD 9.0 引入了 pdfork()/pdkill() 等，将子进程变成文件描述符，这样就能用IO事件框架统一处理了，也符合UNIX的“everything is a file”哲学。但愿Linux内核也能尽快引入类似的系统调用，减轻程序员的负担。
• 这本书没有讲内存池，而是说明不是每个程序都要自己写内存池（§12.2.8）。这本书也没有把“避免内存碎片”挂在嘴边，而是论证为什么一般的程序不必在意它（§A.1.8）；
• 这本书只关注Linux，不考虑移植性。它推荐使用Linux专有的gettid()系统调用作为线程标识（第4.3节），而不是用pthread_self()。
• 这本书不讲POSIX中五花八门的定时函数，而专讲用Linux特有的timerfd来实现高精度定时（§7.8.2），因为它能方便地融入IO事件处理框架。muduo直接使用C++标准库来管理定时器，而不是自己实现小顶堆(heap)，这样可以简化实现（§8.2.1）。
• 这本书只讲mutex和condition variable作为最基础的线程同步手段（第2章），并且我认为一个C++多线程程序代码里不应该直接出现pthread_mutex_lock之类的基本Pthreads调用。本书进一步建议只使用非递归的mutex（§2.1.1），这与某些网上文章的推荐正好相反。这本书第2.3节甚至建议不要使用读写锁和信号量（semaphore），因为一是容易用错，二是不见得能提高性能。mutex和condition variable是完备的，能实现多种更易用的同步设施，例如CountDownLatch和BlockingQueue。§12.8.3的代码展示了用BlockingQueue和ThreadPool控制并发度的手法，做到了“No locks. No condition variables. No callbacks.”
• 这本书不讲lock-free编程，因为编写可靠的lock-free代码并分析验证其正确性的难度远大于编写普通的使用mutex和condition variable的多线程代码，后者已经有了相当成熟的理论和工具。我认为lock-free不是每个多线程程序员应该掌握的技术，它投入高而用处少，可以适当了解，但不值得每个人都去深究。只需要少数人用它实现封装好的数据结构，像我这样的普通人就可以受益。
• 这本书只讲BSD Sockets作为进程间通信的手段，并且只用TCP长连接（§3.4）。这样就砍掉了pipe、FIFO、POSIX message queue、shared memory、STREAMS、UNIX domain socket等等内容，因为它们都只限本机进程间通信，无法扩展到多机。
• 网络编程方面（第6、7章），这本书不讲Sockets API的基本用法，而且代码中也不会直接使用它们。我认为在程序中直接使用 Sockets API是初学者的做法，当写一个新网络服务程序，如果一开始考虑的是怎么组织accept、read、epoll_wait等调用，这种做法无异于用铅笔刀锯大树，事倍功半，也不利于将来的功能扩展和维护。稍微像样点的公司都会用成熟的网络库（不一定开源），把网络编程的复杂性封装进去，暴露出良好易用的接口，让开发人员使用更高层的building blocks（消息传递或RPC）从功能的角度去设计程序，避免一次次反复掉到TCP网络编程的坑里。多个服务程序共享相同的基础库和事件处理框架的益处是显而易见的，一方面把网络编程的复杂性集中到一起，避免每个团队都去踏一遍坑；另一方面，基础库的bug修复与性能优化能惠及用到它的全部服务程序；最后，程序结构上的相似性让编程经验更加通用，多个服务程序在功能、性能、正确性等方面具有共性，能举一反三触类旁通，降低将来开发维护的成本。应该避免每个程序都另起炉灶，单独设计其IO事件处理结构。
• 这本书只讲非阻塞IO结合IO复用（IO-Multiplexing）这一种并发风格（归纳为三个半事件），并介绍在多线程下的扩展（one loop per thread）。IO复用方面，本书只讲level-trigger，不讲edge-trigger。一方面目前没有up to date的测试表明ET更快，相反，我认为LT在读取数据时可以节约一次read()调用（§8.7.2）；另一方面，LT模式更容易与其他第三方库结合（§7.15）。多线程程序管理并发socket fd有很多风格可供选择，例如epoll fd是多个线程共享一个（多对一）还是每个线程有自己的epoll fd（一对一），每个socket fd是只属于一个epoll fd（多对一）还是可以同时属于多个 epoll fd（多对多），每个socket fd是只能被固定的一个线程读写还是可以被多个线程读写（如果是后者，那么读写的时候是加锁还是使用ONESHOT）。以上不是每种都可行，本书也没有一一加以分析，而是建议使用one loop per thread这种适用性较强的风格，首先是正确性容易验证，其次是性能也能满足要求。
• 本书不讲IPv6，因为目前世界上最大的公司的服务机群也用不完一个私有A类地址（10.0.0.0/8）。本书不讲UDP，因为《Unix网络编程》已经讲得很好了。
• 这本书举的网络编程的例子不再是简单的echo服务，而是有格式（因此引入codec）、多连接之间会交换数据的网络程序，更接近业务场景，也借机讲解如何避免TCP网络编程的常见陷阱。并且在示例代码中给出了分布式单词计数、多机求中位数等稍微复杂一点的程序。
• 在C++方面，这本书没有介绍动态链接库热更新这种“高级”技术，而是说明，在分布式系统中，为了部署方便，应该从源码编译全部的库，与主程序链接为一个standalone的可执行文件，以减小对运行环境的依赖（第10章）。第11章还讨论了程序库与应用程序之间的接口设计。

“信息”按照香农的定义，是“减少不确定性”，这本书包含的信息正是减少选用编程设施（facilities）方面的不确定性，让读者集中精力攻克本质问题。这本书介绍的方法不一定对于每个应用场景都是最好的，但肯定是简便易行的，是时间成本、功能、性能的一种合理折中。

[1] 这本书前言的第一句话“本书主要讲述采用现代 C++ 在 x86-64 Linux 上编写多线程 TCP 网络服务程序的主流常规技术”，封面印着“示范在多核时代采用现代 C++ 编写多线程 TCP 网络服务器的正规做法”。

[2] 前言写到：读者应该已经大致读过《现代操作系统》、《UNIX 环境高级编程》、《UNIX 网络编程》、《C++ Primer》或与之内容相近的书籍，熟悉基本概念，并掌握 Pthreads 和 Sockets API 的常规用法。

2012-01-28

我在《Linux 多线程服务端编程：使用 muduo C++ 网络库》第 1.9 节“再论 shared_ptr 的线程安全”中写道：

（shared_ptr）的引用计数本身是安全且无锁的，但对象的读写则不是，因为 shared_ptr 有两个数据成员，读写操作不能原子化。根据文档（http://www.boost.org/doc/libs/release/libs/smart_ptr/shared_ptr.htm#ThreadSafety）， shared_ptr 的线程安全级别和内建类型、标准库容器、std::string 一样，即：

• 一个 shared_ptr 对象实体可被多个线程同时读取（文档例1）；

• 两个 shared_ptr 对象实体可以被两个线程同时写入（例2），“析构”算写操作；

• 如果要从多个线程读写同一个 shared_ptr 对象，那么需要加锁（例3~5）。

请注意，以上是 shared_ptr 对象本身的线程安全级别，不是它管理的对象的线程安全级别。

后文（p.18）则介绍如何高效地加锁解锁。本文则具体分析一下为什么“因为 shared_ptr 有两个数据成员，读写操作不能原子化”使得多线程读写同一个 shared_ptr 对象需要加锁。这个在我看来显而易见的结论似乎也有人抱有疑问，那将导致灾难性的后果。本文以 boost::shared_ptr 为例，与 std::shared_ptr 可能略有区别。

shared_ptr 的数据结构

shared_ptr 是引用计数型（reference counting）智能指针，几乎所有的实现都采用在堆（heap）上放个计数值（count）的办法（除此之外理论上还有用循环链表的办法，不过没有实例）。具体来说，shared_ptr<Foo> 包含两个成员，一个是指向 Foo 的指针 ptr，另一个是 ref_count 指针（其类型不一定是原始指针，有可能是 class 类型，但不影响这里的讨论），指向堆上的 ref_count 对象。ref_count 对象有多个成员，具体的数据结构如图 1 所示，其中 deleter 和 allocator 是可选的。

图 1：shared_ptr 的数据结构。

为了简化并突出重点，后文只画出 use_count：

以上是 shared_ptr<Foo> x(new Foo); 对应的内存数据结构。

如果再执行 shared_ptr<Foo> y = x; 那么对应的数据结构如下。

但是 y=x 涉及两个成员的复制，这两步拷贝不会同时（原子）发生。

中间步骤 1，复制 ptr 指针：

中间步骤 2，复制 ref_count 指针，导致引用计数加 1：

步骤1和步骤2的先后顺序跟实现相关（因此步骤 2 里没有画出 y.ptr 的指向），我见过的都是先1后2。

既然 y=x 有两个步骤，如果没有 mutex 保护，那么在多线程里就有 race condition。

多线程无保护读写 shared_ptr 可能出现的 race condition

考虑一个简单的场景，有 3 个 shared_ptr<Foo> 对象 x、g、n：

• shared_ptr<Foo> g(new Foo); // 线程之间共享的 shared_ptr
• shared_ptr<Foo> x; // 线程 A 的局部变量
• shared_ptr<Foo> n(new Foo); // 线程 B 的局部变量

一开始，各安其事。

线程 A 执行 x = g; （即 read g），以下完成了步骤 1，还没来及执行步骤 2。这时切换到了 B 线程。

同时编程 B 执行 g = n; （即 write G），两个步骤一起完成了。

先是步骤 1：

再是步骤 2：

这是 Foo1 对象已经销毁，x.ptr 成了空悬指针！

最后回到线程 A，完成步骤 2：

多线程无保护地读写 g，造成了“x 是空悬指针”的后果。这正是多线程读写同一个 shared_ptr 必须加锁的原因。

当然，race condition 远不止这一种，其他线程交织（interweaving）有可能会造成其他错误。

思考，假如 shared_ptr 的 operator= 实现是先复制 ref_count（步骤 2）再复制 ptr（步骤 1），会有哪些 race condition？

杂项

shared_ptr 作为 unordered_map 的 key

如果把 boost::shared_ptr 放到 unordered_set 中，或者用于 unordered_map 的 key，那么要小心 hash table 退化为链表。http://stackoverflow.com/questions/6404765/c-shared-ptr-as-unordered-sets-key/12122314#12122314

直到 Boost 1.47.0 发布之前，unordered_set<std::shared_ptr<T> > 虽然可以编译通过，但是其 hash_value 是 shared_ptr 隐式转换为 bool 的结果。也就是说，如果不自定义hash函数，那么 unordered_{set/map} 会退化为链表。https://svn.boost.org/trac/boost/ticket/5216

Boost 1.51 在 boost/functional/hash/extensions.hpp 中增加了有关重载，现在只要包含这个头文件就能安全高效地使用 unordered_set<std::shared_ptr> 了。

这也是 muduo 的 examples/idleconnection 示例要自己定义 hash_value(const boost::shared_ptr<T>& x) 函数的原因（书第 7.10.2 节，p.255）。因为 Debian 6 Squeeze、Ubuntu 10.04 LTS 里的 boost 版本都有这个 bug。

为什么图 1 中的 ref_count 也有指向 Foo 的指针？

shared_ptr<Foo> sp(new Foo) 在构造 sp 的时候捕获了 Foo 的析构行为。实际上 shared_ptr.ptr 和 ref_count.ptr 可以是不同的类型（只要它们之间存在隐式转换），这是 shared_ptr 的一大功能。分 3 点来说：

1. 无需虚析构；假设 Bar 是 Foo 的基类，但是 Bar 和 Foo 都没有虚析构。

shared_ptr<Foo> sp1(new Foo); // ref_count.ptr 的类型是 Foo*

shared_ptr<Bar> sp2 = sp1; // 可以赋值，自动向上转型（up-cast）

sp1.reset(); // 这时 Foo 对象的引用计数降为 1

此后 sp2 仍然能安全地管理 Foo 对象的生命期，并安全完整地释放 Foo，因为其 ref_count 记住了 Foo 的实际类型。

2. shared_ptr<void> 可以指向并安全地管理（析构或防止析构）任何对象；muduo::net::Channel class 的 tie() 函数就使用了这一特性，防止对象过早析构，见书 7.15.3 节。

shared_ptr<Foo> sp1(new Foo); // ref_count.ptr 的类型是 Foo*

shared_ptr<void> sp2 = sp1; // 可以赋值，Foo* 向 void* 自动转型

sp1.reset(); // 这时 Foo 对象的引用计数降为 1

此后 sp2 仍然能安全地管理 Foo 对象的生命期，并安全完整地释放 Foo，不会出现 delete void* 的情况，因为 delete 的是 ref_count.ptr，不是 sp2.ptr。

3. 多继承。假设 Bar 是 Foo 的多个基类之一，那么：

shared_ptr<Foo> sp1(new Foo);

shared_ptr<Bar> sp2 = sp1; // 这时 sp1.ptr 和 sp2.ptr 可能指向不同的地址，因为 Bar subobject 在 Foo object 中的 offset 可能不为0。

sp1.reset(); // 此时 Foo 对象的引用计数降为 1

但是 sp2 仍然能安全地管理 Foo 对象的生命期，并安全完整地释放 Foo，因为 delete 的不是 Bar*，而是原来的 Foo*。换句话说，sp2.ptr 和 ref_count.ptr 可能具有不同的值（当然它们的类型也不同）。

为什么要尽量使用 make_shared()？

为了节省一次内存分配，原来 shared_ptr<Foo> x(new Foo); 需要为 Foo 和 ref_count 各分配一次内存，现在用 make_shared() 的话，可以一次分配一块足够大的内存，供 Foo 和 ref_count 对象容身。数据结构是：

不过 Foo 的构造函数参数要传给 make_shared()，后者再传给 Foo::Foo()，这只有在 C++11 里通过 perfect forwarding 才能完美解决。

(.完.)