线程数,512是否合理?
Web-Server有个配置，工作线程数。
Service一般也有个配置，工作线程数。
经验丰富的架构师，懂得如何配置这些参数，使得系统的性能达到最优：有些业务设置为CPU核数的2倍，有些业务设置为CPU核数的8倍，有些业务设置为CPU核数的32倍。
“线程数”的设置依据 ，是本文要讨论的问题。
工作线程数是不是设置的越大越好？ 答案显然是 否定的 ： （1）服务器CPU核数有限，能够同时并发的线程数有限，单核CPU设置1000个工作线程没有意义； （2）线程切换有开销 ，如果线程切换过于频繁，反而会使性能降低；
调用sleep()函数的时候，线程是否一直占用CPU？ 不占用 ，休眠时会把CPU让出来，给其他需要CPU资源的线程使用。
不止sleep， 一些阻塞调用 ，例如网络编程中的： （1）阻塞accept()，等待客户端连接； （2）阻塞recv()，等待下游回包； 都会让出CPU资源 。
单核CPU，设置多线程有意义么？ 单核CPU，设置多线程能否提高并发性能？ 即使是单核，使用多线程也是 有意义 的，大多数情况也 能提高并发 ： （1）多线程编码可以让代码更加清晰 ，例如：IO线程收发包，Worker线程进行任务处理，Timeout线程进行超时检测； （2）如果有一个任务一直占用CPU资源在进行计算，此时增加线程并不能增加并发，例如以下代码会一直占用CPU，并使得CPU占用率达到100%： while(1){ i++; } （3）通常来说，Worker线程一般不会一直占用CPU进行计算，此时即使CPU是单核，增加Worker线程也能够提高并发，因为这个线程在休息的时候，其他的线程可以继续工作；
第一种，IO线程与工作线程通过队列解耦类模型。
如上图，大部分Web-Server与服务框架都是使用这样的一种“IO线程与Worker线程通过队列解耦”类线程模型： （1）有少数几个IO线程监听上游发过来的请求，并进行收发包（生产者）； （2）有一个或者多个任务队列，作为IO线程与Worker线程异步解耦的数据传输通道（临界资源）； （3）有多个工作线程执行真正的任务（消费者）；
这个线程模型应用很广，符合大部分场景，这个线程模型的特点是，工作线程内部是同步阻塞执行任务的，因此 可以通过增加Worker线程数来增加并发能力 ，今天要讨论的重点是“该模型Worker线程数设置为多少能达到最大的并发”。 第二种，纯异步线程模型。 没有阻塞，这种线程模型只需要设置很少的线程数就能够做到很高的吞吐量，该模型的缺点是： （1）如果使用单线程模式，难以利用多CPU多核的优势； （2）程序员更习惯写同步代码，callback的方式对代码的可读性有冲击，对程序员的要求也更高； （3）框架更复杂，往往需要server端收发组件，server端队列，client端收发组件，client端队列，上下文管理组件，有限状态机组件，超时管理组件的支持；
however，这个模型不是今天讨论的重点。
上图是一个典型的工作线程的处理过程，从开始处理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线程执行过程中这两部分时间的比例，例如： （1）执行计算，占用CPU的时间（粉色时间轴）是100ms； （2）等待时间，不占用CPU的时间（橙色时间轴）也是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密集型的业务），瓶颈都在后端数据库访问或者RPC调用，本地CPU计算的时间很少，所以设置几十或者几百个工作线程是能够提升吞吐量的。
学废了吗？
架构师之路 -分享技术 思路
相关文章： 《线上问题排查，这些命令你一定用得到！》 《CPU100%，怎么快速定位？》
《顶尖的人都是怎么想的！（很残酷）》
思考题 ： 贵司线程数设置为多少？
画外音：随手设了一个200？
经验丰富的架构师，懂得如何配置这些参数，使得系统的性能达到最优：有些业务设置为CPU核数的2倍，有些业务设置为CPU核数的8倍，有些业务设置为CPU核数的32倍。
“线程数”的设置依据 ，是本文要讨论的问题。
工作线程数是不是设置的越大越好？ 答案显然是 否定的 ： （1）服务器CPU核数有限，能够同时并发的线程数有限，单核CPU设置1000个工作线程没有意义； （2）线程切换有开销 ，如果线程切换过于频繁，反而会使性能降低；
调用sleep()函数的时候，线程是否一直占用CPU？ 不占用 ，休眠时会把CPU让出来，给其他需要CPU资源的线程使用。
不止sleep， 一些阻塞调用 ，例如网络编程中的： （1）阻塞accept()，等待客户端连接； （2）阻塞recv()，等待下游回包； 都会让出CPU资源 。
单核CPU，设置多线程有意义么？ 单核CPU，设置多线程能否提高并发性能？ 即使是单核，使用多线程也是 有意义 的，大多数情况也 能提高并发 ： （1）多线程编码可以让代码更加清晰 ，例如：IO线程收发包，Worker线程进行任务处理，Timeout线程进行超时检测； （2）如果有一个任务一直占用CPU资源在进行计算，此时增加线程并不能增加并发，例如以下代码会一直占用CPU，并使得CPU占用率达到100%： while(1){ i++; } （3）通常来说，Worker线程一般不会一直占用CPU进行计算，此时即使CPU是单核，增加Worker线程也能够提高并发，因为这个线程在休息的时候，其他的线程可以继续工作；
常见服务线程模型有几种？
了解常见的服务线程模型，有助于理解服务并发的原理，一般来说互联网常见的服务线程模型有 两种 ： （1）IO线程 与 工作线程 通过 任务队列 解耦； （2）纯异步；第一种，IO线程与工作线程通过队列解耦类模型。
如上图，大部分Web-Server与服务框架都是使用这样的一种“IO线程与Worker线程通过队列解耦”类线程模型： （1）有少数几个IO线程监听上游发过来的请求，并进行收发包（生产者）； （2）有一个或者多个任务队列，作为IO线程与Worker线程异步解耦的数据传输通道（临界资源）； （3）有多个工作线程执行真正的任务（消费者）；
这个线程模型应用很广，符合大部分场景，这个线程模型的特点是，工作线程内部是同步阻塞执行任务的，因此 可以通过增加Worker线程数来增加并发能力 ，今天要讨论的重点是“该模型Worker线程数设置为多少能达到最大的并发”。 第二种，纯异步线程模型。 没有阻塞，这种线程模型只需要设置很少的线程数就能够做到很高的吞吐量，该模型的缺点是： （1）如果使用单线程模式，难以利用多CPU多核的优势； （2）程序员更习惯写同步代码，callback的方式对代码的可读性有冲击，对程序员的要求也更高； （3）框架更复杂，往往需要server端收发组件，server端队列，client端收发组件，client端队列，上下文管理组件，有限状态机组件，超时管理组件的支持；
however，这个模型不是今天讨论的重点。
第一类“IO线程与工作线程通过队列解耦”类线程模型，工作线程的工作模式是怎么样的？
了解工作线程的工作模式，对量化分析线程数的设置非常有帮助：上图是一个典型的工作线程的处理过程，从开始处理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线程在执行的过程中： （1）有一部计算时间需要占用CPU； （2）另一部分等待时间不需要占用CPU；通过量化分析，例如打日志进行统计，可以统计出整个Worker线程执行过程中这两部分时间的比例，例如： （1）执行计算，占用CPU的时间（粉色时间轴）是100ms； （2）等待时间，不占用CPU的时间（橙色时间轴）也是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密集型的业务），瓶颈都在后端数据库访问或者RPC调用，本地CPU计算的时间很少，所以设置几十或者几百个工作线程是能够提升吞吐量的。
学废了吗？
架构师之路 -分享技术 思路
相关文章： 《线上问题排查，这些命令你一定用得到！》 《CPU100%，怎么快速定位？》
《顶尖的人都是怎么想的！（很残酷）》
思考题 ： 贵司线程数设置为多少？
画外音：随手设了一个200？
评论