加了循环后如何计算并发数_线程数，射多少最合理？

Web-Server有个配置&＃xff0c;工作线程数。

Service一般也有个配置&＃xff0c;工作线程数。

经验丰富的架构师&＃xff0c;懂得如何配置这些参数&＃xff0c;使得系统的性能达到最优&＃xff1a;有些业务设置为CPU核数的2倍&＃xff0c;有些业务设置为CPU核数的8倍&＃xff0c;有些业务设置为CPU核数的32倍。

“线程数”的设置依据&＃xff0c;是本文要讨论的问题。

工作线程数是不是设置的越大越好&＃xff1f;

答案显然是否定的&＃xff1a;

• 服务器CPU核数有限&＃xff0c;能够同时并发的线程数有限&＃xff0c;单核CPU设置1000个工作线程没有意义

• 线程切换有开销&＃xff0c;如果线程切换过于频繁&＃xff0c;反而会使性能降低

调用sleep()函数的时候&＃xff0c;线程是否一直占用CPU&＃xff1f;

不占用&＃xff0c;休眠时会把CPU让出来&＃xff0c;给其他需要CPU资源的线程使用。

不止sleep&＃xff0c;一些阻塞调用&＃xff0c;例如网络编程中的&＃xff1a;

• 阻塞accept()&＃xff0c;等待客户端连接

• 阻塞recv()&＃xff0c;等待下游回包

都会让出CPU资源。

单核CPU&＃xff0c;设置多线程有意义么&＃xff1f;

单核CPU&＃xff0c;设置多线程能否提高并发性能&＃xff1f;

即使是单核&＃xff0c;使用多线程也是有意义的&＃xff0c;大多数情况也能提高并发&＃xff1a;

• 多线程编码可以让代码更加清晰&＃xff0c;例如&＃xff1a;IO线程收发包&＃xff0c;Worker线程进行任务处理&＃xff0c;Timeout线程进行超时检测

• 如果有一个任务一直占用CPU资源在进行计算&＃xff0c;此时增加线程并不能增加并发&＃xff0c;例如以下代码会一直占用CPU&＃xff0c;并使得CPU占用率达到100%&＃xff1a;

   while(1){ i&＃43;&＃43;; }

• 通常来说&＃xff0c;Worker线程一般不会一直占用CPU进行计算&＃xff0c;此时即使CPU是单核&＃xff0c;增加Worker线程也能够提高并发&＃xff0c;因为这个线程在休息的时候&＃xff0c;其他的线程可以继续工作

常见服务线程模型有几种&＃xff1f;

了解常见的服务线程模型&＃xff0c;有助于理解服务并发的原理&＃xff0c;一般来说互联网常见的服务线程模型有两种&＃xff1a;

• IO线程与工作线程通过任务队列解耦

• 纯异步

第一种&＃xff0c;IO线程与工作线程通过队列解耦类模型。

如上图&＃xff0c;大部分Web-Server与服务框架都是使用这样的一种“IO线程与Worker线程通过队列解耦”类线程模型&＃xff1a;

• 有少数几个IO线程监听上游发过来的请求&＃xff0c;并进行收发包(生产者)

• 有一个或者多个任务队列&＃xff0c;作为IO线程与Worker线程异步解耦的数据传输通道(临界资源)

• 有多个工作线程执行正真的任务(消费者)

这个线程模型应用很广&＃xff0c;符合大部分场景&＃xff0c;这个线程模型的特点是&＃xff0c;工作线程内部是同步阻塞执行任务的&＃xff0c;因此可以通过增加Worker线程数来增加并发能力&＃xff0c;今天要讨论的重点是“该模型Worker线程数设置为多少能达到最大的并发”。

第二种&＃xff0c;纯异步线程模型。

没有阻塞&＃xff0c;这种线程模型只需要设置很少的线程数就能够做到很高的吞吐量&＃xff0c;该模型的缺点是&＃xff1a;

• 如果使用单线程模式&＃xff0c;难以利用多CPU多核的优势

• 程序员更习惯写同步代码&＃xff0c;callback的方式对代码的可读性有冲击&＃xff0c;对程序员的要求也更高

• 框架更复杂&＃xff0c;往往需要server端收发组件&＃xff0c;server端队列&＃xff0c;client端收发组件&＃xff0c;client端队列&＃xff0c;上下文管理组件&＃xff0c;有限状态机组件&＃xff0c;超时管理组件的支持

