线程池及异步请求的意义

柔情只为你懂 2022-06-06 09:51 198阅读 0赞

异步请求和线程的相关，在讲异步请求前，我们先说说线程及线程池的问题。

正常我们使用tomcat作为项目容器启动时，一般会配置线程池。如果不配置线程池，那么每次接收到请求时总会新生成一个线程，在请求结束时，销毁之前的线程。线程的生成和销毁是很耗费资源的，而定义线程池能让线程复用，避免了线程频繁的生成和注销，提高了服务器的 资源利用率。

如何设置线程池内线程的数量呢？这和服务器的CPU实际线程数量和项目的相关。假设我们服务器是10核20线程的，也就是说我们的物理线程有20，也就是说如果项目内同一时间并行的处理消耗CPU资源的线程最多只有20个。注意是**并行**，不是并发，他们是两个概念。并行是指同一时间处理任务，而并发一般是指一段时间，比如一秒内能处理多少的请求数。在处理一个请求时，部分阶段消耗的是CPU资源，大部分阶段都是消耗IO资源，一个物理线程在处理请求其消耗CPU资源的阶段是不能再处理其他的请求的；而在消耗IO资源阶段，是线程阻塞的，此时会释放CPU资源，物理线程可以去处理其他的请求，其中会涉及到线程的上下文切换。**CPU资源就这样在多个请求间切换，在处理完请求的CPU密集阶段后会切换到其他的线程。**

假设服务器的IO资源充足，物理线程的数量是20，请求在CPU密集阶段和IO密集阶段的比例平均是1：9，那么理想情况下可以设置线程数为、  
**线程池内线程数 = 物理线程数 \* （CPU密集阶段时间比例 + IO密集阶段时间比例） / CPU密集阶段时间比例**  
因此理想状况下可以定义线程池内线程数为 20 \* （1 + 9） / 1 = 200，当然这是理想情况下，服务器需要一定的CPU资源来维持服务器运转，所以实际线程数肯定小于200。线程数定义太多有什么问题？如果线程数太多，比如大于200，比如是400，那么同一时间能接受400条请求，但是CPU资源需要在400个线程间轮流切换，处理每个请求的时间只有原先的一半。如果CPU资源能每次处理完一个线程，那么有些线程获取到CPU资源的时间比原来长一倍，也就是有些请求的处理时间比原来的长了一倍；如果请求线程需要多次获取CPU资源才能处理完CPU密集阶段，那么CPU资源就需要更加频繁的在400个线程间切换，物理线程的上下文切换也是要消耗资源的，此时的CPU资源很多都消耗在了请求线程的切换上，而不是处理请求上了。

我们定义线程池数量的时候一定要留有余地，因为线程池时定义在服务器容器内，比如是Servlet容器。但是很多时候项目内的容器也需要线程的，比如Spring容器内定义线程池以实现线程复用。因此Servlet内线程池的线程数量还要更少些。

假设我们定义好了线程池内线程的数量，将其定义为150个，那么当请求的处理时间很长时，使用异步请求有什么好处吗？

当线程池内线程数量为150个时，也就是说同一时间只能处理150个请求，如果处理请求的平均时间为0.05s，那么项目的并发量就是150\*（1/0.05）=3000，也就是说能在一秒内最多处理3000个请求。平均时间是0.05s，也就说说请求在0.05s内处理完，在0.05s内有了结果返回。如果超过0.05s会怎么样？如果一个请求的处理时间是3s，那么在这3s内，处理这个请求的线程是阻塞的，也就是说不会接受其他请求，CPU资源可能会释放，但是线程还是阻塞的。如果同一时间有50个用户访问需要3s处理时间的这个url，那么在3s内，有50个线程被占用了，线程池的容量只有原来的2/3,。如果是10s，或者30s呢？或者是150个用户访问需要30s时间处理的url，也就是说服务器在这30s内只能处理这150个用户的请求了，没有额外的线程来处理其他用户的请求，并发量基本为0。这是一种很糟糕的情况。

异步请求对于这种情况有什么处理方法吗？以SpringMVC为例，当一个Controller方法返回的是Callable,WebAsyncTask,DefrredResult等对象时，也就是说我们把请求的处理过程放进一个线程中，然后把这个线程或者线程的包装对象返回给Servlet容器，当Servlet容器监测到返回的是一个线程或者其包装对象时，会将用户的请求和返回的线程绑定在一起，此时Serlvet内定义的线程(线程池线程)就与用户请求分离了，就可以去处理其他有用户的请求。当Controller线程有了结果或者超时，将其相应的处理结果返回给用户。Controller返回的线程可以是实时生成的线程，也可以是项目容器如Spring容器内定义的线程(推荐Spring线程池)。

异步请求能够尽早的释放对线程池线程的绑定，而使用项目内定义的线程，不影响服务器处理其他用户的请求。对于那些需要长时间处理的请求，很多都是IO密集型的，也就说请求大部分处于IO等待阶段，而IO阻塞阶段是不消耗CPU资源的。异步请求使用的是项目内的线程池，项目内的线程池能比较灵活的定义配置，且可具有一定的弹性，当异步请求多时生成容器上线的线程，当异步请求少时，仅维持最低标准的线程。