Método de clase interna estática, utilizado para construir un patrón singleton para crear un grupo de subprocesos ThreadPoolExecutor

Anteriormente escribí un artículo sobre el grupo de subprocesos Java ThreadPoolExecutor usando la cola ilimitada LinkedBlockingQueue para implementar subprocesos múltiples y registré brevemente el uso de ThreadPoolExecutor usando la cola ilimitada LinkedBlockingQueue para implementar subprocesos múltiples. Sin embargo, en aplicaciones reales, en algunos escenarios de solicitudes simultáneas de gran tamaño, se crearán directamente varios grupos de subprocesos al mismo tiempo y existe el riesgo de que la memoria sea insuficiente. Por lo tanto, puede considerar utilizar el patrón singleton para administrar las llamadas al grupo de subprocesos.

El método más simple es usar @Bean para inyectar el ThreadPoolExecutor inicializado directamente en springboot. Este es un singleton, pero se convierte en un grupo de subprocesos público y no se puede cerrar () cuando se agota. Siempre existirá en la aplicación y ocupará un poco de memoria. Por supuesto, Springboot también viene con un grupo de subprocesos al que se puede llamar directamente, pero debido a que es público, la configuración no se puede cambiar de manera flexible según los diferentes servicios, por lo que es mejor escribir uno usted mismo cuando sea necesario.

Si no está familiarizado con el modo singleton, puede leer las siguientes dos publicaciones de blog, que son muy detalladas. Los métodos de implementación comunes incluyen métodos de inanición, perezoso, doble detección y métodos estáticos de clase interna para implementar casos únicos. Creo que los métodos estáticos de clase interna son los más apropiados.

Enlace de blog de referencia para el modo singleton: blogs.com/jingpeipei/p/5771716.html

blogs.com/damsoft/p/6105122.html

Usemos el método de clase interna estática para crear un singleton para administrar la creación de ThreadPoolExecutor:

Método de prueba empresarial:

Tenga en cuenta que este grupo de subprocesos de creación propia debe cerrarse a tiempo después de su uso. Teniendo en cuenta la concurrencia, se pueden procesar otras llamadas simultáneas al mismo tiempo mientras el grupo de subprocesos existe y no está cerrado. Cuando se llama después del cierre, se regenerará un nuevo grupo de subprocesos para continuar recibiendo solicitudes de procesamiento. Esto tiene en cuenta tanto el uso de la memoria como el rendimiento. Durante las pruebas, a la primera solicitud se le asignó un tamaño de 1000 y a la segunda solicitud se le asignó un tamaño de 1. Al procesar una solicitud con un tamaño de 1, al cerrar el grupo de subprocesos, la primera solicitud aún no se ha procesado, se crearán las solicitudes restantes para continuar procesando las solicitudes restantes y el grupo de subprocesos se cerrará después del procesamiento. Se pueden crear diferentes solicitudes en diferentes escenarios comerciales, más flexibles.