Me imagino que algunas tareas programar para tomar un tiempo muy largo y ScheduledThreadPoolExecutor crearía hilos adicionales para las otras tareas que deben ejecutarse, hasta que se alcanza un número máximo de hilos.¿Por qué ScheduledThreadPoolExecutor solo acepta un número fijo de subprocesos?
Pero parece que solo puedo especificar un número fijo de subprocesos para el grupo, ¿por qué es así?
Como el por qué, tampoco lo sé. Pero me puedo imaginar.
La cantidad de recursos de una computadora es limitada. No todos los recursos se pueden manejar al mismo tiempo tampoco.
Si varios procesos cargan archivos al mismo tiempo, se cargarán más despacio que si se cargaran secuencialmente (al menos en un disco duro).
Un procesador también tiene soporte limitado para manejar múltiples hilos al mismo tiempo. En algún momento, el SO o JVM pasarán más tiempo cambiando hilos, que los hilos que gastan ejecutando su código.
Esa es una buena razón para que el ScheduledThreadPoolExecutor se diseñe tal como es. Puede colocar cualquier cantidad de trabajos en la cola, pero nunca se ejecutan más trabajos al mismo tiempo que los que se pueden ejecutar de manera eficiente. Depende de usted equilibrar eso, por supuesto.
Si sus tareas están vinculadas a IO, establecería el tamaño del grupo pequeño, y si están unidas a la CPU, un poco más grande (32 o más). También puede hacer múltiples ScheduledThreadPoolExecutor s, uno para tareas vinculadas a IO y otro para tareas vinculadas a la CPU.
Mientras investigaba más sobre SchecduledThreadPoolExecutor encontré esto link, Este enlace explica SchecduledThreadPoolExecutor resuelve muchos problemas de la clase Timer. Y también la razón para introducir SchecduledThreadPoolExecutor fue reemplazar el temporizador (debido a varios problemas con el temporizador). Creo que el motivo de la cantidad fija de subprocesos pasados a SchecduledThreadPoolExecutor está en uno de los problemas que resuelve esta clase. es decir,
La clase Timer solo inicia un hilo . Si bien es más eficiente que crear un hilo por tarea, es no una solución óptima. La solución óptima puede ser utilizar una cantidad de hilos entre un hilo para todas las tareas y un hilo por tarea. En el efecto , la mejor solución es colocar las tareas en un grupo de subprocesos. El número de subprocesos en el grupo debe ser asignable durante la construcción a permitir que el programa determine el número óptimo de subprocesos en el grupo.
Así que, en mi opinión, aquí es donde está el caso de uso para SchecduledThreadPoolExecutor. En su caso, debe poder decidir el valor óptimo según las tareas que planea programar y el tiempo que estas tareas tardan en finalizar. Si tengo 4 tareas largas que están programadas para el mismo tiempo, preferiría que el tamaño de mi grupo fuera mayor que 4 si hay otras tareas que se ejecutarán al mismo tiempo. También preferiría separar tareas de larga ejecución en diferentes ejecutores como se indica en las respuestas anteriores.
Espero que esto ayude :)
Según Java Concurrency In Practice existen las siguientes desventajas de la creación del hilo sin límites:
Tema Ciclo de Vida sobrecarga
La creación de hilos y el desmontaje no son libres. La creación de subprocesos lleva tiempo y requiere alguna actividad de procesamiento por parte de la JVM y el sistema operativo.
consumo de recursos
hilos activos consumen recursos del sistema, especialmente la memoria. Cuando hay más subprocesos ejecutables que los procesadores disponibles, los subprocesos permanecen inactivos. Tener muchos hilos inactivos puede acumular mucha memoria, presionar al recolector de basura y tener muchos hilos que compitan por las CPU puede imponer otros costos de rendimiento también. Si tiene suficientes hilos para mantener todas las CPU ocupadas, la creación de más hilos no ayudará y puede incluso perjudicar.
Estabilidad
Hay un límite en el número de hilos puede ser creado. El límite varía según la plataforma y se ve afectado por factores que incluyen los parámetros de invocación de JVM, el tamaño de pila solicitado en el constructor de Thread y los límites en los hilos colocados por el sistema operativo subyacente. Cuando llega a este límite, el resultado más probable es un OutOfMemoryError. Tratar de recuperarse de ese error es muy arriesgado; es mucho más fácil estructurar su programa para evitar llegar a este límite.
Hasta cierto punto, más hilos puede mejorar el rendimiento, pero más allá de ese punto la creación de más hilos simplemente se ralentiza su aplicación, y la creación de un hilo demasiados puede causar toda su aplicación a fallará estrepitosamente. La forma de mantenerse fuera de peligro es limitar la cantidad de subprocesos que crea su aplicación y probarla exhaustivamente para asegurarse de que, incluso cuando se alcanza este límite, no se agoten los recursos.
La creación de subprocesos ilimitados puede parecer que funciona muy bien durante la creación de prototipos y el desarrollo, con problemas que aparecen solo cuando la aplicación está desplegada y bajo una gran carga.