Linux多线程服务端编程读后感10篇

《Linux多线程服务端编程》是一本由陈硕著作，电子工业出版社出版的平装图书，本书定价：89.00元，页数：610，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

《Linux多线程服务端编程》读后感(一)：关键算法有问题

oll模型最关键的算法是如何调度线程池来处理有读写的连接，但是本书在4400位置附近只提了一句：「muduo目前采用最简单的round-robin算法来选取poll中的EventLoop...」。

为什么有问题？1、采用轮询的方法不能保证线程之间调度的公平（即使线程池采用和CPU核数相同的线程数并绑定线程到各核心上），因为有些连接可能读写频繁，有些连接则可能数据寥寥，这样有的核心很忙有的却很闲，如此CPU就未被完全利用；2、如果采用比CPU核心数多的线程，则频繁的轮询调度可能导致频繁地切换线程，性能会大受影响。

也就是说调度的基本粒度应该是每个fd的每个读或者写，而不是每个fd（上所有的读写）。

比较高效地实现应该是Windows的IOCP，不过Linux从2.6Kernel开始已经支持异步IO了，叫做Linux native AIO。

《Linux多线程服务端编程》读后感(二)：linux网络编程力作！

相比APUE和UNP，该书更像一本实战进阶教程。结合作者提供的开源库muduo，向读者很好的展示了linux网络库开发及多线程服务器开发（就网络编程而言现在市面上的中文书无出其右），同时该书也是一本学习现代C 编程的好书。

：我们的游戏项目的网络库参考了muduo并做了一些修改，现在运行非常良好。得益于muduo的良好设计，在移植windows及android平台时没有做过多的修改，特此感谢陈硕的辛勤努力！

：居然有人说水军多！！！ 为了证明我不是水军，发一下我的blog：

《Linux多线程服务端编程》读后感(三)：这本书很实用 -- 在校生视角

首先讲个结论，这本书很实用！

一直以来，不少学长就再三的强调，要想当个好的“后端”程序员，拿好offer，就得扎扎实实把C 学好。到我一直疑惑怎样才算“学好”。同学们似乎把学好就定位在“记得各种语法细节”。学校里使用C 的太少了，不如 java 和 python 开发来得快。另外，优秀的C 开源项目太少。因 此，C 的“实战”之路不好走。

这本书的可贵之处在于“有源码” ， “有引用”。其实看源码就跟写作看别人的文章一样。从别人的文章里学技巧，这比一般的经验分享有用多了。第二是有“引用”。由于书本篇幅的限制和主题表达的需要。作者在写书无法把资料的信息全部阐述，写下资料的出处，想深入了解的就可以自己去读。这资料是作者日积月累攒下的，省了读者不少事。大开我眼界。

最后跟作者说声谢谢，写书不易。期待他的下一本著作。

《Linux多线程服务端编程》读后感(四)：即便不讲C ，书也很有趣

草草翻阅了一遍很

有意思，C 部分很多没看懂的，准备买本深读。

比如 ntp 的实现原理，多线程下为何不能 fork，还有 timefd的使用，好像没讲eventfd，BlockingQueue 确实也非常好用。

timing-wheel 的图，个人觉得有点坑爹，轮盘上的刻度容易误解。另外 evbuffer 讲的太繁琐了，耗费了几页纸。

Linux 现在真心缺少讲网络编程的书籍，也许是richard stevens 高度太高弄得后人无从下手？

如今内核日新月异，新增了很多有用的系统调用，及其期待好书的出现能综合的介绍，不过这种深刻 理解协议栈 然后回头写用户态程序的人也许真的很少。

作者旁征博引的能力很强。

《Linux多线程服务端编程》读后感(五)：水军很多啊

9.1分，尼玛，坑谁呢。。。。。

看这里，比较客观

muduo适用于什么环境？

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的，有几个？而如果是从编程初学者教育的角度来看，是介绍

OSIX重要，还是介绍2.6.22引入的一个new feature重要？

而抛弃signal的处理之后，muduo自然轻松了许多，还顺带可以说一句：muduo支持高

级特性signalfd。--嗯，听起来很高级，不过signalfd不是muduo支持的，而是kernel支

持的。

一个网络编程库，timer是重中之重线程池linux，比到底是用epoll还是select都重要。当然，话说回

来，再吊的库无非也就是个heap为本的数据结构在支持，无非是有些库喜欢说自己的

heap实现比别人都高效，比如haproxy。

但muduo却独辟蹊径，用timerfd，泥玛又是一个高级特性啊，很唬人的。由kernel帮你

管理timer，是不是很吊。

不仅采用了timerfd，muduo还采用了set来保存event，每个big loop里要查超时的时

候，再iterate一遍这个set。

再然后，每次加一个timer，就要冒着一次settime的syscall的风险--这还不够，还得要一

次gettimeofday。别不把syscall当不要钱的可以吗？

你也许可以跑10万个连接，但你敢加上超时的特性吗？muduo如果有做过细致的

enchmark就会知道，一个loop里最花时间的就是timer的处理。

关于muduo的timer处理，槽点太多，我就不一一细述了。回头看看timer，很显然不适

合工业应用，而给初学者做参考。。。嗯，负面参考价值很大。

嗯，今天先说这么多吧。吐槽点还很多，比如那个全功能的http范例，比如对

thread/fork的支持，比如对内存的使用等等等等。都要一一吐过也不是不可以，不过就

