(3)如果cpu是单核的,设置多线程有什么意义,能提高并发性能么?
即使是单核,使用多线程也是有意义的
a.多线程编码可以让我们的服务/代码更加清晰,有些IO线程收发包,有些Worker线程进行任务处理,有些Timeout线程进行超时检测
b.如果有一个任务一直占用CPU资源在进行计算,那么此时增加线程并不能增加并发,例如这样的一个代码
while(1){ i++; }
该代码一直不停的占用CPU资源进行计算,会使CPU占用率达到100%
c.通常来说,Worker线程一般不会一直占用CPU进行计算,此时即使CPU是单核,增加Worker线程也能够提高并发,因为这个线程在休息的时候,其他的线程可以继续工作
如上图,大部分Web-Server与服务框架都是使用这样的一种“IO线程与Worker线程通过队列解耦”类线程模型:
1)有少数几个IO线程监听上游发过来的请求,并进行收发包(生产者)
2)有一个或者多个任务队列,作为IO线程与Worker线程异步解耦的数据传输通道(临界资源)
3)有多个工作线程执行正真的任务(消费者)
这个线程模型应用很广,符合大部分场景,这个线程模型的特点是,工作线程内部是同步阻塞执行任务的(回想一下tomcat线程中是怎么执行Java程序的,dubbo工作线程中是怎么执行任务的),因此可以通过增加Worker线程数来增加并发能力,今天要讨论的重点是“该模型Worker线程数设置为多少能达到最大的并发”。
上图是一个典型的工作线程的处理过程,从开始处理start到结束处理end,该任务的处理共有7个步骤:
1)从工作队列里拿出任务,进行一些本地初始化计算,例如http协议分析、参数解析、参数校验等
2)访问cache拿一些数据
3)拿到cache里的数据后,再进行一些本地计算,这些计算和业务逻辑相关
4)通过RPC调用下游service再拿一些数据,或者让下游service去处理一些相关的任务
5)RPC调用结束后,再进行一些本地计算,怎么计算和业务逻辑相关
6)访问DB进行一些数据操作
7)操作完数据库之后做一些收尾工作,同样这些收尾工作也是本地计算,和业务逻辑相关
分析整个处理的时间轴,会发现:
1)其中1,3,5,7步骤中【上图中粉色时间轴】,线程进行本地业务逻辑计算时需要占用CPU
2)而2,4,6步骤中【上图中橙色时间轴】,访问cache、service、DB过程中线程处于一个等待结果的状态,不需要占用CPU,进一步的分解,这个“等待结果”的时间共分为三部分:
2.1)请求在网络上传输到下游的cache、service、DB
2.2)下游cache、service、DB进行任务处理
2.3)cache、service、DB将报文在网络上传回工作线程
最后一起来回答工作线程数设置为多少合理的问题。
通过上面的分析,Worker线程在执行的过程中,有一部计算时间需要占用CPU,另一部分等待时间不需要占用CPU,通过量化分析,例如打日志进行统计,可以统计出整个Worker线程执行过程中这两部分时间的比例,例如:
1)时间轴1,3,5,7【上图中粉色时间轴】的计算执行时间是100ms
2)时间轴2,4,6【上图中橙色时间轴】的等待时间也是100ms
得到的结果是,这个线程计算和等待的时间是1:1,即有50%的时间在计算(占用CPU),50%的时间在等待(不占用CPU):
1)假设此时是单核,则设置为2个工作线程就可以把CPU充分利用起来,让CPU跑到100%
2)假设此时是N核,则设置为2N个工作现场就可以把CPU充分利用起来,让CPU跑到N*100%
结论:
N核服务器,通过执行业务的单线程分析出本地计算时间为x,等待时间为y,则工作线程数(线程池线程数)设置为 N*(x+y)/x,能让CPU的利用率最大化。
总结:对于非阻塞的服务,线程数直接和CPU个数一样就可以了;对于网络调用等有阻塞的服务,CPU并没有完全占用,可以增加线程(找到个最优值)。N核服务器,通过执行业务的单线程分析出本地计算时间为x,等待时间为y,则工作线程数(线程池线程数)设置为 N*(x+y)/x,能让CPU的利用率最大化。
部分内容转自:http://www.jianshu.com/p/ad7a889598e5