《Linux多线程服务端编程》书评

水军很多啊

9.1分，尼玛，坑谁呢。。。。。看这里，比较客观http://ar.newsmth.net/thread-c64b61785ba061.htmlmuduo适用于什么环境？ muduo的官方一句话自我介绍是：A C++ non-blocking multi-threaded network library for Linux。 在其readme和wiki中均未提及此lib是否适用于实际场景，于是我花了些时间翻看了一 下，得出的结论是此lib仅限于展示epoll/poll的基本用法，对网络编程初学者是否有参考 价值还有待进一步考察。 任何一个网络产品除了要支持网络event之外，还必须处理另外两种事件：signal和 timer。 muduo也毫无例外。但近看一下就发现muduo对single和timer的支持很有喜感。 除了SIGPIPE被mask之外，muduo没有接管signal。当然muduo这么做是有借口的，反 正有signalfd嘛。在此我想问问各位做网络应用的同学，在你的实际项目中，不用POSIX 的signal接口而用signalfd的，有几个？而如果是从编程初学者教育的角度来看，是介绍 POSIX重要，还是介绍2.6.22引入的一个new feature重要？ 而抛弃signal的处理之后，muduo自然轻松了许多，还顺带可以说一句：muduo支持高 级特性signalfd。--嗯，听起来很高级，不过signalfd不是muduo支持的，而是kernel支 持的。 一个网络编程库，timer是重中之重，比到底是用epoll还是select都重要。当然，话说回 来，再吊的库无非也就是个heap为本的数据结构在支持，无非是有些库喜欢说自己的 heap实现比别人都高效，比如haproxy。 但muduo却独辟蹊径，用timerfd，泥玛又是一个高级特性啊，很唬人的。由kernel帮你 管理timer，是不是很吊。 不仅采用了timerfd，muduo还采用了set来保存event，每个big loop里要查超时的时 候，再iterate一遍这个set。 再然后，每次加一个timer，就要冒着一次settime的syscall的风险--这还不够，还得要一 次gettimeofday。别不把syscall当不要钱的可以吗？ 你也许可以跑10万个连接，但你敢加上超时的特性吗？muduo如果有做过细致的 benchmark就会知道，一个loop里最花时间的就是timer的处理。 关于muduo的timer处理，槽点太多，我就不一一细述了。回头看看timer，很显然不适 合工业应用，而给初学者做参考。。。嗯，负面参考价值很大。 嗯，今天先说这么多吧。吐槽点还很多，比如那个全功能的http范例，比如对 pthread/fork的支持，比如对内存的使用等等等等。都要一一吐过也不是不可以，不过就 要耐下性子来慢慢写就是。

简评一则

本书大部分都由作者的blog文章组成，内容略显杂乱，无组织性，不能算得上是一本好书，9.0的分数由理由相信是水军所为。 但是各章节内容也不能说无任何价值，都是作者的经验之谈。对我进行服务器编程不久的同学来说，还是值得一读的。

近两年最有收获的一本书

去年买的这本书，到现在很多章节看了不下3遍，书中并不是讲使用muduo库，而是重点放在怎样实现一个网络库和作者多年来积累的服务端编程经验。不要去在乎什么boost库，这不是重点，重点是各种服务端技术和网络经验。说一点虚的，这是我近两年看的最认真的一本书，最有收获的一本书。如果想做服务端的同学，看看这本书绝对收获颇丰。看到有评论说muduo实现的如何不好，严重怀疑这些人没看过这本书，其实我觉得书的重点不在这。我力推这本书但是并没有用过muduo。因为我觉得重点在作者在书中大量的经验之谈，绝对醍醐灌顶，不服来辩，

看了之后收获很大，对学习网络编程、多线程和C++都有帮助

个人觉得看了APUE和UNP之后看这本书非常合适。这本书比较贴近实践，看了这本书之后对Non-blocking IO，Reactor模型，多线程，C++的使用都有了更深入的认识。尤其推荐6.6章，对多线程服务器模型的描述很精彩。

linux网络编程力作！

相比APUE和UNP，该书更像一本实战进阶教程。结合作者提供的开源库muduo，向读者很好的展示了linux网络库开发及多线程服务器开发（就网络编程而言现在市面上的中文书无出其右），同时该书也是一本学习现代C++编程的好书。PS：我们的游戏项目的网络库参考了muduo并做了一些修改，现在运行非常良好。得益于muduo的良好设计，在移植windows及android平台时没有做过多的修改，特此感谢陈硕的辛勤努力！PS：居然有人说水军多！！！ 为了证明我不是水军，发一下我的blog：http://www.cnblogs.com/ychellboy

