java面试题：服务器的线程设置多少合适

线程数设多少合适？？

提问：工作线程数是不是设置的越大越好？
回答：肯定不是的
1）一来服务器CPU核数有限，同时并发的线程数是有限的，1核CPU设置10000个工作线程没有意义
2）线程切换是有开销的，如果线程切换过于频繁，反而会使性能降低

提问：如果CPU是单核，设置多线程有意义么，能提高并发性能么？
回答：即使是单核，使用多线程也是有意义的
1）多线程编码可以让我们的服务/代码更加清晰，有些IO线程收发包，有些Worker线程进行任务处理，有些Timeout线程进行超时检测
2）如果有一个任务一直占用CPU资源在进行计算，那么此时增加线程并不能增加并发，例如这样的一个代码
while(1){ i++; }
该代码一直不停的占用CPU资源进行计算，会使CPU占用率达到100%
3）通常来说，Worker线程一般不会一直占用CPU进行计算，此时即使CPU是单核，增加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密集型的业务），瓶颈都在后端数据库，本地CPU计算的时间很少，所以设置几十或者几百个工作线程也都是可能的。