Eine Sache, die Sie wissen müssen, ist, dass ExecutorService
eine Schnittstelle ist, nicht eine Klasse, so die Antwort könnte für verschiedene Implementierungen von ExecutorService
unterschiedlich sein.
Das gesagt, es wäre nicht sinnvoll für die meisten Anwendungen, wenn ein ExecutorService
benahm sich in der Art, dass Sie sich Sorgen machen. Es würde viel mehr Sinn machen, wenn jeder Worker-Thread sein Ergebnis im Objekt Future
speichern würde, das an den Client zurückgegeben wurde, und dann das Ergebnis vergessen und die Future
vergessen und mit der nächsten Aufgabe fortfahren.
IF das ist, wie sie umgesetzt wird, und wenn Ihr Code vergessen hat, auch über die Future
, dann ist die Future
und das Ergebnis sowohl von der GC gesammelt werden würden, und das wäre das Ende sein.
Das ist die Implementierung, die für mich Sinn machen würde. Sie können selbst sehen, wie die ThreadPoolExecutor
Klasse in dem OpenJDK-Projekt tut es tatsächlich durch den Quellcode untersuchen:
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/util/concurrent
ich einen kurzen Blick nahm, aber ich habe keine Zeit, es in der Tiefe zu studieren .
Wie ich in meinem Kommentar (oben) gesagt habe, würde ich einen Test schreiben und für mich selbst herausfinden, ob ich irgendwelche Zweifel hatte.
_Ich meine, ein Thread im Thread-Pool kann nie wieder verwendet werden, da sein Ergebnis nicht abgerufen wird_ Können Sie das Verhalten beschreiben, an das Sie hier denken? –
Das können Sie leicht testen: Erstellen Sie einen festen Thread-Pool, übermitteln Sie mehr Anfragen als die Anzahl der Threads und sehen Sie, was passiert. –
@SotiriosDelimanolis, danke für die Antwort und Abstimmung. Ich nehme an, wenn Thread-Pool der Größe 5 ist, wenn ich 5 Threads einreiche, ohne das Ergebnis abzurufen, ob ich den 6. Thread einreichen kann? Das ist die Frage. –