当前位置：网站首页>异步Servlet在转转图片服务的实践

异步Servlet在转转图片服务的实践

2022-07-25 09:41:00 【InfoQ】

一、问题背景

为了提供公司内部统一的图片上传平台，去年架构部开发并上线了一个SpringBoot的web服务，客户端可以通过Http上传图片，web服务端对图片进行内部处理（如裁剪、加水印等）后最终将图片放入远端存储。前段时间，突然收到监控系统的报警信息，同时业务反馈有

大量的上传图片请求超时

。针对这个问题，开始进行了排查优化。

二、排查问题

首先看JVM的状态，可以发现两个关键的异常指标。其中一个是FullGC次数。从公司内部的监控系统可以看出在

18:20

这个时间点某台机器的

FullGC次数开始暴增

。

众所周知，FullGC的原因是JVM在堆中的对象总和大于JVM堆的总内存，需要进行FullGC对非存活的对象进行回收。而当FullGC频繁时，一般有两个原因：

有大对象直接进入老年代

对象不断在创建并且一直存活，即内存泄漏

仅从已有的信息尚不能确定FullGC的主要原因，所以需要继续寻找其他的异常点。

第二个异常是Runnable线程的数量。同样地从

18:20

开始

Runnable线程不断增加，并且波动的趋势和FullGC次数的趋势几乎一模一样

。

这时候基本可以锁定FullGC频繁的原因是大量的Runnable线程所携带的对象不能被回收。那么下一个问题是，为什么会突然有这么多Runnable线程?登录其中一台服务器，使用

jps

命令获取当前进程id，接着

jstack

命令带上该进程id可以查看各个线程当前的堆栈信息。

找到其中一个Runnable线程可以看到堆栈停在了

socketRead0()

方法，再往下看，可以看到是

PictureUploadServiceImpl

的

getInputSreamFromUrl()

方法，该方法的逻辑是下载业务方提供的第三方图片URL。所以出现大量的Runnable线程说明某个业务方提供的

第三方图片URL下载异常

！

即因为

图片URL下载超时

当前线程阻塞

不断创建Tomcat线程（且下载图片）

FUllGC频繁

！

三、解决方案

3.1 初步方案

知道了问题产生的原因后，通过排查服务端的配置，可以发现两个参数设置得不合理：

Tomcat最大线程数设置了1000

从刚才的图看出，线程数到200左右就开始FullGC，最大线程数1000只会加剧FullGC，所以最大线程数应该减少，可以参考Tomcat默认的最大线程数，即为200。

下载URL的超时时间设置了5000ms

过大的超时时间会使线程一直处于Runnable状态，减少超时时间可以让线程快速完成任务，避免线程一直创建。

在调整完这两个参数后，FullGC频繁的问题是解决了，但是因为限制了Tomcat最大线程数，又会带来新的问题。

3.2 新的问题

如下图所示，该服务的Tomcat线程池主要接收了两类请求供客户端上传图片

其中A类请求是接收客户端上传的

MultipartFile

对象，而B类请求是接收客户端上传的URL。

对于A类请求，服务端接收的是二进制流，Tomcat线程可以直接把流上传到存储终端，而对于B类请求，服务端接收的是图片URL，Tomcat线程需要对URL先进行下载，再上传到存储终端。

所以

当图片URL的服务器出现异常时，Tomcat线程在下载图片会被阻塞，导致Tomcat线程不能被释放，在流量大的情况下，整个Tomcat线程池都是正在处理B类请求的阻塞线程，当Tomcat的阻塞队列被打满后，服务端将不能接收任何请求

！

而在公司的业务场景中，A类请求的比例远远大于B类请求，这种情况是绝对不能接受的。为了保证重要业务的正常运行，需要增加另外的线程池进行

线程隔离

。

将B类请求的实际处理交给新增的业务线程池去执行，只需对业务线程池设置合理参数（容量，阻塞队列和拒绝策略等），就能够保证B类请求不会对Tomcat线程池造成任何影响，从而保证A类请求的正常处理。

加入线程池就能够完美地解决问题吗？仔细想一下，客户端上传了一张图片，原本在Tomcat中处理后返回了上传地址，而现在改成另一个线程池中处理，

处理后的结果应该怎么返回给客户端

呢。

有读者可能会认为可以使用以下方式提交获取返回值

<T> Future<T> submit(Callable<T> task);

但是一旦使用了

future.get()

就会对Tomcat现在造成阻塞，又会遇到最开始的问题。所以用

submit()

提交属于本末倒置了。那么到底该怎么解决，

既能实现线程隔离，又能同步返回处理后的结果给客户端

？经过调研，我们最终使用了异步Servlet技术解决这个问题。

3.3 异步Servlet

异步Servlet是Servlet3.0规范中一个新特性，支持Servlet在处理过程中可以开启异步模式，然后在相应的业务线程里面进行一些业务操作，完成业务操作之后才对请求返回响应。

