Solución:
El modelo asíncrono de Servlet introduce un límite asíncrono entre los subprocesos del contenedor (1 solicitud de Servlet / modelo de subproceso) y el procesamiento de la solicitud en su aplicación. El procesamiento puede ocurrir en un hilo diferente o esperar. Al final, debe enviar de nuevo a un hilo contenedor y leer / escribir de forma bloqueada (InputStream y OutputStream son intrínsecamente bloqueando las API).
Con ese modelo, necesita muchos subprocesos para lograr la simultaneidad (porque muchos de ellos se pueden bloquear en espera de E / S). Esto cuesta recursos y puede ser una compensación, según su caso de uso.
Con el código sin bloqueo, solo necesita unos pocos subprocesos para procesar muchas solicitudes al mismo tiempo. Este es un modelo de concurrencia diferente; como cualquier modelo, conlleva beneficios y compensaciones.
Para obtener más información sobre esa comparación, esta charla de Servlet frente a pilas reactivas debería ser de interés.
La API de servlet está bloqueando la E / S, lo que requiere 1 subproceso por solicitud HTTP. Spring MVC async se basa en las API de Servlet que solo proporcionan un comportamiento asíncrono entre los subprocesos del contenedor y los subprocesos de procesamiento de solicitudes, pero no de un extremo a otro.
Spring WebFlux, por otro lado, logra la concurrencia mediante un número fijo de subprocesos mediante el uso de sockets HTTP y empujando fragmentos de datos a la vez a través de los sockets. Este mecanismo se llama bucle de eventos, una idea popularizada por Node.js. Este enfoque es escalable y resistente. Spring-webflux de Spring 5 usa el bucle de eventos enfoque para proporcionar comportamiento asincrónico.
Se puede leer más de
- Servlet frente a reactivo
- Batalla de rendimiento de Spring Boot
- Comparación de WebFlux con Spring Web MVC