多线程服务器适用场合

前提

  • 进程”指的是fork(2)系统调用的产物

  • 线程”指的是pthread_create()的产物,因此是宝贵的那种原生线程。而且Pthreads是NPTL的,每个线程由clone(2)产生,对应一个内核的task_struct。

Pthreads是一组线程操作的标准,NPTL是 Native POSIX Thread Library 的缩写,是Linux上实现Pthreads标准的一个库。NPTL是Pthreads在Linux平台上的具体实现。NPTL提供了线程创建、同步、互斥、条件变量等功能。

必须使用单线程的场合

  1. 程序可能会 fork(2);

  2. 限制程序的CPU占用率。 8核服务器,单线程只在一个核上跑,cpu使用率也只有 12.5%

一个程序fork(2)之后一般有两种行为:

1. 立刻执行exec(),变身为另一个程序。例如shell和inetd;又比如 lighttpd fork()出子进程,然后运行fastcgi程序。或者集群中运行在计算节点上的负责启动job的守护进程。

2. 不调用exec(),继续运行当前程序。要么通过共享的文件描述符与父进程通信,协同完成任务;要么接过父进程传来的文件描述符,独立完成工作。

event loop 的缺点

添加图片注释,不超过 140 字(可选)

多线程没有绝对的性能优势

  • IO Bound 和CPU Bound ,任何一方早早先达到瓶颈,多线程都没有啥优势!

  • IO bound和CPU bound是指在计算机系统中,任务执行的瓶颈主要是由I/O操作或者CPU运算所决定。

IO bound(输入输出受限)是指任务的执行时间主要被I/O操作所消耗。CPU的利用率相对较低,大部分时间会处于等待I/O完成的状态。

CPU bound(计算受限)是指任务的执行时间主要被CPU计算所消耗。计算密集型任务,CPU的利用率相对较高,大部分时间会用于执行计算操作。

  • 如果任务是IO bound,则可能需要优化I/O子系统来提高整体性能;

  • 如果任务是CPU bound,则可能需要考虑使用多线程、并行处理等方式来充分利用 CPU 资源。

适用多线程程序的场景

目的

提高响应速度,让IO和“计算”相互重叠,降低latency延迟。虽然多线程不能提高绝对性能,但能提高平均响应性能。

一个程序要做成多线程的,大致要满足:

  • 有多个CPU可用。

  • 线程间有共享数据,即内存中的全局状态。

  • 共享的数据是可以修改的,而不是静态的常量表。如果数据不能修改,那么可以在进程间用 shared memory

  • 提供非均质的服务。即事件的响应有优先级差异,可以用专门的线程来处理优先级高的事件。防止优先级反转。

  • latency (延迟 )和throughput (吞吐量) 同样重要,不是逻辑简单的IO bound或CPU bound程序。换言之,程序要有相当的计算量。

  • 利用异步操作。比如logging。无论往磁盘写log file,还是往log server发送消息都不应该阻塞关键路径。

  • 能 scale up。一个好的多线程程序应该能享受增加CPU数目带来的好处。

  • 具有可预测的性能。随着负载增加,性能缓慢下降,超过某个临界点之后会急速下降。线程数目一般不随负载变化。

  • 多线程能有效地划分责任与功能,让每个线程的逻辑比较简单,任务单一,便于编码。而不是把所有逻辑都塞到一个event loop里,不同类别的事件之间相互影响。

  • 24
    点赞
  • 18
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
《Linux多线程服务端编程:使用muduo C++网络库》主要讲述采用现代C++在x86-64 Linux上编写多线程TCP网络服务程序的主流常规技术,重点讲解一种适应性较强的多线程服务器的编程模型,即one loop per thread。 目 录 第1部分C++ 多线程系统编程 第1章线程安全的对象生命期管理3 1.1当析构函数遇到多线程. . . . . . . . . . . . . . . . .. . . . . . . . . . . 3 1.1.1线程安全的定义. . . . . . . . . . . . . . . . .. . . . . . . . . . . 4 1.1.2MutexLock 与MutexLockGuard. . . . . . . . . . . . . . . . . . . . 4 1.1.3一个线程安全的Counter 示例.. . . . . . . . . . . . . . . . . . . 4 1.2对象的创建很简单. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 5 1.3销毁太难. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 7 1.3.1mutex 不是办法. . . . . . . . . . . . . . . . . . . .. . . . . . . . 7 1.3.2作为数据成员的mutex 不能保护析构.. . . . . . . . . . . . . . 8 1.4线程安全的Observer 有多难.. . . . . . . . . . . . . . . . . . . . . . . . 8 1.5原始指针有何不妥. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 11 1.6神器shared_ptr/weak_ptr . . . . . . . . . .. . . . . . . . . . . . . . . . 13 1.7插曲:系统地避免各种指针错误. . . . . . . . . . . . . . . . .. . . . . . 14 1.8应用到Observer 上.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.9再论shared_ptr 的线程安全.. . . . . . . . . . . . . . . . . . . . . . . . 17 1.10shared_ptr 技术与陷阱. . . .. . . . . . . . . . . . . . . . . . . . . . . . 19 1.11对象池. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 21 1.11.1enable_shared_from_this . . . . . . . . . . . . . . . . . . . . . . 23 1.11.2弱回调. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 24 1.12替代方案. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 26 1.13心得与小结. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 26 1.14Observer 之谬. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 第2章线程同步精要 2.1互斥器(mutex). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.1.1只使用非递归的mutex . . . . . . . . . . . . . .. . . . . . . . . . 33 2.1.2死锁. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 35 2.2条件变量(condition variable). . . . . . . . . .

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值