要耐下性子来慢慢写就是。

《Linux多线程服务端编程》读后感(六)：为什么推荐Linux多线程服务端编程。 转自我的知乎。

个人感受，这本书写的非常好，也非常用心。但悲观的说，如果一遍看不懂的话，主要是因为缺乏经验。而且，我也并不认为缺乏经验的同学会通过只看书看几次就能看懂。

我觉得技术书籍可能分为几个层次。最上层可能是哲学，中层可能是方法论，最下层是技术说明。比如，技术说明可能是，API 某某可以干什么？XX语言怎么用？这种书籍的阅读需要的经验偏低，可以直接阅读。

到了方法论这个级别，就会说，解决一个问题有很多方法。这些方法哪些是不靠谱的。哪些是常用的，哪些是最佳实践。

而这本书的出色的地方就是基本上是在方法论及以上这个级别来谈问题。这种级别的书，读起来并不再是作者说什么，读者接受什么的过程了。而是一个思辨，对抗，统一的思维过程了。

比如书中说（凭着记忆回忆，不一定完全一致），多线程直接用锁应该用什么锁？读到这里，把书盖上，问问自己，自己会用什么锁？可能有读写锁，有mutex，有spinlock。这些东西自己会怎么用？为什么这么用？

ok，自己想明白之后，再看陈硕的书里怎么写的。也许大多数想法和自己一样。也许差的很远。但，对比自己

和陈硕的思考过程，就能知道他牛逼的地方。自己也就提升了。

所以，对于这种书里的问题，没有自己的思考和经验，很难看下去。

顺便多聊一下。明白自己缺乏经验不是坏事。因为时间对大家基本平等，早明白这一点就可以早提升经验。提升的方法有两点。一个是阅读和自己经验更接近的方法论书籍，另一个是实践，写一个自己认为足够困难的东西。另外经验也是分领域的。让我写vue之类的，我也没经验。

另外一点，方法论的书籍，如果还是按照普通说明性质的书籍读。记住了xxx有什么功能。其实感觉收益不是最大的。我也在自己刚学编程的半年后读head first 设计模式。读了几遍也不知道为啥。过几年后重读，发现几个小时左右就全明白了。不过，这类书籍早期看过也不是坏事，只是之后拿起来重读就好了。

还有一种书籍，或者文章。是哲学级别的。比如python的import this。这个其实更容易读懂，因为基本都是大实话。但是，也更难实践。就是很多人说的，道理我都懂，过不好一生一样。

跑的有点偏，总结起来。这本书是方法论和哲学层次的书，阅读这类书都有很大的经验门槛。如果读不懂，这很正常。不要觉得缺乏经验不好，可以先补充这方面的经验。

大概这样吧，顺便感谢作者贡献。

《Linux多线程服务端编程》读

后感(七)：说实话这个库很渣

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

muduo更像是新手练手的东西堆砌而成, 所以, 这是只能算是个然并卵的东西.

而这本书, 就是新手的笔记堆砌而成.

不推荐.

《Linux多线程服务端编程》读后感(八)：推荐《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 设计”理念，在编程中挑选 boost 库中久经考验的、优秀的子库善加应用，比如“使用 boost::function 和 boost::bind 取代虚函数”，减少代码的同时获得非常可靠的代码质量，是非常值得我们学习借鉴的。

这本书展示了基础的重要性。直接读，可以发现很多章节讲的内容都可以说是常识，但是作为一名久经考验的程序员，可以说，我觉得这里面讲的常识都是“一不留神坑死你”的。比如“shared_ptr 技术与陷阱”一节中，作者提到析构的线程不一定是是对象诞生的线程，我的膝盖就中过一箭。当时我为一个动作游戏编写非玩家角色的人工智能，在游戏中，大部分 CPU 资源都被用在图形渲染上，留给人工智能的资源非常有限，我又要做计算量超大的团队人工智能，所以很“卡”。后来的优化方案是把内存释放操作放到另一条线程去执行，虽然当时没有使用 shared_ptr，但因为问题的原因和解决方案都是一样的，如果我们当时都读过这本书，应该不会踏入这个坑。如果有出身草莽的野路子程序员，读一下这本书，应该还是大有补益的。

这本书展示了对业务理解的重要性。无论是 muduo 库，还是这本书，都没有想做到面面俱到。对于 muduo，作者追求的是完成业务领域的需求，并压榨硬件的极限；对于这本书，作者讲求的是“经验与实践”，并

没有把这本书写成枕头书，而是把“应当注意的、我这样做的理由”讲得通透。说老实话，读这本书，感觉到作者就像一对一的培训那么贴心。

虽然我从 2013 年起，以 web 开发和团队管理工作为主，已经不写基于 TCP 协议的服务器端程序，甚至“几乎不使用 C ”三年了，但阅读这本书仍然极有意义：一是理解 Linux 关于网络方面的新特性，这一块对我现在做基于 HTTP 协议的开发工作也是极有帮助的；二是理解多线程的最佳实践，其实工作中免不了多少要跟多线程打交道，掌握这方面的最佳实践，在遇到使用场景时，可以马上给出“没大错”的方案；三是理解 C ，跟上它的发展，这对于我编写、学习其它编程语言也极有指导意义。当然，对于我朋友这种从客户端转过来服务器端的程序员来说，最重要的是能够快速地写出“正统的”服务器端代码了。

（编辑：财气旺网 - 财气网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!