¿Estoy en lo cierto al decir que para las aplicaciones web el contenedor web se encarga de subprocesos múltiples?
La mayoría de los servidores web (Java y otros, incluido JBoss) siguen un modelo de "un subproceso por solicitud", es decir, cada solicitud HTTP es procesada completamente por exactamente un subproceso. Este hilo a menudo pasará la mayor parte del tiempo esperando cosas como solicitudes de DB. El contenedor web creará nuevos hilos según sea necesario.
Algunos servidores (en el ecosistema de Java principalmente Netty ) realizan el manejo de solicitudes asíncronas, ya sea con un modelo de "un subproceso hace todo" o algo más complejo. La idea básica es que tener muchos hilos en espera desperdicia recursos, por lo que trabajar de forma asincrónica puede ser más eficiente.
Si es así, ¿puedo introducir nuevos pasos en aplicaciones basadas en web?
Es posible, pero debe hacerse con mucho cuidado, ya que los errores (como pérdidas de memoria o falta de sincronización) pueden causar errores que son muy difíciles de reproducir, o derribar todo el servidor.
¿Hay alguna ventaja en hacerlo y en qué escenario se necesitaría hacer eso?
Bueno, la ventaja es que puedes hacer cosas en paralelo. El uso de hilos para mejorar la velocidad computacional pura es algo que no debe hacer en un servidor web, ya que ralentizaría el manejo de otras solicitudes. Ese tipo de cosas debe hacerse en un servidor separado, probablemente utilizando algún tipo de cola de trabajo.
Un escenario legítimo para subprocesos múltiples en el contexto del manejo de una solicitud HTTP podría ser si necesita acceder a otros recursos de la red, por ejemplo, llamar a varios servicios web diferentes. Si lo hace de una sola vez, debe esperar a que finalice cada llamada. Pero si usa varios hilos, el tiempo de espera total es solo el retraso de la llamada más lenta.
Concurrency Utilities.