SpringBoot four asynchronous processing, writing this article, I learned first myself

Let’s start with a graph to see the difference between asynchronous and synchronous requests:

In the figure above, there are three roles: client, Web container, and business process thread.

Client requests to the Web container in both processes are synchronous. Because they are all in a blocking wait state when requesting the client, they are not processed asynchronously.

In the Web container section, the first process takes the form of a synchronous request and the second takes the form of an asynchronous callback.

Through asynchronous processing, threads and related resources allocated to requests by the container can be released first, reducing the burden on the system, thereby increasing the throughput of the server to the client requests. However, when the number of concurrent requests is large, the solution is usually load balancing rather than asynchronous.

Let’s look directly at an example of an asynchronous servlet-based request:

@GetMapping(value = "/email/send") public void servletReq(HttpServletRequest request) { AsyncContext asyncContext = request.startAsync(); Asynccontext.addlistener (new AsyncListener() {@override public void addListener() OnTimeout (AsyncEvent event) {system.out.println (" Processing timed out... ); } @override public void onStartAsync(AsyncEvent event) {system.out.println (" thread starts executing "); } @override public void onError(AsyncEvent event) {system.out.println (); " + event.getThrowable().getMessage()); } @override public void onComplete(AsyncEvent event) {system.out.println (" execute, free resource "); }}); // setTimeout asynccontext. setTimeout(6000); asyncContext.start(new Runnable() { @Override public void run() { try { Thread.sleep(5000); System.out.println(" internal Thread: "+ thread.currentThread ().getName()); asyncContext.getResponse().getWriter().println("async processing"); } catch (Exception e) {system.out.println (" error: "+ LLDB message ()); } // asyncContext.complete(); }}); System.out.println(" Thread: "+ thread.currentThread ().getName())); }Copy the code

Start the project, access the corresponding URL, and print the following log:

Main thread: HTTP-nio-8080-exec-4 Internal thread: http-nio-8080-exec-5 When the execution is complete, resources are releasedCopy the code

As you can see, the above code completes the main thread first, which is the log printing of the last line of the program, and then the execution of the internal thread. The inner thread completes execution and AsyncContext’s onComplete method is called.

If you access the URL through a browser, you can also see the return value of async Processing. The result from the internal thread is also returned to the client normally.

For a request (/email), the Callable processing flow is as follows:

1. Spring MVC enables sub-threads to handle business (submitting Callable to TaskExecutor);

2. DispatcherServlet and all filters exit the Web container thread, but Response remains open;

Callable returns the result, SpringMVC sends the original request back to the container (request again /email), resuming the previous processing;

4. DispatcherServlet is called again and the result is returned to the user;

Examples of code implementation are as follows:

@getMapping ("/email") public Callable<String> order() {system.out.println (" mainline start: " + Thread.currentThread().getName()); Callable<String> result = () -> {system.out.println (" thread.currentThread ().getName() "); Thread.sleep(1000); System.out.println(" + thread.currentThread ().getName()); return "success"; }; System.out.println(" thread.currentThread ().getName()); return result; }Copy the code

To access the corresponding URL, the console enters the log as follows:

Main thread start: HTTP-nio-8080-exec-1 Main thread Return: HTTP-nio-8080-exec-1 secondary thread Start: task-1 Secondary thread return: task-1Copy the code

As you can see from the log, the main thread completes before the secondary thread executes. At the same time, the URL returns the result “Success”. This also illustrates the problem that asynchronous processing on the server side is invisible to the client.

Callable is executed by default using the SimpleAsyncTaskExecutor class, which is very simple and does not reuse threads. In practice, the AsyncTaskExecutor class is used to configure threads.

The thread pool is configured by implementing the WebMvcConfigurer interface.

@Configuration public class WebConfig implements WebMvcConfigurer { @Resource private ThreadPoolTaskExecutor myThreadPoolTaskExecutor; / * * * * / configuration thread pool @ Bean (name = "asyncPoolTaskExecutor") public ThreadPoolTaskExecutor getAsyncThreadPoolTaskExecutor () { ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor(); taskExecutor.setCorePoolSize(2); taskExecutor.setMaxPoolSize(10); taskExecutor.setQueueCapacity(25); taskExecutor.setKeepAliveSeconds(200); taskExecutor.setThreadNamePrefix("thread-pool-"); AbortPolicy and CallerRunsPolicy are supported in the thread pool. . The default is the latter taskExecutor setRejectedExecutionHandler (new ThreadPoolExecutor CallerRunsPolicy ()); taskExecutor.initialize(); return taskExecutor; } @override public void configureAsyncSupport(Final AsyncSupportConfigurer configurer) {// Process callable timeout configurer.setDefaultTimeout(60 * 1000); configurer.setTaskExecutor(myThreadPoolTaskExecutor); configurer.registerCallableInterceptors(timeoutCallableProcessingInterceptor()); } @Bean public TimeoutCallableProcessingInterceptor timeoutCallableProcessingInterceptor() { return new TimeoutCallableProcessingInterceptor(); }}Copy the code

To verify the printed thread, we replace the system.out.println in the example code with log output, and see that the log is printed as follows before using the thread pool:

The 2021-02-21 09:45:37. 8312-144 the INFO [nio - 8080 - exec - 1] C.S.L earn. Controller. AsynController: Main thread start: HTTP - nio - 8080-2021-02-21 09:45:37 exec - 1, 8312-144 the INFO [nio - 8080 - exec - 1] C.S.L earn. Controller. AsynController: Main thread returns: HTTP - nio - 8080-2021-02-21 09:45:37 exec - 1, 8312-148 the INFO] [task - 1 C.S.L earn. Controller. AsynController: Vice thread begins: the 2021-02-21 09:45:38 task - 1. 8312-153 the INFO] [task - 1 C.S.L earn. Controller. AsynController: vice thread returns: task 1Copy the code

The thread name is task-1. After the thread pool is enabled, the following log is printed:

The 2021-02-21 09:50:28. 8339-950 the INFO [nio - 8080 - exec - 1] C.S.L earn. Controller. AsynController: Main thread start: HTTP - nio - 8080-2021-02-21 09:50:28 exec - 1, 8339-951 the INFO [nio - 8080 - exec - 1] C.S.L earn. Controller. AsynController: The main thread to return: HTTP - nio - 8080-2021-02-21 09:50:28 exec - 1. 8339-955 the INFO [thread pool - 1] C.S.L earn. Controller. AsynController: Vice thread begins: thread pool - 1 09:50:29 2021-02-21. 8339-956 the INFO [thread pool - 1] C.S.L earn. Controller. AsynController: The secondary thread returns thread-pool-1Copy the code

The thread name is thread-pool-1, where the thread pool prefix is specified.

In addition to the thread pool configuration, you can also configure unified exception handling, which is not demonstrated here.

DeferredResult is used in a similar way to Callable, but not in the same way as A DeferredResult. The actual result of DeferredResult may not have been generated when it is returned. The actual result of DeferredResult may have been set in another thread.

This feature of DeferredResult is important for advanced applications such as server-side pushing, order expiration handling, long polling, and the ability to emulate MQ.

In DeferredResult, let’s take a look at the official examples and instructions:

@RequestMapping("/quotes")
@ResponseBody
public DeferredResult<String> quotes() {
  DeferredResult<String> deferredResult = new DeferredResult<String>();
  // Save the deferredResult in in-memory queue ...
  return deferredResult;
}

// In some other thread...
deferredResult.setResult(data);
Copy the code

As you can see from the example above, the call to DeferredResult doesn’t have to be in Spring MVC, it could be another thread. So does the official explanation:

In this case the return value will also be produced from a separate thread. However, that thread is not known to Spring MVC. For example the result may be produced in response to some external event such as a JMS message, a scheduled task, etc.

That is, DeferredResult can also return results triggered by MQ, scheduled tasks, or other threads. Here’s an example:

@Controller @RequestMapping("/async/controller") public class AsyncHelloController { private List<DeferredResult<String>> deferredResultList = new ArrayList<>(); @ResponseBody @GetMapping("/hello") public DeferredResult<String> helloGet() throws Exception { DeferredResult<String> deferredResult = new DeferredResult<>(); Add (deferredResult); return deferredResult; } @responseBody@getMapping ("/setHelloToAll") public void helloSet() throws Exception {// Let all held requests respond deferredResultList.forEach(d -> d.setResult("say hello to all")); }}Copy the code

The first request, / Hello, will store deferredResult, and the front end of the page will wait. All relevant pages will not respond until the second request, setHelloToAll, is sent.

The entire execution process is as follows:

• The controller returns a DeferredResult and stores it in memory or in a List (for subsequent access);
• Spring MVC calls Request.startAsync () to enable asynchronous processing; At the same time, the interceptor, Filter and so on in DispatcherServlet will immediately exit the main thread, but the state of Response remains open;
• The application gives the DeferredResult#setResult value through another thread (possibly MQ messages, scheduled tasks, and so on). SpringMVC then sends the request to the servlet container again;
• The DispatcherServlet is invoked again and then processes the subsequent standard flow;

It can be found through the above process: DeferredResult can be used to implement long connections. For example, when an operation is asynchronous, you can save the corresponding DeferredResult object, and when the asynchronous notification comes back, you can find the DeferredResult object and process the result in setResult. Thus improving performance.

Different packages:

• @ Async: org. Springframework. Scheduling. The annotation;
• WebAsyncTask: org. Springframework. Web. Context. Request. Async;
• Callable: Java. Util. Concurrent;
• DeferredResult: org. Springframework. Web. Context. Request. Async;

We should feel a little bit different from the package we are in, for example @Async is in the Scheduling package, while WebAsyncTask and DeferredResult are for the Web (Spring MVC), Callable is used for concurrent processing.

For Callable, this is usually used for asynchronous requests with the Controller method, but it can also be used as a Runable replacement. Differs from normal methods in the way they return:

Public String aMethod(){} public String <String> aMethod(){}Copy the code

WebAsyncTask is a wrapper around Callable that provides some handling of event callbacks, not much different in nature.

DeferredResult is used in a similar way to Callable, with an emphasis on communication across threads.

@async is also a way to replace Runable instead of creating our own thread. And it applies more broadly, not just to the Controller layer, but to any layer’s methods.

Of course, you can also analyze it in terms of return results, exception handling and so on, but I won’t go into that here.