AbortPolicy : Directo lanzado evitar que el sistema funcione correctamente.
CallerRunsPolicy : Mientras el grupo de subprocesos no está cerrada, la política directamente en el hilo de la persona que llama, ejecute la tarea actual se descarta.
DiscardOldestPolicy : deseche la solicitud más antigua, trata de presentar el trabajo actual de nuevo.
DiscardPolicy : descarte no puede manejar la tarea, no se da ningún tipo de tratamiento.
Si desea personalizar la interfaz de rechazar la estrategia puede lograr RejectedExecutionHandler
Cómo utilizar un grupo de subprocesos buena
El número de ajustes de tamaño de rosca
De cálculo intensivo
Como su nombre indica es la aplicación requiere una gran cantidad de recursos informáticos de la CPU, la era de la CPU multi-núcleo, tenemos que dejar que cada núcleo de CPU están involucrados en el cálculo, el rendimiento de la CPU utilizado en su totalidad, esto no se considera una pérdida de configuración del servidor, si configura un muy buen servidor también se ejecuta en un programa de un único subproceso que será igual que una pérdida grande
Para las aplicaciones de cálculo intensivo, para trabajar enteramente sobre el número de CPU de núcleo, por lo que con el fin de hacer que se reproduzca completamente las ventajas, evitar el cambio de contexto hilo excesivo, la solución ideal es: el número de hilos = número 1 núcleo de la CPU , también se puede establecer en número núcleo de la CPU * 2 , pero depende de la versión de JDK y configuraciones de CPU (CPU del servidor tiene Hyper-Threading)
IO-intensiva
Se entiende bien, y sobre todo que estamos haciendo para desarrollar aplicaciones web, que implica grandes cantidades de tráfico de la red, no sólo eso, con la base de datos, la interacción entre el caché y también implica IO, IO, una vez se produjo, en un hilo esperará estado, cuando el extremo IO, los datos está listo, el hilo seguirá
Por lo tanto, se puede encontrar aquí para aplicaciones intensivas de IO, podemos establecer el número de multi-hilo algunos del grupo de subprocesos, por lo que podemos hacer en este momento para esperar a IO, el hilo puede hacer otras cosas, para mejorar la eficiencia de procesamiento concurrente. A continuación, la cantidad de datos que no son del grupo de subprocesos puede establecer fácilmente? Por supuesto que no, asegúrese de recordar que el cambio de contexto hilo a un precio
Actualmente resumió una fórmula para aplicaciones intensivas de IO: threads = núcleos de CPU / (l factor de bloque) Este factor de bloque es generalmente 0,8 a 0,9, 0,8 o 0,9 pueden ser tomadas. Aplicar la fórmula para una CPU de doble núcleo, es el número ideal de hilos es 20, por supuesto, no es absoluto, es necesario de acuerdo con la situación real de ajustar y de negocios real: int final la poolSize = (int) (cpuCore / Resultados (1 - 0,9) )
parámetros de configuración del grupo de subprocesos
Utilizar el grupo de subprocesos cuando no se ha seleccionado ningún límite superior de los elementos de configuración. En primer lugar, no utilizar ninguna agrupación de hebras superior y dejó la cola sin límites ! Por ejemplo, configurar la cola de juego sin límites newCachedThreadPool debido a algunas circunstancias imprevistas, el grupo de subprocesos sistema será anormal, lo que lleva a surgir discusiones situación o cola de tareas sigue creciendo, dando lugar a fallos del sistema de agotamiento de memoria y excepciones. Recomendamos el uso de los primeros principios de un grupo de subprocesos a medida para evitar este problema, que es el estándar en el grupo de subprocesos
Establecer un número razonable de hilos, y el hilo de tiempo de inactividad para recuperarse , que debe ajustarse de acuerdo con los ciclos de ejecución de tareas específicas y el tiempo, evitar la frecuente recuperación y la creación , aunque nuestro objetivo es utilizar el grupo de subprocesos es mejorar el rendimiento del sistema y el rendimiento, sino también en cuenta bajo la estabilidad del sistema , problemas de otro modo inesperados surgen será muy problemático
De acuerdo con la escena real, elija adecuado para su política de rechazo . Para compensar, no meterse con el apoyo mecanismo de compensación automática de JDK ! Trate de usar tácticas personalizadas se negaron a revelar todos los detalles eran
Enganche su uso de la conducta incrustado
El uso del gancho, dejando el grupo de subprocesos para llevar a cabo la pista: ThreadPoolExecutor proporciona un método gancho protegida tipo puede ser reemplazado, lo que permite al usuario la tarea antes de la ejecución y después de la ejecución para hacer algo.
Podemos utilizarlo para lograr dicha inicialización ThreadLocal, recopilar estadísticas, tales como la tala y otras operaciones. BeforeExecute como gancho y afterExecute.
También hay un gancho se puede utilizar cuando la tarea se haya ejecutado la lógica permite al usuario insertar, como rerminated. Si la ejecución del método gancho falla, el trabajo de la rosca interna fallará o estar interrumpido
Cerrar el grupo de subprocesos
Cuando el contenido del grupo de subprocesos no se cita y el número de subprocesos de trabajo es 0, el grupo de subprocesos se dará por terminado. También podemos llamar a la parada terminar manualmente el grupo de subprocesos . Si nos olvidamos de llamar a la parada, con el fin de permitir que los recursos de rosca se liberan, también podemos utilizar KeepAliveTime y allowCoreThreadTimeOut para lograr sus objetivos! Por supuesto, el enfoque prudente es utilizar una máquina virtual Runtime.getRuntime (). AddShutdownHook método, la mano para llamar al método de cierre del grupo de subprocesos
