Sollten Sie immer einen ExecutorService verwenden, anstatt einen eigenen Thread zu starten?

Question

Mit JDK> = 1.5, sollte der bevorzugte Weg, um einen Thread zu starten, immer ein Executor oder Executor Service sein, oder gibt es noch Gründe, einen Thread.start zu verwenden, wenn Sie nicht brauchen, was ein ExecutorService bietet?

Für syncronized dachte ich, dass die Verwendung der neuen Lock-Implementierungen bevorzugt wurde, bis ich explained otherwise war. Ich frage mich also genauso nach Executors. Sind sie nur eine Möglichkeit, komplexere Fälle zu behandeln, oder sollten sie die Standardauswahl sein?

Answer 1

persönlich seit Java 5, habe ich über Thread und ThreadGroup vollständig verlassen, da sie bieten viel weniger kundenspezifische Anpassung und Funktionalität als ExecutorService.

Wenn ich ExecutorService benutze, weiß ich, dass ich Callable verwenden kann, ich weiß, dass ich (mit ein wenig Aufwand) wiederholte Aufgaben planen kann. Als Konsequenz betrachte ich direkte Instanziierung von Thread Objekten als veralteten Code, wie Vector und Hashtable sind.

Answer 2

Java Concurrency in Practice zumindest eindeutig in Abschnitt 6.2 .:

Die primäre Abstraktion für die Task-Ausführung in den Java-Klassenbibliotheken ist nichtThread, aber Executor. [...]

Die Verwendung eines Executor ist normalerweise der einfachste Weg, ein Producer-Consumer-Design in Ihrer Anwendung zu implementieren.

Answer 3

Das Schreiben von korrektem Multi-Thread-Code ist sehr schwierig. Die Schönheit des Executor-Frameworks besteht darin, dass es den größten Teil der Schwerfälligkeit implementiert, der von Entwicklern begegnet wird, und dass Sie nur Callable oder Future implementieren und das Programm java.util.concurrent programmieren müssen. IMHO führt dies zu viel besser lesbarem Code und bietet aufgrund der Komplexität der korrekten Verwaltung von Threads viel weniger Möglichkeiten, ihn falsch zu implementieren.