Cómo Threadpool reutiliza Threads y cómo funciona

Mis conceptos de Multithreading son débiles e intentan aprender.

En java, lo que sé es que no podemos llamar a un hilo más de una vez, es decir,

Thread t = new Thread(//Some Runnable); t.start() t.start() //Illegal and throw Exception at Runtime. 

Por lo que yo sé, arroja una excepción cuando llamas a t.start () otra vez porque la stack asociada para el Thread se destruye una vez que sale del método run() y estás tratando de inicializar cosas de nuevo.

En ese caso, lo que sé sobre Threadpool es que ofrece un mejor rendimiento y ahorra tiempo porque no es necesario crear un nuevo hilo. (Lo leí en http://www.javatpoint.com/thread-pooling-in-java )

si no es necesario crear un nuevo escenario Thread en ThreadPool, entonces ¿cómo funciona con el mismo hilo que acaba de finalizar su método de ejecución? ¿Se puede volver a utilizar ese hilo?

Leí esto, http://docs.oracle.com/javase/tutorial/essential/concurrency/pools.html y dice que “la mayoría de las implementaciones de ejecutores en java.util.concurrent usan grupos de subprocesos, que consisten en subprocesos de trabajo Este tipo de subproceso existe por separado de las tareas Ejecutables e Invocables que ejecuta y se usa a menudo para ejecutar múltiples tareas.

Entonces, ¿qué es el hilo de trabajo aquí, es algo diferente a los hilos de Java normales?

con este enlace ¿Cómo hace un grupo de subprocesos en caché para reutilizar los subprocesos existentes? Obtuve algo, pero todavía estoy confundido sobre qué tipo de cosas se pueden eliminar cuando usamos el grupo de subprocesos y que ofrece un mejor rendimiento que el uso del subproceso normal de Java.

Así que podemos decir así,

El hilo tiene tres partes,

  1. Creación (indicando al sistema operativo que es un hilo nuevo, crea stack para él).
  2. Ejecutar Runnable es decir, el método run ().
  3. Destruyendo hilos.

Por lo tanto, teniendo en cuenta los 3 pasos anteriores, con Threadpool, los pasos 1 y 3 se pueden eliminar después de un número fijo de Creación de subprocesos. solo se ejecutará el Paso 2 para cada tarea, ¿por qué Threadpool es más rápido? podemos decir así? ¿Estoy en lo correcto?

Si no hay necesidad de crear un nuevo Thread en el escenario ThreadPool, entonces ¿cómo funciona con el mismo hilo que acaba de finalizar su método de ejecución? ¿Se puede usar el Thread de nuevo?

Simple: el hilo original nunca termina realmente. Solo espera que se ejecute otra tarea. En pseudo-código:

 // No, this isn't even slightly accurate! General impression only :) while (!pool.isShutdown()) { Runnable task = pool.waitForTaskOnQueue(); task.run(); } 

(Obviamente, cuando se cierra un grupo de subprocesos, debería dejar de esperar que los subprocesos también esperen otra tarea, pero con suerte obtendrá una idea general).

El proceso funciona en dos partes:

Presentación de la tarea: los grupos de subprocesos están estrechamente relacionados con una cola de locking. Cuando decimos executor.execute (ejecutable). El ejecutable / invocable se enqueda en la cola.

Ejecución de tareas: ahora las tareas deben ser recogidas de la cola. Digamos que cada vez que una tarea se envía a la cola, debe recogerse y ejecutarse.

Entonces, hay hilos que ejecutarán un ciclo infinito y verán la cola de tareas. Tan pronto como las tareas estén disponibles, un hilo lo seleccionará y ejecutará.

Por lo tanto, teniendo en cuenta los 3 pasos anteriores, con Threadpool, los pasos 1 y 3 se pueden eliminar después de un número fijo de Creación de subprocesos. solo se ejecutará el Paso 2 para cada tarea, ¿por qué Threadpool es más rápido? podemos decir así? ¿Estoy en lo correcto?

Sí, estás en lo correcto. La creación y destrucción de subprocesos es una de las tareas más costosas. Como en un grupo de subprocesos, los subprocesos ya se crearon, por lo que la sobrecarga de la creación de subprocesos no está allí. Pero si tiene hilos mucho más altos de lo que debería, será bastante malo para su aplicación. Puede salir de la OutofMemorry o puede estar relacionado con otros problemas. Para solucionar un tamaño de grupo de subprocesos, utilice la siguiente fórmula:

no of threads = 2 * no_of_cores * no_of_disks * percentage CPU utilization you need * (1 + (W/ C))

(W / C) es la fracción que indica el tiempo de espera para calcular el tiempo.

En el conjunto de subprocesos En lugar de crear nuevos subprocesos cuando llegan nuevas tareas, un grupo de subprocesos mantiene una cantidad de subprocesos inactivos que están listos para ejecutar tareas según sea necesario. Después de que un hilo completa la ejecución de una tarea, no muere. En cambio, permanece inactivo en el grupo esperando ser elegido para ejecutar nuevas tareas.

Puede limitar un número definido de subprocesos simultáneos en el grupo, lo que es útil para evitar sobrecargas. Si todos los hilos están ocupados ejecutando tareas, las nuevas tareas se colocan en una cola, esperando que un hilo esté disponible