异步请求

Spring MVC 与 Servlet 异步请求 处理 进行了广泛的集成

有关这与 Spring WebFlux 的区别概述，请参阅下面的 异步 Spring MVC 与 WebFlux 的比较 部分。

DeferredResult

一旦在 Servlet 容器中 启用 异步请求处理功能，控制器方法就可以使用 DeferredResult 包装任何支持的控制器方法返回值，如下面的示例所示

  • Java

  • Kotlin

@GetMapping("/quotes")
@ResponseBody
public DeferredResult<String> quotes() {
	DeferredResult<String> deferredResult = new DeferredResult<>();
	// Save the deferredResult somewhere..
	return deferredResult;
}

// From some other thread...
deferredResult.setResult(result);
@GetMapping("/quotes")
@ResponseBody
fun quotes(): DeferredResult<String> {
	val deferredResult = DeferredResult<String>()
	// Save the deferredResult somewhere..
	return deferredResult
}

// From some other thread...
deferredResult.setResult(result)

控制器可以异步地从不同的线程生成返回值——例如，响应外部事件（JMS 消息）、计划任务或其他事件。

Callable

控制器可以使用 java.util.concurrent.Callable 包装任何支持的返回值，如下面的示例所示

  • Java

  • Kotlin

@PostMapping
public Callable<String> processUpload(final MultipartFile file) {
	return () -> "someView";
}
@PostMapping
fun processUpload(file: MultipartFile) = Callable<String> {
	// ...
	"someView"
}

然后可以通过 配置的 AsyncTaskExecutor 运行给定任务来获取返回值。

处理

以下是 Servlet 异步请求处理的简要概述

  • 通过调用 request.startAsync() 可以将 ServletRequest 置于异步模式。这样做主要的效果是 Servlet（以及任何过滤器）可以退出，但响应保持打开状态以让处理稍后完成。

  • 调用request.startAsync()方法会返回AsyncContext，您可以使用它来进一步控制异步处理。例如，它提供了dispatch方法，该方法类似于Servlet API中的转发，不同之处在于它允许应用程序在Servlet容器线程上恢复请求处理。

  • ServletRequest提供对当前DispatcherType的访问，您可以使用它来区分处理初始请求、异步调度、转发和其他调度类型。

DeferredResult处理的工作原理如下

  • 控制器返回一个DeferredResult，并将其保存在某个内存队列或列表中，以便可以访问它。

  • Spring MVC调用request.startAsync()。

  • 同时，DispatcherServlet和所有配置的过滤器退出请求处理线程，但响应保持打开状态。

  • 应用程序从某个线程设置DeferredResult，Spring MVC 将请求调度回 Servlet 容器。

  • DispatcherServlet再次被调用，处理继续进行，使用异步产生的返回值。

Callable处理的工作原理如下

  • 控制器返回一个Callable。

  • Spring MVC 调用request.startAsync()并将Callable提交给AsyncTaskExecutor，以便在单独的线程中进行处理。

  • 同时，DispatcherServlet和所有过滤器退出 Servlet 容器线程，但响应保持打开状态。

  • 最终，Callable产生结果，Spring MVC 将请求调度回 Servlet 容器以完成处理。

  • DispatcherServlet再次被调用，处理继续进行，使用Callable异步产生的返回值。

有关更多背景和上下文信息，您还可以阅读博客文章，该文章介绍了 Spring MVC 3.2 中的异步请求处理支持。

异常处理

当您使用DeferredResult时，您可以选择使用异常调用setResult或setErrorResult。在这两种情况下，Spring MVC 都将请求调度回 Servlet 容器以完成处理。然后，它被视为控制器方法返回给定值或产生给定异常。然后，异常将经过常规的异常处理机制（例如，调用@ExceptionHandler方法）。

当您使用Callable时，会发生类似的处理逻辑，主要区别在于结果是从Callable返回的，或者由它引发异常。

拦截

HandlerInterceptor实例可以是AsyncHandlerInterceptor类型，以便在启动异步处理的初始请求上接收afterConcurrentHandlingStarted回调（而不是postHandle和afterCompletion）。

HandlerInterceptor实现还可以注册CallableProcessingInterceptor或DeferredResultProcessingInterceptor，以更深入地集成到异步请求的生命周期中（例如，处理超时事件）。有关更多详细信息，请参阅AsyncHandlerInterceptor。

DeferredResult提供onTimeout(Runnable)和onCompletion(Runnable)回调。有关更多详细信息，请参阅DeferredResult的javadoc。Callable可以替换为WebAsyncTask，它公开了用于超时和完成回调的额外方法。

异步 Spring MVC 与 WebFlux 的比较