关键算法有问题

poll模型最关键的算法是如何调度线程池来处理有读写的连接，但是本书在4400位置附近只提了一句：「muduo目前采用最简单的round-robin算法来选取poll中的EventLoop...」。为什么有问题？1、采用轮询的方法不能保证线程之间调度的公平（即使线程池采用和CPU核数相同的线程数并绑定线程到各核心上），因为有些连接可能读写频繁，有些连接则可能数据寥寥，这样有的核心很忙有的却很闲，如此CPU就未被完全利用；2、如果采用比CPU核心数多的线程，则频繁的轮询调度可能导致频繁地切换线程，性能会大受影响。也就是说调度的基本粒度应该是每个fd的每个读或者写，而不是每个fd（上所有的读写）。比较高效地实现应该是Windows的IOCP，不过Linux从2.6Kernel开始已经支持异步IO了，叫做Linux native AIO。

跳过了大部分C++相关的章节

我觉得以我的智商在有生之年很难掌握这么复杂的语言……书是上班时间看的，所以只是大致过一遍，而且即使要看muduo的代码，也得先按照优先级入队等待调度吧以下是我感兴趣并看完的章节：第2章 除了2.8第3章第4章 除了4.7和4.8第6章 只看了6.6.2第7章 7.5 7.13第9章第10章第12章 12.6 12.7 12.8附录A能有一本不经过翻译的好书其实挺不容易的，感谢作者

这本书很实用 -- 在校生视角

首先讲个结论，这本书很实用！一直以来，不少学长就再三的强调，要想当个好的“后端”程序员，拿好offer，就得扎扎实实把C++学好。到我一直疑惑怎样才算“学好”。同学们似乎把学好就定位在“记得各种语法细节”。学校里使用C++的太少了，不如 java 和 python 开发来得快。另外，优秀的C++开源项目太少。因 此，C++的“实战”之路不好走。这本书的可贵之处在于“有源码” ， “有引用”。其实看源码就跟写作看别人的文章一样。从别人的文章里学技巧，这比一般的经验分享有用多了。第二是有“引用”。由于书本篇幅的限制和主题表达的需要。作者在写书无法把资料的信息全部阐述，写下资料的出处，想深入了解的就可以自己去读。这资料是作者日积月累攒下的，省了读者不少事。大开我眼界。最后跟作者说声谢谢，写书不易。期待他的下一本著作。

如果读通很有帮助

应该算是一本好书，推荐。如果能把此书读通，对以后肯定帮助大大的。但是难度肯定是有的，遇到不懂得地方多上网查查，不要轻易放弃。这本书对多线程的服务器端编程写的挺详细的。本书的宗旨是贵精不贵多。掌握两种基本的同步原语就可以满足各种多线程同步的功能需求，还能写出更易用的同步设施。掌握一种进程间通信方式和一种多线程网络编程模型就足以应对日常开发任务，编写运行于公司内网环境的分布式服务统。

即便不讲C++，书也很有趣

草草翻阅了一遍很有意思，C++部分很多没看懂的，准备买本深读。比如 ntp 的实现原理，多线程下为何不能 fork，还有 timefd的使用，好像没讲eventfd，BlockingQueue<T> 确实也非常好用。timing-wheel 的图，个人觉得有点坑爹，轮盘上的刻度容易误解。另外 evbuffer 讲的太繁琐了，耗费了几页纸。Linux 现在真心缺少讲网络编程的书籍，也许是richard stevens 高度太高弄得后人无从下手？如今内核日新月异，新增了很多有用的系统调用，及其期待好书的出现能综合的介绍，不过这种深刻 理解协议栈 然后回头写用户态程序的人也许真的很少。作者旁征博引的能力很强。

说实话这个库很渣

说实话这个库很渣, 代码风格渣, 注解也很随意, 甚至关键部分没有注解, 代码排版也很糟糕, 设计也不行, 局限于reactor模型也是个硬伤, 另外数据收发部分存在各种隐含的数据分配及拷贝, 比如字符串到字符串, 数据到字符串等之类, 这其中用到了string存储数据也是个奇葩. 这样白白浪费了内存及cpu资源, 导致效率低下, 无法与主流的asio或其它库相比, 细节问题考虑不周详的实在太多了.muduo更像是新手练手的东西堆砌而成, 所以, 这是只能算是个然并卵的东西.而这本书, 就是新手的笔记堆砌而成.不推荐.

推荐《Linux 多线程服务器端编程》

