Die Servlet-API sagt über "AsyncContext.start":

Start stornieren (java.lang.Runnable run)

Bewirkt, dass der Container einen Thread, möglicherweise aus einem verwalteten Thread-Pool, auslöst, um die angegebene ausführbare Datei auszuführen. Der Container kann geeignete Kontextinformationen an die ausführbare Datei weitergeben.

Aus dieser Beschreibung geht nicht hervor, in welchem ​​Verhältnis sie zur Optimierung der Thread-Nutzung steht, wenn der Job gewartet werden muss.

In "Servlet & JSP" gibt Budi Kurniawan ein Beispiel für asynchrone Servlet 3.0-Funktionen, die er verwendetAsyncContext.startIch zeige eine vereinfachte Version des Beispiels:

<code>public void doGet(...) {
    final AsyncContext asyncContext = request.startAsync();

    asyncContext.start(new Runnable() {                        
        @ Override
        public void run() {
            // do some work here which involves waiting
            ...
            asyncContext.complete();
        }
    });
}
</code>

In den meisten anderen Beispielen, die ich getroffen habe, speichert die Dienstmethode den AsyncContext nur irgendwo und er wird irgendwo anders verarbeitet (z. B. durch einen Hintergrund-Thread). In diesem Beispiel sieht es so aus, als ob der Job nur an einen anderen Thread übergeben wird, der die Anforderung abschließt. Soweit ich weiß, ist es jetzt einfach der Arbeitsthread, der Zeit mit Warten verschwendet.

Gewinnen Sie tatsächlich etwas, indem Sie den Job (der das Warten umfasst) von einem Thread zum anderen weitergeben? Wenn nicht, wozu?AsyncContext.start(...)?