线程数，512是否合理？

​Web-Server有个配置，工作线程数。,Service一般也有个配置，工作线程数。,经验丰富的架构师，懂得如何配置这些参数，使得系统的性能达到最优：有些业务设置为CPU核数的2倍，有些业务设置为CPU核数的8倍，有些业务设置为CPU核数的32倍。,“线程数”的设置依据，是本文要讨论的问题。,,答案显然是否定的：,不占用，休眠时会把CPU让出来，给其他需要CPU资源的线程使用。,不止sleep，一些阻塞调用，例如网络编程中的：,都会让出CPU资源。,即使是单核，使用多线程也是有意义的，大多数情况也能提高并发：,了解常见的服务线程模型，有助于理解服务并发的原理，一般来说互联网常见的服务线程模型有两种：,,如上图，大部分Web-Server与服务框架都是使用这样的一种“IO线程与Worker线程通过队列解耦”类线程模型：,这个线程模型应用很广，符合大部分场景，这个线程模型的特点是，工作线程内部是同步阻塞执行任务的，因此可以通过增加Worker线程数来增加并发能力，今天要讨论的重点是“该模型Worker线程数设置为多少能达到最大的并发”。,没有阻塞，这种线程模型只需要设置很少的线程数就能够做到很高的吞吐量，该模型的缺点是：,however，这个模型不是今天讨论的重点。,了解工作线程的工作模式，对量化分析线程数的设置非常有帮助：,上图是一个典型的工作线程的处理过程，从开始处理start到结束处理end，该任务的处理共有7个步骤：,分析整个处理的时间轴，会发现：,(1) 其中1，3，5，7步骤中（上图中粉色时间轴），线程进行本地业务逻辑计算时需要占用CPU；,(2) 而2，4，6步骤中（上图中橙色时间轴），访问cache、service、DB过程中线程处于一个等待结果的状态，不需要占用CPU，进一步的分解，这个“等待结果”的时间共分为三部分：,通过上面的分析，Worker线程在执行的过程中：,通过量化分析，例如打日志进行统计，可以统计出整个Worker线程执行过程中这两部分时间的比例，例如：,得到的结果是，这个线程计算和等待的时间是1：1，即有50%的时间在计算（占用CPU），50%的时间在等待（不占用CPU）：,结论来了：,N核服务器，通过执行业务的单线程分析出本地计算时间为x，等待时间为y，则工作线程数（线程池线程数）设置为 N*(x+y)/x，能让CPU的利用率最大化。,一般来说，非CPU密集型的业务（加解密、压缩解压缩、搜索排序等业务是CPU密集型的业务），瓶颈都在后端数据库访问或者RPC调用，本地CPU计算的时间很少，所以设置几十或者几百个工作线程是能够提升吞吐量的。​