Servlet API 最初是为通过 Filter-Servlet 链进行单次传递而构建的。异步请求处理允许应用程序退出 Filter-Servlet 链，但保持响应打开以供进一步处理。Spring MVC 异步支持是围绕该机制构建的。当控制器返回DeferredResult时，Filter-Servlet 链将退出，并且 Servlet 容器线程将被释放。稍后，当设置DeferredResult时，将进行ASYNC调度（到同一个 URL），在此期间，控制器将再次被映射，但不会调用它，而是使用DeferredResult值（就像控制器返回它一样）来恢复处理。

相比之下，Spring WebFlux 既不是基于 Servlet API 构建的，也不需要这种异步请求处理功能，因为它在设计上就是异步的。异步处理内置于所有框架契约中，并在请求处理的所有阶段得到内在支持。

从编程模型的角度来看，Spring MVC 和 Spring WebFlux 都支持异步和响应式类型作为控制器方法中的返回值。Spring MVC 甚至支持流，包括响应式背压。但是，与 WebFlux 不同的是，对响应的单个写入仍然是阻塞的（并在单独的线程上执行），WebFlux 依赖于非阻塞 I/O，并且不需要为每次写入使用额外的线程。

另一个基本区别是，Spring MVC 不支持控制器方法参数中的异步或反应式类型（例如，@RequestBody、@RequestPart 等），也不对异步和反应式类型作为模型属性提供任何显式支持。Spring WebFlux 支持所有这些。

最后，从配置的角度来看，异步请求处理功能必须在 Servlet 容器级别启用。

HTTP 流

参见 Reactive 堆栈中的等效项

您可以使用 DeferredResult 和 Callable 来获得单个异步返回值。如果您想生成多个异步值并将它们写入响应，该怎么办？本节介绍如何做到这一点。

对象

您可以使用 ResponseBodyEmitter 返回值来生成对象流，其中每个对象都使用HttpMessageConverter 序列化并写入响应，如下例所示

  • Java

  • Kotlin

@GetMapping("/events")
public ResponseBodyEmitter handle() {
	ResponseBodyEmitter emitter = new ResponseBodyEmitter();
	// Save the emitter somewhere..
	return emitter;
}

// In some other thread
emitter.send("Hello once");

// and again later on
emitter.send("Hello again");

// and done at some point
emitter.complete();
@GetMapping("/events")
fun handle() = ResponseBodyEmitter().apply {
	// Save the emitter somewhere..
}

// In some other thread
emitter.send("Hello once")

// and again later on
emitter.send("Hello again")

// and done at some point
emitter.complete()

您也可以在 ResponseEntity 中使用 ResponseBodyEmitter 作为主体，让您自定义响应的状态和标头。

当 emitter 抛出 IOException（例如，如果远程客户端断开连接）时，应用程序不负责清理连接，也不应调用 emitter.complete 或 emitter.completeWithError。相反，Servlet 容器会自动启动 AsyncListener 错误通知，其中 Spring MVC 会进行 completeWithError 调用。此调用反过来会执行一次最终的 ASYNC 分派到应用程序，在此期间 Spring MVC 会调用配置的异常解析器并完成请求。

SSE

SseEmitter（ResponseBodyEmitter 的子类）提供对服务器发送事件的支持，其中从服务器发送的事件根据 W3C SSE 规范进行格式化。要从控制器生成 SSE 流，请返回 SseEmitter，如下例所示

  • Java

  • Kotlin

@GetMapping(path="/events", produces=MediaType.TEXT_EVENT_STREAM_VALUE)
public SseEmitter handle() {
	SseEmitter emitter = new SseEmitter();
	// Save the emitter somewhere..
	return emitter;
}

// In some other thread
emitter.send("Hello once");

// and again later on
emitter.send("Hello again");

// and done at some point
emitter.complete();
@GetMapping("/events", produces = [MediaType.TEXT_EVENT_STREAM_VALUE])
fun handle() = SseEmitter().apply {
	// Save the emitter somewhere..
}

// In some other thread
emitter.send("Hello once")

// and again later on
emitter.send("Hello again")

// and done at some point
emitter.complete()

虽然 SSE 是流式传输到浏览器的主要选项，但请注意，Internet Explorer 不支持服务器发送事件。请考虑使用 Spring 的WebSocket 消息传递，以及SockJS 回退 传输（包括 SSE），这些传输针对各种浏览器。

另请参见上一节，了解有关异常处理的说明。

原始数据

有时，绕过消息转换并直接流式传输到响应 OutputStream（例如，用于文件下载）会很有用。您可以使用 StreamingResponseBody 返回值类型来执行此操作，如下例所示

  • Java

  • Kotlin

@GetMapping("/download")
public StreamingResponseBody handle() {
	return new StreamingResponseBody() {
		@Override
		public void writeTo(OutputStream outputStream) throws IOException {
			// write...
		}
	};
}
@GetMapping("/download")
fun handle() = StreamingResponseBody {
	// write...
}