however&＃xff0c;这个模型不是今天讨论的重点。

第一类“IO线程与工作线程通过队列解耦”类线程模型&＃xff0c;工作线程的工作模式是怎么样的&＃xff1f;

了解工作线程的工作模式&＃xff0c;对量化分析线程数的设置非常有帮助&＃xff1a;

上图是一个典型的工作线程的处理过程&＃xff0c;从开始处理start到结束处理end&＃xff0c;该任务的处理共有7个步骤&＃xff1a;

(1)从工作队列里拿出任务&＃xff0c;进行一些本地初始化计算&＃xff0c;例如http协议分析、参数解析、参数校验等&＃xff1b;

(2)访问cache拿一些数据&＃xff1b;

(3)拿到cache里的数据后&＃xff0c;再进行一些本地计算&＃xff0c;这些计算和业务逻辑相关&＃xff1b;

(4)通过RPC调用下游service再拿一些数据&＃xff0c;或者让下游service去处理一些相关的任务&＃xff1b;

(5)RPC调用结束后&＃xff0c;再进行一些本地计算&＃xff0c;怎么计算和业务逻辑相关&＃xff1b;

(6)访问DB进行一些数据操作&＃xff1b;

(7)操作完数据库之后做一些收尾工作&＃xff0c;同样这些收尾工作也是本地计算&＃xff0c;和业务逻辑相关&＃xff1b;

分析整个处理的时间轴&＃xff0c;会发现&＃xff1a;

• 其中1&＃xff0c;3&＃xff0c;5&＃xff0c;7步骤中(上图中粉色时间轴)&＃xff0c;线程进行本地业务逻辑计算时需要占用CPU

• 而2&＃xff0c;4&＃xff0c;6步骤中(上图中橙色时间轴)&＃xff0c;访问cache、service、DB过程中线程处于一个等待结果的状态&＃xff0c;不需要占用CPU&＃xff0c;进一步的分解&＃xff0c;这个“等待结果”的时间共分为三部分&＃xff1a;

  2.1)请求在网络上传输到下游的cache、service、DB

  2.2)下游cache、service、DB进行任务处理

  2.3)cache、service、DB将报文在网络上传回工作线程

如何量化分析&＃xff0c;并合理设置工作线程数呢&＃xff1f;

通过上面的分析&＃xff0c;Worker线程在执行的过程中&＃xff1a;

• 有一部计算时间需要占用CPU

• 另一部分等待时间不需要占用CPU

通过量化分析&＃xff0c;例如打日志进行统计&＃xff0c;可以统计出整个Worker线程执行过程中这两部分时间的比例&＃xff0c;例如&＃xff1a;

• 执行计算&＃xff0c;占用CPU的时间(粉色时间轴)是100ms

• 等待时间&＃xff0c;不占用CPU的时间(橙色时间轴)也是100ms

得到的结果是&＃xff0c;这个线程计算和等待的时间是1&＃xff1a;1&＃xff0c;即有50%的时间在计算(占用CPU)&＃xff0c;50%的时间在等待(不占用CPU)&＃xff1a;

• 假设此时是单核&＃xff0c;则设置为2个工作线程就可以把CPU充分利用起来&＃xff0c;让CPU跑到100%

• 假设此时是N核&＃xff0c;则设置为2N个工作现场就可以把CPU充分利用起来&＃xff0c;让CPU跑到N*100%

当当当当&＃xff01;&＃xff01;&＃xff01;

结论来了&＃xff1a;

N核服务器&＃xff0c;通过执行业务的单线程分析出本地计算时间为x&＃xff0c;等待时间为y&＃xff0c;则工作线程数(线程池线程数)设置为 N*(x&＃43;y)/x&＃xff0c;能让CPU的利用率最大化。

一般来说&＃xff0c;非CPU密集型的业务(加解密、压缩解压缩、搜索排序等业务是CPU密集型的业务)&＃xff0c;瓶颈都在后端数据库访问或者RPC调用&＃xff0c;本地CPU计算的时间很少&＃xff0c;所以设置几十或者几百个工作线程是能够提升吞吐量的。

GET新技能了吗&＃xff1f;

相关文章&＃xff1a;

《缓冲池(buffer pool)》

《写缓冲(change buffer)》

《日志缓冲(log buffer)》

思考题&＃xff1a;

贵司线程数设置为多少&＃xff1f;

画外音&＃xff1a;随手设了一个200&＃xff1f;