3.3.1 Servlet3.0规范

异步Servlet的示例如下：

@WebServlet(URLPatterns = &quot;/async&quot;,asyncSupported = true)
public class AsyncServlet extends HttpServlet {

 ExecutorService executorService =Executors.newSingleThreadExecutor();

 @Override
 protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
 //1. 开启异步,获取异步上下文
 final AsyncContext ctx = req.startAsync();
 //2. 提交线程池异步执行
 executorService.execute(new Runnable() {


 @Override
 public void run() {
 try {
 //3.模拟任务并输出
 Thread.sleep(10000L);
 ServletResponse response = ctx.getResponse();
 outputStream = response.getOutputStream();
 outputStream.write(&quot;task complete&quot;.getBytes(StandardCharsets.UTF_8));
 outputStream.flush();
 } catch (IOException e) {
 e.printStackTrace();
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 //4. 执行完成后完成回调
 ctx.complete();
 }
 });
 }
}

Servlet规范只是一个标准，在不同的web容器中有不同的实现。由于我们平时使用基本都是Tomcat容器，所以下面介绍下Tomcat的实现。

3.3.2 Tomcat实现

从上面的demo看出，除了

req.startAsync()

和

ctx.complete()

这两行代码，其他的步骤和我们平时使用线程池异步处理没有什么区别。那么这两行有什么作用呢？为了避免本文篇幅过长，这里对具体的源码实现进行概括:

req.startAsync()

主要干了两件事：

设置当前请求为一个异步类型的请求

把当前的请求的request和response保存在一个上下文对象中

当Tomcat线程的任务结束之前会判断当前的请求是否为异步类型，如果是异步类型，不会对当前的request和response进行finish操作。这就是为什么Tomcat线程能够释放并且保持服务端和客户端连接仍然打开的原因！

ctx.complete()

的作用则是使用另外一个Tomcat线程对之前保存的response进行finish操作，对请求进行了返回。

Tomcat的异步servlet的实现原理就是这么简单，想知道更多的细节可以自行阅读和调试源码。

但是Tomcat只实现了

ctx.complete()

这个api对response进行返回，如果需要对response进行其他操作，比如把异步上传后的图片地址进行返回，需要在调用

ctx.complete()

之前进行设置。

3.3.3 Spring MVC实现

为了使用更便捷，SpringMVC 3.2版本对Tomcat的异步servlet实现进行了进一步的封装和拓展，以下是

官方文档提供的demo

：

@RequestMapping(&quot;/quotes&quot;)
@ResponseBody
public DeferredResult<String> quotes() {
 DeferredResult<String> deferredResult = new DeferredResult<String>();
 // Save the deferredResult somewhere..
 return deferredResult;
}
// In some other thread...
deferredResult.setResult(data);

Spring MVC自己封装了

DeferredResult

类，让开发者使用起来更加简单，只需要在controller的方法把需要返回的对象类型包装在

DeferredResult

里面，然后进行return就可以。Spring MVC的核心处理类

DispatchServlet

会对

DeferredResult

类型的返回值进行特殊处理，其流程和Tomcat的实现大同小异，都是对当前请求的request和response进行保存并保持response打开。当其他线程调用

deferredResult.setResult(data)

之后会将异步处理的结果返回给客户端。

3.4 最终方案

到目前为止，我们已经可以针对一开始出现的问题给出完善的解决方案。

针对减少FullGC:

调整Tomcat线程数200

调整下载图片超时时间2000ms

针对线程隔离：

使用线程池 + DeferredResult 进行异步处理和同步返回

最终应用到项目的controller代码为：

@RestController
public class PictureUploadController {
 private ExecutorService threadPool = new ThreadPoolExecutor(16, 16, 30, TimeUnit.SECONDS,
 new LinkedBlockingQueue<>(5000), new ThreadFactory() {
 private final AtomicInteger uploadUrlPicThreadNum = new AtomicInteger(1);

 @Override
 public Thread newThread(Runnable runnable) {
 Thread thread = Executors.defaultThreadFactory().newThread(runnable);
 thread.setName(&quot;uploadUrlPicThread-&quot; + uploadUrlPicThreadNum.getAndIncrement());
 return thread;
 }
 }, new ThreadPoolExecutor.DiscardOldestPolicy());

 @Autowired
PictureUploadService pictureUploadService;

 @PostMapping(&quot;/asyncUpload&quot;)
 public DeferredResult<ApiResult> asyncUploadPicture(@Valid PictureUploadDTO pictureUploadDTO) { 
 //1. 构建DeferredResult对象，设置超时时间
 DeferredResult<ApiResult> deferredResult = new DeferredResult<>(5000);
 threadPool.execute(new Runnable() {
 @Override
 public void run() {
 //2.异步上传图片
 apiResult = pictureUploadService.upload(pictureUploadDTO);
 //3.设置返回值
 deferredResult.setResult(apiResult);
 }
 });
 return deferredResult;
 }
}