La tecnología de grupos de subprocesos se utiliza a menudo en el desarrollo de subprocesos múltiples de Java. Este artículo es una explicación detallada de los siete parámetros al crear un grupo de subprocesos de Java.
Se puede ver en el código fuente que el constructor del grupo de subprocesos tiene 7 parámetros, que son corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory y handler. Los 7 parámetros se explicarán uno por uno a continuación.
| nombre del parámetro | sentido | Presta atención a los puntos |
|---|---|---|
| corePoolSize | El número de subprocesos principales, el número mínimo de subprocesos mantenidos en el grupo de subprocesos (incluido el número de subprocesos activos e inactivos) | 1. Una vez creado el grupo de subprocesos, no es el número predeterminado de subprocesos de corePoolSize el que se creará de forma predeterminada, pero el subproceso se creará solo cuando se envíe la tarea |
| maximumPoolSize | Número máximo de subprocesos, el número máximo de subprocesos que se permite crear en el grupo de subprocesos | 1. MaximumPoolSize es generalmente mayor que el valor de corePoolSize 2. Si maximumPoolSize = corePoolSize, entonces el grupo de subprocesos es un grupo de subprocesos de tamaño fijo |
| keepAliveTime | El tiempo de vida del hilo inactivo en el grupo de hilos | 1. De forma predeterminada (allowCoreThreadTimeOut = false), keepAliveTime funcionará solo cuando el número de subprocesos en ejecución en el grupo de subprocesos supere corePoolSize, es decir, keepAliveTime solo funciona en subprocesos que superen corePoolSize (por ejemplo: corePoolSize = 10, actualmente hay 15 subprocesos en ejecución. En este momento, el número de subprocesos en ejecución supera el número de subprocesos centrales. Cuando los subprocesos están inactivos después de realizar tareas, cuando el tiempo alcanza el valor crítico de keepAliveTime, se destruirán 5 subprocesos y el último solo en el grupo de subprocesos Habrá 10 subprocesos disponibles) 2. Si el grupo de subprocesos se establece en allowCoreThreadTimeOut = true, entonces keepAliveTime también tiene un efecto en el subproceso principal, es decir, cuando el subproceso en el subproceso principal está inactivo, se destruirá cuando el tiempo alcanza el valor crítico de keepAliveTime. El número de subprocesos en el grupo de subprocesos puede ser 0 |
| unidad | Unidad de tiempo de mantenimiento (por ejemplo: segundos, milisegundos, etc.) | TimeUnit.DAYS; // días TimeUnit.HOURS; // horas TimeUnit.MINUTES; // minutos TimeUnit.SECONDS; // segundos TimeUnit.MILLISECONDS; // milisegundos TimeUnit.MICROSECONDS; // microsegundos TimeUnit.NANOSECONDS; // nano segundo |
| workQueue | Cola de bloqueo de tareas, cuando la cantidad de tareas excede la cantidad de subprocesos centrales en el grupo de subprocesos actual, la cola de cortes no está llena y las tareas que deben ejecutarse se colocarán en la cola de bloqueo primero para esperar | Una vez que se envía la nueva tarea, ingresará primero a la cola de trabajos y luego la sacará de la cola cuando esté programada. En jdk se proporcionan cuatro colas de trabajo: consulte los detalles a continuación |
| threadFactory | Objeto de fábrica de subprocesos, utilizado para crear una nueva instancia de subproceso | La fábrica utilizada al crear un nuevo hilo se puede utilizar para establecer el nombre del hilo, ya sea un hilo demonio, etc. |
| estrategia de rechazo del controlador | Negativa a ejecutar la estrategia de procesamiento. | Cuando las tareas en la cola de trabajo han alcanzado el límite máximo, y el número de subprocesos en el grupo de subprocesos también ha alcanzado el límite máximo, en este momento, si se envía una nueva tarea, cómo manejarla. La estrategia de rechazo aquí es resolver este problema. Hay 4 estrategias de rechazo en jdk: consulte a continuación para obtener más detalles |
workQueue
cola de trabajo①ArrayBlockingQueue
Cola de bloqueo limitada basada en matriz, ordenada por FIFO. Después de que entren nuevas tareas, se colocarán al final de la cola. Una matriz limitada puede evitar el agotamiento de los recursos. Cuando el número de subprocesos en el grupo de subprocesos alcanza corePoolSize, y entra una nueva tarea, la tarea se colocará al final de la cola, esperando ser programada. Si la cola está llena, se crea un nuevo subproceso, y si el número de subprocesos ha alcanzado maxPoolSize, se ejecutará la estrategia de rechazo.
②LinkedBlockingQuene
La cola de bloqueo ilimitada basada en la lista vinculada (de hecho, la capacidad máxima es Interger.MAX), ordenada por FIFO. Debido a la naturaleza ilimitada aproximada de la cola, cuando el número de subprocesos en el grupo de subprocesos alcanza corePoolSize, las nuevas tareas siempre se almacenarán en la cola en lugar de crear nuevos subprocesos hasta maxPoolSize. Por lo tanto, cuando se usa la cola de trabajo, el parámetro maxPoolSize De hecho, no funciona.
③SynchronousQuene
Una cola de bloqueo que no almacena tareas en caché, el productor coloca una tarea y debe esperar hasta que el consumidor la saca. Es decir, cuando ingrese una nueva tarea, no se almacenará en caché, sino que se programará directamente para ejecutar la tarea. Si no hay subprocesos disponibles, se creará un nuevo subproceso. Si el número de subprocesos alcanza maxPoolSize, se ejecutará la estrategia de rechazo.
④PriorityBlockingQueue
Cola de bloqueo ilimitada con prioridad, la prioridad se logra a través del parámetro Comparador (la cola se usa raramente).
Pautas de la política de procesamiento de rechazos:
1. CallerRunsPolicy Bajo esta política, el método de ejecución de la tarea rechazada se ejecuta directamente en el subproceso de la persona que llama, a menos que el grupo de subprocesos se haya cerrado, la tarea se abandona directamente. Si la adición de la tarea falla y el grupo de subprocesos no está cerrado, entonces el subproceso que llama (subproceso principal) llamará al método execute () en el ejecutor para ejecutar la tarea.
2. AbortPolicy La política predeterminada del grupo de subprocesos, si hay Tareas agregadas Si falla, la tarea se descartará y se lanzará una RejectedExecutionException.
3. DiscardPolicy Si una tarea no se puede agregar, la tarea se descartará sin que se inicie ninguna excepción.
4. DiscardOldestPolicy Si la tarea no se puede agregar, poll () se eliminará de la primera tarea en la cola e intentará agregarla nuevamente. Si aún falla, continuará reintentando de acuerdo con esta estrategia.
5. Personalice la política política si la estrategia anterior Si la política no puede cumplir con los requisitos, puede personalizar la política que cumpla con el escenario; implementar el métodojectedExecution () en la interfaz RejectedExecutorHandler.
La fuente del artículo se refiere a
https://blog.csdn.net/ye17186/article/details/89467919
https://blog.csdn.net/u012253957/article/details/102967238?utm_medium=distribute.pc_relevant.none- task-blog- baidujs_baidulandingword-1 & spm = 1001.2101.3001.4242