ExecutorService y el patrón Command

ExecutorService y el patrón Command

por | Jun 24, 2018

ExecutorService es el nombre que se le ha dado a la API de concurrencia implantada en el JDK7. Su nombre deriva de la única interfaz que hereda de Executor.

Hemos hablado más en profundidad en este blog sobre el patrón Command y hoy venimos a desenmarañar la relación de las clases de esta API para ver una vez más, como el JDK no es ajeno a la implantación de patrones.

Esta API no solo implementa el patrón Command, también usa el Method Factory para devolvernos una instancia. No reflejaremos esto para no complicar más de lo necesario el diagrama UML.

Comencemos por la clase ThreadPoolExecutor. Por supuesto, simplificaremos su explicación, ya que la clase es un pequeño infierno de código usando clases muy variopintas.

Este ThreadPoolExecutor que tomamos como ejemplo, es una de las posibilidades que tenemos a la hora de instanciar un pool de threads de tipo ExecutorService.

Esta clase contiene un atributo de tipo BlockingQueue, que básicamente permite que un hilo introduzca tareas en la cola y otro las consuma de forma segura.

También contiene una inner-class llamada Worker. Esta clase tiene un constructor parametrizado con un Runnable que se encarga de mantener el control de los hilos que ejecutan las tareas. Se podría interpretar como la clase encargada de ejecutar las tareas de la BlockingQueue.

Cuando llamamos al método execute() de la clase principal (recordemos que ThreadPoolExecutor contiene una clase hija Worker), lo que realmente hacemos es comprobar el número de Workers y el máximo que podemos tener para ejecutar la tarea.

  • Si tenemos menos Workers de los que podríamos tener, añadimos uno para ejecutar la tarea.
  • SI tenemos el máximo numero de Workers ya trabajando, metemos en la blockingQueue esa tarea para ser ejecutada más adelante.
  • SI no podemos crear más Workers ni poner en la cola esa tarea, se crea un nuevo hilo solo para desecharla.

A continuación pongo un diagrama UML muy sencillo en el que se aprecian las principales clases, interfaces y relaciones.

executor service uml

¿Veis el parecido con el patrón Command? El invoker aquí esta representado por la clase ThreadPoolExecutor, la cual a través de sus Workers, va resolviendo tareas que el usuario crea.

Recordemos el propósito fundamental del patrón Command: desacoplar la ejecución de la clase que ejecuta una tarea del usuario que la crea, para ser gestionada por un intermediario.

La API Concurrence efectivamente usa el patrón Command, por supuesto de una forma más refinada (ya que usa mecanismos de control de sincronicidad, entre ostras cosas) pero no deja de cumplir con el principio del patrón.

Los hilos en Java I

por | Jun 21, 2018

El concepto de procesos e hilos no es exclusivo de Java. Los sistemas operativos usan hilos para ejecutar procesos, y como mínimo un proceso debe estar siendo ejecutado en un hilo.

Manejar correctamente los hilos en cualquier aplicación informática es la diferencia más crítica a la hora de hablar de rendimiento, y por eso es necesario comprender profundamente estos conceptos como desarrolladores.

Existen fundamentalmente dos tipos de hilos en la máquina virtual de Java: los hilos del sistema y los hilos demonio (daemon). Los demonios son hilos que se ejecutan a lo largo de la vida de una aplicación controlando diversos aspectos de bajo nivel para el buen funcionamiento de los hilos del sistema. En Java, el daemon más conocido es el garbage collector, que se encarga de liberar espacio en la memoria dinámicamente buscando valores que no están siendo apuntados por ninguna variable.

Los hilos además pueden tener prioridades. Por ejemplo en Linux un proceso (que puede estás definido por uno o mas hilos), puede tener una prioridad de -20 a 20 en función de si es más o menos prioritario. En Java se maneja gracias a una propiedad de la clase Thread, que es la clase fundamental para crear nuevos hilos de sistema, en una escala de 1 a 10.

En Java existen dos maneras de crear una tarea:

  • Proveer una clase que implemente Runnable
  • Crear una clase que extienda Thread

Cada una de ellas tiene sus ventajas e inconvenientes, como explico en esta entrada, pero vemos como implementar cada una de ellas.

La interfaz Runnable

La interfaz Runnable es una interfaz funcional, es decir, una interfaz que implementa un solo método abstracto sin parámetros ni variable de retorno. Se usa para definir una tarea que deberá ejecutar un hilo.

La clase Thread

La clase Thread es la representación de un hilo, y se puede construir de dos formas.

  1. Pasándole por parámetro al constructor de la clase un objeto de tipo Runnable.
  2. Crear una clase que extienda Thread y sobrescribiendo el método run() que hereda de la interfaz Runnable.

Para lanzar el hilo, simplemente tenemos que llamar al método start(), el cual llama al método run() sobreescrito por la clase.

Veamos con un ejemplo simple esto:

Vemos que el hilo principal del programa, creado por la llamada al método main() crea dos nuevos hilos paralelos y los lanza. Podríamos representarlo gráficamente de la siguiente forma:

La máquina virtual de Java acaba la ejecución del programa cuando todos los hilos del sistema terminan.

Hay que tener muy en cuenta que la llamada al método run() de una clase que implemente Runnable no crea un nuevo hilo, solo provoca que la tarea sea ejecutada por el hilo que ha llamado al método.

En la siguiente entrada veremos brevemente cuáles son las APIs de concurrencia de Java y sus principales características.