resueltos - ¿Cuándo deberíamos usar el hilo de Java sobre el ejecutor?
hilos en java netbeans (7)
Ejecutor parece una abstracción limpia. ¿Cuándo querría usar Thread directamente en lugar de confiar en el ejecutor más robusto?
Bueno, pensé que un ThreadPoolExecutor proporcionaba un mejor rendimiento porque administra un conjunto de subprocesos, minimizando la sobrecarga de crear instancias de un nuevo subproceso, asignar memoria ...
Y si va a lanzar miles de subprocesos, le dará algunas funciones de cola que tendría que programar por sí mismo ...
Los subprocesos y los Ejecutores son herramientas diferentes, utilizadas en diferentes escenarios ... Tal como lo veo, es como preguntar por qué debo usar ArrayList cuando puedo usar HashMap. Ellos son diferentes...
El paquete java.util.concurrent proporciona una interfaz de ejecutor y se puede usar para crear un hilo.
La interfaz Executor proporciona un solo método, ejecución, diseñado para ser un reemplazo directo de un lenguaje común de creación de hilos. Si r es un objeto Runnable, y e es un objeto Executor que puede reemplazar
(Nuevo Thread (r)). start ();
con
e.execute (r);
Refiera here
No hay ninguna ventaja al usar hilos crudos. Siempre puede proporcionar a los Ejecutores una fábrica de subprocesos, por lo que incluso se cubre la opción de creación de subprocesos personalizados.
No utilice Thread a menos que necesite un comportamiento más específico que no se encuentre en Thread. Luego extiendes Thread y agregas tu comportamiento específicamente deseado.
De lo contrario solo usa Runnable o Executor.
Para dar algo de historia, los Ejecutores solo se agregaron como parte del estándar Java en Java 1.5. Entonces, de alguna manera, los Ejecutores pueden ser vistos como una nueva abstracción mejor para tratar con las tareas Ejecutables.
Un poco de una simplificación excesiva que viene ... - Los ejecutores son hilos hechos correctamente, así que utilícelos con preferencia.
Siempre es mejor preferir Executor a Thread incluso para un solo hilo como se muestra a continuación
ExecutorService fixedThreadPool = Executors.newFixedThreadPool(1);
Puedes usar Thread over Executor en los siguientes escenarios
Su aplicación necesita hilos limitados y la lógica empresarial es simple
Si el modelo de subprocesamiento simple satisface sus necesidades sin Thread Pool
Confía en administrar el ciclo de vida de los subprocesos y los escenarios de manejo de excepciones con la ayuda de las API de bajo nivel en las siguientes áreas:
Inter thread communication, Exception handling, reincarnation of threadsdebido a errores inesperados
y un último punto
Si su aplicación no necesita personalización de varias características de
ThreadPoolExecutorThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)
En todos los demás casos, puedes ir a ThreadPoolExecutor
Uso Thread cuando necesito un procesamiento de mensajes basado en extracción. Por ejemplo, una cola es take () - es en un bucle en un hilo separado. Por ejemplo, envuelve una cola en un contexto costoso: digamos una conexión JDBC, una conexión JMS, archivos para procesar desde un solo disco, etc.
Antes de que me maldigan, ¿tienes algún escenario?
Editar :
Como lo han dicho otros, la interfaz Executor ( ExecutorService ) tiene más potencial, ya que puede usar los Executors para seleccionar un comportamiento: programado, priorizado, en caché, etc. en Java 5+ o en un puerto trasero de Java para Java 1.4.
El marco del ejecutor tiene protección contra los errores ejecutables y vuelve a crear automáticamente subprocesos de trabajo. Un inconveniente en mi opinión, es que debes awaitTermination() shutdown() y awaitTermination() explícitamente antes de salir de la aplicación, lo cual no es tan fácil en las aplicaciones GUI. Si usa colas limitadas, debe especificar un RejectedExecutionHandler o los nuevos ejecutables se tirarán.
Puede echar un vistazo a Brian Goetz et al: Java Concurrency in Practice (2006)