您可以使用StreamingResponseBody作为ResponseEntity中的主体来自定义响应的状态和标头。

响应式类型

参见 Reactive 堆栈中的等效项

Spring MVC 支持在控制器中使用响应式客户端库（另请参阅 WebFlux 部分中的响应式库）。这包括来自spring-webflux的WebClient和其他库，例如 Spring Data 响应式数据存储库。在这种情况下，能够从控制器方法返回响应式类型非常方便。

响应式返回值的处理方式如下

  • 单值承诺被适配为，类似于使用DeferredResult。示例包括Mono（Reactor）或Single（RxJava）。

  • 具有流媒体媒体类型（例如application/x-ndjson或text/event-stream）的多值流被适配为，类似于使用ResponseBodyEmitter或SseEmitter。示例包括Flux（Reactor）或Observable（RxJava）。应用程序还可以返回Flux<ServerSentEvent>或Observable<ServerSentEvent>。

  • 具有任何其他媒体类型（例如application/json）的多值流被适配为，类似于使用DeferredResult<List<?>>。

Spring MVC 通过来自spring-core的ReactiveAdapterRegistry支持 Reactor 和 RxJava，它允许它从多个响应式库进行适配。

对于流式传输到响应，支持响应式背压，但对响应的写入仍然是阻塞的，并且通过配置的AsyncTaskExecutor在单独的线程上运行，以避免阻塞来自WebClient返回的Flux等上游源。

上下文传播

使用java.lang.ThreadLocal传播上下文很常见。这对于在同一线程上处理是透明的，但对于跨多个线程的异步处理需要额外的工作。Micrometer 上下文传播 库简化了跨线程的上下文传播，以及跨上下文机制的传播，例如ThreadLocal 值、Reactor 上下文、GraphQL Java 上下文 等。

如果 Micrometer 上下文传播存在于类路径中，当控制器方法返回 响应式类型（例如Flux 或Mono）时，所有ThreadLocal 值（对于这些值，有一个已注册的io.micrometer.ThreadLocalAccessor）将被写入 Reactor Context 作为键值对，使用ThreadLocalAccessor 分配的键。

对于其他异步处理场景，您可以直接使用上下文传播库。例如

Java
// Capture ThreadLocal values from the main thread ...
ContextSnapshot snapshot = ContextSnapshot.captureAll();

// On a different thread: restore ThreadLocal values
try (ContextSnapshot.Scope scope = snapshot.setThreadLocals()) {
	// ...
}

有关更多详细信息，请参阅 Micrometer 上下文传播库的 文档。

断开连接

参见 Reactive 堆栈中的等效项

Servlet API 不会在远程客户端断开连接时提供任何通知。因此，在通过 SseEmitter 或 响应式类型 流式传输到响应时，重要的是定期发送数据，因为如果客户端已断开连接，写入将失败。发送可以采用空（仅注释）SSE 事件或任何其他数据形式，另一方必须将其解释为心跳并忽略。

或者，考虑使用具有内置心跳机制的 Web 消息传递解决方案（例如 STOMP over WebSocket 或带有 SockJS 的 WebSocket）。

配置

异步请求处理功能必须在 Servlet 容器级别启用。MVC 配置还公开了用于异步请求的几个选项。

Servlet 容器

过滤器和 Servlet 声明有一个asyncSupported 标志，需要将其设置为true 以启用异步请求处理。此外，应声明过滤器映射以处理ASYNC jakarta.servlet.DispatchType。

在 Java 配置中，当您使用AbstractAnnotationConfigDispatcherServletInitializer 初始化 Servlet 容器时，这将自动完成。

在web.xml 配置中，您可以将<async-supported>true</async-supported> 添加到DispatcherServlet 和Filter 声明中，并将<dispatcher>ASYNC</dispatcher> 添加到过滤器映射中。

Spring MVC

MVC 配置公开了以下用于异步请求处理的选项

  • Java 配置：在WebMvcConfigurer 上使用configureAsyncSupport 回调。

  • XML 命名空间：在<mvc:annotation-driven> 下使用<async-support> 元素。

您可以配置以下内容

  • 异步请求的默认超时值取决于底层 Servlet 容器，除非显式设置。

  • AsyncTaskExecutor 用于在使用 响应式类型 进行流式传输时阻塞写入，以及用于执行从控制器方法返回的 Callable 实例。默认使用的那个不适合在负载下生产环境使用。

  • DeferredResultProcessingInterceptor 实现和 CallableProcessingInterceptor 实现。

请注意，您也可以在 DeferredResult、ResponseBodyEmitter 和 SseEmitter 上设置默认超时值。对于 Callable，您可以使用 WebAsyncTask 来提供超时值。