Synchronous or asynchronous? Webflux development really faster than servlet development? By the way, completablefuture

Before looking at the following, first give you a basic knowledge of science

Runable: Thread task class interface, no return value

Callable: The difference from the above is that there is a return value

Executor: Defines the interface for thread pool execution tasks, but only runable is defined, that is, execute

Executorservice: Is the thread pool specification, like Threadpoolexecutor is its implementation class, inherits executor, and also expands the execution specification for callable task class, that is, submit ()

Executors: A tool class that provides some thread pools with a default configuration, such as new fixedthreadpool (int num), in fact except Newworkstealingpool (using Forkjoinpool) Outside the threadpoolexecutor, including the Scheduledthreadpoolexecutor, timer thread pool, just the queue is using
Delayedworkqueue This delay to block the queue.

Future:java interface for future mode implementation
Implementation class for the Futuretask:future interface

First of all, please think of a question, what is asynchronous and synchronous? What's the difference? See here, it's about asynchronous and synchronous, not blocking versus non-blocking (the difference between blocking and non-blocking is the notion that a thread is blocked, that is, a block of code (such as IO) You are turning on a sub-thread to run it so that the main thread goes directly or lets the main thread go blocking it).

The concept of synchronous and asynchronous is very vague compared to the definition of blocking and non-blocking, and the concepts of synchronization and asynchrony are blurred, as I have just contacted NiO and AIO because of the misleading nature of the various blogs on the web and the fact that I have not taken the time to think about them (independent thinking is important, not just passive acceptance), The concept that led to a once understood as synchronous and asynchronous is the operating system level, that is, the trigger of the task is whether the system actively notifies you (callback), or if you keep polling in the program to see if the trigger condition is reached.

In fact, this is only a superficial phenomenon, we think, the program active access and system to inform you, the two real difference is what? In fact, it is the need for us to keep polling, non-stop people looking at. And the other is through the callback function, which is triggered by the event of the completion of the task, There is no need for us to observe. This is the difference between synchronous and asynchronous, and synchronization at a certain point still requires active access to our task thread. And asynchronously, the task thread itself tells us that we are done. That is, the real difference is that there is no callback function after completing the task!

To understand this, let's say to Completablefuture, first of all, this class is the first real asynchronous programming implementation of Java, Futuretask is synchronous, the reason is very simple, you need to take the initiative to get the return value of Futuretask (Get () method), And that's what we're going to do. Synchronization is the need for our program to proactively access our task threads.

Completablefuture does not require our active acquisition, the reason is very simple, completablefuture is event-driven data processing. That is, completablefuture can register listeners, This will trigger the callback automatically once our data processing is complete.

Here is a small demo

Analyze from the printed information

1. In the case where we do not specify a thread pool, Completablefuture uses Forkjoinpool by default, and Forkjoinpoll thread is the daemon thread, which is why I join at the end. (The life cycle of the daemon is dependent on the foreground thread, that is, my main thread runs out of the JVM and exits without a daemon thread executing.)

2. Although asynchronous is specified in each invocation of the chain, the entire method chain is still using the same thread, because these calls have dependencies, so I always feel that the completetablefuture chain call is very chicken. But, although the operation of the method in chained calls is serial, But for the thread that calls it outside, it's still asynchronous (see above for the definition of async)

The above reason is said Completablefuture concept, is because completablefuture is actually a typical response style programming style, for us to say the Webflux to do a cushion, so we say Webflux the biggest misunderstanding, That is, responsive programming is more efficient, better performance, and shorter response time than servlets

As you know, SPRING5 has introduced a Webflux development framework (using the default server made by Netty and not using the servlet specification), using mono (correspondence singleton) and Webflux (corresponding to multiple cases)

Let's look at the following example

First note that mono is the implementation provided by Netty rather than spring, and then ask you to think about a process, what happens when I visit this code?

Spring will go to start a thread to process the Mono method call chain, then return immediately, see Clearly, is started, not necessarily start running, may just be ready to return the state (here is a basic knowledge of the course life cycle, when you start a thread, this thread will not run immediately, It also needs to wait for the CPU's time slice)

But it's going to return right here. The thread that handles the request requests is returned immediately, and the response thread does not respond to the client immediately, because the mono thread also needs to process the data, and when the mono thread processes the data, it is response monitored by the event. At this point response gets the data back (this can be understood as Mono's push to response after processing the data)

OK, everyone here should understand, Webflux framework in our program seems to be asynchronous, but the client response appears to be synchronous (because I still need you to return to my data I can respond to the client, from a point of view for the client's immediate response to such things, unless it is some background tasks, That is unrelated to the content of the task, otherwise there is no way to do asynchronous),

As a result, in the case of Webflux and the traditional servlet development can use multithreading, the Webflux framework is no faster than the previous request and response synchronous processing point, and may even be slower, because in the case of a large number of threads opened, Thread context switching is a significant overhead. You know, Webflux development is always more than a traditional development to open a thread

And the funniest thing is that this approach to the Spring Webflux framework is the same as the servlet 3 (Asynchronous Processing task, request instant return). So the Webflux framework is more efficient than the servlet and the response is much faster.

So the conclusion is that the Webflux framework is really just a programming style framework, just like the java8 provided by the functional programming framework stream, which can only be reduced without any performance improvement, and the WEBFLUX framework can be implemented in the same way as in other ways.

Synchronous or asynchronous? Webflux development really faster than servlet development? By the way, completablefuture