最近，有一位朋友因为工作需要，需要从网游的客户端编程转向服务器端编程，找我推荐一本书。我推荐了《Linux 多线程服务器端编程——使用 muduo C++ 网络库》给他，他在网上书店看了以后问我为什么推荐这么厚一本书给他，正好这本书我已经早就看完了，一直也想写篇“书评”，就在这里多扯几句。其实实在算不上书评，原因有二：一是读书的时候囫囵吞枣，理解不够深刻，不深刻自然不能评；二是这几年虽然在 Linux 下写服务器端的网络程序，但很少用多线程，也很少用 C++，书里谈的东西，算是不熟悉的领域，自然也不能乱评。所以今天这篇，应当是推荐，是为陈硕老师背书。这本书展示了使用 C++、多线程进行网络编程的许多最佳实践，甚至称为标准做法也不为过。比如当谈到 C++ 的内存管理问题的时候，以“不配对的 new[]/delete”为例，用“把 new[] 统统替换为 std::vector/scoped_array”为解决方案，提出使用“智能指针”解决大部分内存问题，堪称金玉良言。又比如当谈到“如何限制并发连接数”时，作者直接引用了 libev 作者 Marc Lehmann 提出的几个方案，并另外给出一个更为简单的方案。这些最佳实践的意义在于，当你读完了 APUE 和 UNP，却发现自己写出来的网络程序完全不堪商用，然后花费了许多日日夜夜修补业务漏洞、内存泄漏、并发性能，勉强支撑了公司业务以后，读到此书时那种相见恨晚的感觉。你会发现虽然自己身经百战，但是仍然能够从书中找到自己完全不了解的“常识”；对你来说，也许最大的欣慰就是觉得以后团队新人终于有一本实践指南，可以让新人快速成长起来，不用再一次趟过你已经趟过的坑。这本书展示了好的代码，特别是好的 C++ 代码。从来不缺乏 C++ 的批评之声，但是 C++ 应当怎么用，如何写 C++ 才是现代的、真正的 C++，在此书之前，几乎从来没有成体系的讲法。我参与过一些 C++ 项目的编程，也见过许多技术负责人一边视 boost 为洪水猛兽，甚至对 STL 也避之不及，却又一边自行制造同样目的、质量差强人意的山寨版轮子。作者非常理性地看待 C++，约束自己对其特性的使用，并提出“朴素的 C++ 设计”理念，在编程中挑选 boost 库中久经考验的、优秀的子库善加应用，比如“使用 boost::function 和 boost::bind 取代虚函数”，减少代码的同时获得非常可靠的代码质量，是非常值得我们学习借鉴的。这本书展示了基础的重要性。直接读，可以发现很多章节讲的内容都可以说是常识，但是作为一名久经考验的程序员，可以说，我觉得这里面讲的常识都是“一不留神坑死你”的。比如“shared_ptr 技术与陷阱”一节中，作者提到析构的线程不一定是是对象诞生的线程，我的膝盖就中过一箭。当时我为一个动作游戏编写非玩家角色的人工智能，在游戏中，大部分 CPU 资源都被用在图形渲染上，留给人工智能的资源非常有限，我又要做计算量超大的团队人工智能，所以很“卡”。后来的优化方案是把内存释放操作放到另一条线程去执行，虽然当时没有使用 shared_ptr，但因为问题的原因和解决方案都是一样的，如果我们当时都读过这本书，应该不会踏入这个坑。如果有出身草莽的野路子程序员，读一下这本书，应该还是大有补益的。这本书展示了对业务理解的重要性。无论是 muduo 库，还是这本书，都没有想做到面面俱到。对于 muduo，作者追求的是完成业务领域的需求，并压榨硬件的极限；对于这本书，作者讲求的是“经验与实践”，并没有把这本书写成枕头书，而是把“应当注意的、我这样做的理由”讲得通透。说老实话，读这本书，感觉到作者就像一对一的培训那么贴心。虽然我从 2013 年起，以 web 开发和团队管理工作为主，已经不写基于 TCP 协议的服务器端程序，甚至“几乎不使用 C++”三年了，但阅读这本书仍然极有意义：一是理解 Linux 关于网络方面的新特性，这一块对我现在做基于 HTTP 协议的开发工作也是极有帮助的；二是理解多线程的最佳实践，其实工作中免不了多少要跟多线程打交道，掌握这方面的最佳实践，在遇到使用场景时，可以马上给出“没大错”的方案；三是理解 C++，跟上它的发展，这对于我编写、学习其它编程语言也极有指导意义。当然，对于我朋友这种从客户端转过来服务器端的程序员来说，最重要的是能够快速地写出“正统的”服务器端代码了。