graphqljava线程池大小

并发线程池到底设置多大呢？

通常有点年纪的程序员或许都听说这样一个说法 （其中 N 代表 CPU 的个数）

CPU 密集型应用，线程池大小设置为 N + 1

IO 密集型应用，线程池大小设置为 2N

这个说法到底是不是正确的呢？

其实这是极不正确的。那为什么呢？

首先我们从反面来看，假设这个说法是成立的，那我们在一台服务器上部署多少个服务都无所谓了。因为线程池的大小只能服务器的核数有关，所以这个说法是不正确的。那具体应该怎么设置大小呢？

假设这个应用是两者混合型的，其中任务即有 CPU 密集，也有 IO 密集型的，那么我们改怎么设置呢？是不是只能抛硬盘来决定呢？

那么我们到底该怎么设置线程池大小呢？有没有一些具搭厅体实践方键亩法来指导大家落地呢？让我们来深入地了知亮隐解一下。

Little's Law（利特尔法则）

一个系统请求数等于请求的到达率与平均每个单独请求花费的时间之乘积

假设服务器单核的，对应业务需要保证请求量（QPS）：10 ，真正处理一个请求需要 1 秒，那么服务器每个时刻都有 10 个请求在处理，即需要 10 个线程

同样，我们可以使用利特尔法则（Little's law）来判定线程池大小。我们只需计算请求到达率和请求处理的平均时间。然后，将上述值放到利特尔法则（Little's law）就可以算出系统平均请求数。估算公式如下

*线程池大小 = （（线程 IO time + 线程 CPU time ）/线程 CPU time ） CPU数目**

具体实践

通过公式，我们了解到需要 3 个具体数值

一个请求所消耗的时间 (线程 IO time + 线程 CPU time)

该请求计算时间 （线程 CPU time）

CPU 数目

请求消耗时间

Web 服务容器中，可以通过 Filter 来拦截获取该请求前后消耗的时间

找的资料，你看一下吧：\x0d\x0a多线程技术主要解决处理器单元内多个线程执行的问题，裤哗它可以显著减让汪少处理器单元的闲置时间，增加处理器单元的吞吐能力。\x0d\x0a\x0d\x0a假设一个服务器完成一项任务所需时间为：T1 创建线程时间，T2 在线程中执行任务的时间，T3 销毁线程时间。\x0d\x0a\x0d\x0a如果：T1 + T3 远大于 T2，则可以采用线程池，以提高坦纯仔服务器性能。\x0d\x0a一个线程池包括以下四个基本组成部分：\x0d\x0a1、线程池管理器（ThreadPool）：用于创建并管理线程池，包括 创建线程池，销毁线程池，添加新任务；\x0d\x0a2、工作线程（PoolWorker）：线程池中线程，在没有任务时处于等待状态，可以循环的执行任务；\x0d\x0a3、任务接口（Task）：每个任务必须实现的接口，以供工作线程调度任务的执行，它主要规定了任务的入口，任务执行完后的收尾工作，任务的执行状态等；\x0d\x0a4、任务队列（taskQueue）：用于存放没有处理的任务。提供一种缓冲机制。\x0d\x0a\x0d\x0a线程池技术正是关注如何缩短或调整T1,T3时间的技术，从而提高服务器程序性能的。它把T1，T3分别安排在服务器程序的启动和结束的时间段或者一些空闲的时间段，这样在服务器程序处理客户请求时，不会有T1，T3的开销了。\x0d\x0a\x0d\x0a线程池不仅调整T1,T3产生的时间段，而且它还显著减少了创建线程的数目，看一个例子：\x0d\x0a\x0d\x0a假设一个服务器一天要处理50000个请求，并且每个请求需要一个单独的线程完成。在线程池中，线程数一般是固定的，所以产生线程总数不会超过线程池中线程的数目，而如果服务器不利用线程池来处理这些请求则线程总数为50000。一般线程池大小是远小于50000。所以利用线程池的服务器程序不会为了创建50000而在处理请求时浪费时间，从而提高效率。

---