Am I correct in saying that for Web Applications the web container takes care of multi-threading?
La maggior parte dei server web (Java e non, incluso JBoss) seguono un modello "un thread per richiesta", cioè ogni richiesta HTTP viene completamente elaborata da esattamente un thread. Questa discussione spesso impiega la maggior parte del tempo ad aspettare cose come richieste DB. Il contenitore web creerà nuovi thread, se necessario.
Alcuni server (nell'ecosistema Java principalmente Netty ) eseguono la gestione asincrona delle richieste, con un modello "un filo fa tutto" o qualcosa di più complesso. L'idea di base è che avere un sacco di thread in attesa spreca risorse, quindi lavorare in modo asincrono può essere più efficiente.
If so, can I introduce new treads in a Web Based applications?
È possibile, ma dovrebbe essere fatto con molta attenzione, dal momento che errori (come perdite di memoria o sincronizzazione mancante) possono causare bug che sono molto difficili da riprodurre o far cadere l'intero server.
Is there any advantage in doing so and in what scenario one would need to do that?
Bene, il vantaggio è che puoi fare cose in parallelo. L'uso di thread per migliorare la pura velocità di calcolo è qualcosa che dovresti non fare su un server web, poiché rallenterebbe la gestione di altre richieste. Questo tipo di cose dovrebbe essere fatto su un server separato, probabilmente usando una sorta di coda di lavoro.
Uno scenario legittimo per il multithreading nel contesto della gestione di una richiesta HTTP potrebbe essere se devi accedere ad altre risorse di rete, ad es. chiama diversi servizi web. Se lo fai in un singolo thrad, devi aspettare che ogni chiamata finisca a turno. Ma se usi più thread, il tempo di attesa totale è solo il ritardo della singola chiamata più lenta.